From Andy.Thompson at e-tcc.com Fri May 1 13:03:32 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 1 May 2015 13:03:32 +0000 Subject: [Freeipa-users] 2fa with trusted AD users Message-ID: <562e1b92aecf45fda5f76c03ae05a68c@TCCCORPEXCH02.TCC.local> Is this possible or do they have to be local IPA accounts? Looking at options for setting up freeradius with IPA on the backend and utilizing OTP, I've got a test case setup and working for local accounts but a lot of our users are trusted accounts. >From what I can tell it is not possible currently but I saw a reference along the line somewhere about external users. Can't really find much info otherwise. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From npmccallum at redhat.com Fri May 1 13:27:23 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 01 May 2015 09:27:23 -0400 Subject: [Freeipa-users] 2fa with trusted AD users In-Reply-To: <562e1b92aecf45fda5f76c03ae05a68c@TCCCORPEXCH02.TCC.local> References: <562e1b92aecf45fda5f76c03ae05a68c@TCCCORPEXCH02.TCC.local> Message-ID: <1430486843.2514.3.camel@redhat.com> On Fri, 2015-05-01 at 13:03 +0000, Andy Thompson wrote: > Is this possible or do they have to be local IPA accounts? Looking > at options for setting up freeradius with IPA on the backend and > utilizing OTP, I've got a test case setup and working for local > accounts but a lot of our users are trusted accounts. > > > From what I can tell it is not possible currently but I saw a > > reference along the line somewhere about external users. Can't > > really find much info otherwise. It is not currently possible. However, I believe Alexander had some ideas related to this. I've CC'd him. Nathaniel From nagerjj at gmail.com Fri May 1 15:11:28 2015 From: nagerjj at gmail.com (Josh N) Date: Fri, 1 May 2015 11:11:28 -0400 Subject: [Freeipa-users] Samba4 & Freeipa integration question Message-ID: <003601d08421$1a1fc020$4e5f4060$@gmail.com> Hello everyone, I am using Samba4 as a DC to authenticate windows hosts and would like to use the same user accounts on the Samba4 DC for authentication on my linux servers as well. Is it possible to perform this type setup using Samba4 and Freeipa together? Please provide any excellent guides for this setup too pls. Thank you in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Fri May 1 15:53:08 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 1 May 2015 17:53:08 +0200 Subject: [Freeipa-users] Common Name for the ipa-cacert-manage command In-Reply-To: <5542B231.6060104@cenic.org> References: <5536C111.1000706@cenic.org> <5536C761.7090704@redhat.com> <554287D5.5090702@cenic.org> <5542943B.5030105@redhat.com> <5542958A.3070102@cenic.org> <5542A289.9070105@redhat.com> <5542B231.6060104@cenic.org> Message-ID: hi, On Fri, May 1, 2015 at 12:52 AM, William Graboyes wrote: > > I guess it is time to get deep into API documentation. This is a hell of > a lot of hoops to jump through just so that users who don't have shell > access can easily change their passwords without having to see a scare > page. Distributing the IPA CA is not an option at this point, as we have a > very odd desktop support model. I thought all of this was to be fixed in > 4.1, which is why I went 4.1... and now nothing has changed... and I am > back to square 1. > that is unfortunate for you. Most companies have at least AD deployed on their infrastructure, and using that to deplay CA root certificates to all domain member computers is very easy. For unix/linux networks system like cfengine/puppet/whatever make this quite easy as well. So that is something you need to address and not really IPA's fault in my opinion. You could also deploy a password reset page using something like http://ltb-project.org/wiki/documentation/self-service-password behind a tls site with a certificate signed by one of the standard trusted authoriteis like verising, digicert, etc. That way your users could reset their passwords without the certificate errors and you could have the time to put order in your desktop infrastructure ;-) > This is the only, and I am serious here, the only gating factor for > FreeIPA going into production. The self-signed certs on the UI. It really > isn't safe or secure to tell users to "Just trust the self signed cert." > You create an easy vector for users to get sucked into a phishing trap. > Users are trained to just click warnings away, nothing new here. The certificate system is quite ... special. Just because the standard stores of the browsers trust a bunch of root CAs, does not mean that those are safe. Think of diginotar. I trust our IPA root CA much more than Turktrust Bilgi Iletisim ... (just the first one on the list of root CA's on firefox now). > Next question, Has anyone made or documented an external password change > program for freeipa? > I already pointed this one http://ltb-project.org/wiki/documentation/self-service-password, but there are others. I have used gente: https://github.com/sciurus/gente as well, really easy to set up and does it job. And there are plenty of commercial solutions out there willing to get your money if you let them :-) -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri May 1 16:37:06 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 1 May 2015 12:37:06 -0400 (EDT) Subject: [Freeipa-users] Samba4 & Freeipa integration question In-Reply-To: <003601d08421$1a1fc020$4e5f4060$@gmail.com> References: <003601d08421$1a1fc020$4e5f4060$@gmail.com> Message-ID: <1542657767.11459017.1430498226233.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I am using Samba4 as a DC to authenticate windows hosts and would like to use > the same user accounts on the Samba4 DC for authentication on my linux > servers as well. Is it possible to perform this type setup using Samba4 and > Freeipa together? Please provide any excellent guides for this setup too > pls. Thank you in advance! This is not possible right now. Samba 4 AD DC is missing cross-forest trust support which is required for interoperability with FreeIPA. There is ongoing work on implemented needed features in Samba and current set of patches to be merged upstream measured in several hundreds commits. We plan to target Samba 4.3 timeframe. -- / Alexander Bokovoy From abokovoy at redhat.com Fri May 1 16:38:19 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 1 May 2015 12:38:19 -0400 (EDT) Subject: [Freeipa-users] 2fa with trusted AD users In-Reply-To: <1430486843.2514.3.camel@redhat.com> References: <562e1b92aecf45fda5f76c03ae05a68c@TCCCORPEXCH02.TCC.local> <1430486843.2514.3.camel@redhat.com> Message-ID: <479875285.11460612.1430498299500.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Fri, 2015-05-01 at 13:03 +0000, Andy Thompson wrote: > > Is this possible or do they have to be local IPA accounts? Looking > > at options for setting up freeradius with IPA on the backend and > > utilizing OTP, I've got a test case setup and working for local > > accounts but a lot of our users are trusted accounts. > > > > > From what I can tell it is not possible currently but I saw a > > > reference along the line somewhere about external users. Can't > > > really find much info otherwise. > > It is not currently possible. However, I believe Alexander had some > ideas related to this. I've CC'd him. Not supported right now. We haven't started working on it but most likely 2FA support for AD users will come as part of ID Views feature. -- / Alexander Bokovoy From nagerjj at gmail.com Fri May 1 18:27:51 2015 From: nagerjj at gmail.com (Josh N) Date: Fri, 1 May 2015 14:27:51 -0400 Subject: [Freeipa-users] Samba4 & Freeipa integration question In-Reply-To: <1542657767.11459017.1430498226233.JavaMail.zimbra@redhat.com> References: <003601d08421$1a1fc020$4e5f4060$@gmail.com> <1542657767.11459017.1430498226233.JavaMail.zimbra@redhat.com> Message-ID: <005501d0843c$88b4aa30$9a1dfe90$@gmail.com> Thank you for that information. -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Friday, May 1, 2015 12:37 PM To: Josh N Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Samba4 & Freeipa integration question ----- Original Message ----- > I am using Samba4 as a DC to authenticate windows hosts and would like > to use the same user accounts on the Samba4 DC for authentication on > my linux servers as well. Is it possible to perform this type setup > using Samba4 and Freeipa together? Please provide any excellent guides > for this setup too pls. Thank you in advance! This is not possible right now. Samba 4 AD DC is missing cross-forest trust support which is required for interoperability with FreeIPA. There is ongoing work on implemented needed features in Samba and current set of patches to be merged upstream measured in several hundreds commits. We plan to target Samba 4.3 timeframe. -- / Alexander Bokovoy From lists at fahrendorf.de Fri May 1 19:21:09 2015 From: lists at fahrendorf.de (Martin (Lists)) Date: Fri, 01 May 2015 21:21:09 +0200 Subject: [Freeipa-users] thousands DSRetroclPlugin mesages In-Reply-To: <554213B0.5090604@redhat.com> References: <553CA688.9040009@fahrendorf.de> <553DE905.3080108@redhat.com> <5540D9DA.9040507@fahrendorf.de> <5540DFE7.9030208@redhat.com> <5540FE12.7060302@fahrendorf.de> <554213B0.5090604@redhat.com> Message-ID: <5543D225.9090204@fahrendorf.de> Sorry, first post went to Ludwig only. Now to the list as well. Am 30.04.2015 um 13:36 schrieb Ludwig Krispenz: >>> indicating that trimming works. >> As it seems my trimming is broken, at least partially. Is there >> something I can adjust? > no, it seems to be ok, IPA configures the "changelog maxage" as 2d, so > if changelog trimming runs, it removes changes older than two days, then > it "sleeps" for this time and then runs again, so the changes could pile > up to four days, then get trimmed and so on ... >>> you said "thousands" of messages, how frequent are they really ? >> On every reboot I got these messages. I do not get them during normal >> opperation. > how frequently do you reboot ? maybe you only see the trimming after > startup I reboot with almost every kernel update for fedora 21 (so about every month). >> Something odd I observed after the last two reboots: ns-slapd runs my >> hard disk for several minutes (about 15 minutes) after the reboot. This >> is the time it takes to log all these change record messages. So my question remains: What does the ldap server do with all these data? Is it possible to run trimming manually before shutdown? Or can I do some other things the get this messages away? >> Kindly >> Martin >> From nathan at nathanpeters.com Sat May 2 01:19:40 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 1 May 2015 18:19:40 -0700 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves Message-ID: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. I also have another host running PowerDNS serving as a slave. The FreeIPA servers are setup to allow transfers to the slave by IP. When adding the zone, the slave transfered it properly. However, when I update the zone in FreeIPA, although the serial number changes, in the /var/log/messages I only see an attempt to transfer to the second IPA server, and not the slave. This is the only log entry : May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending notifies (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client 10.178.0.99#29832: received notify for zone 'mydomain.net' I have restarted all services using ipactl restart several times. I have also ensured that the slave hostname and IP are in FreeIPA DNS. I have also added an NS entry pointing to the slave. According to the FreeIPA manual, once that NS entry is added, any zone updates should trigger a notify, but still the only notifications go out to FreeIPA servers and nothing else. Any idea how to fix this so FreeIPA notifies non IPA servers? I'm pretty sure I've followed all the instructions to the letter on this one... From munna.hadoop at gmail.com Sat May 2 11:03:03 2015 From: munna.hadoop at gmail.com (Shaik M) Date: Sat, 2 May 2015 19:03:03 +0800 Subject: [Freeipa-users] Cross Realm Authentication between two FreeIPA Servers Message-ID: Hi, can you please let me know, how to setup Cross Realm Authentication between two FreeIPA Servers? Thanks, Shaik -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat May 2 12:15:41 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 2 May 2015 08:15:41 -0400 (EDT) Subject: [Freeipa-users] Cross Realm Authentication between two FreeIPA Servers In-Reply-To: References: Message-ID: <209394969.11813499.1430568941473.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > can you please let me know, how to setup Cross Realm Authentication between > two FreeIPA Servers? Not supported yet. -- / Alexander Bokovoy From munna.hadoop at gmail.com Sat May 2 12:25:16 2015 From: munna.hadoop at gmail.com (Shaik M) Date: Sat, 2 May 2015 20:25:16 +0800 Subject: [Freeipa-users] Cross Realm Authentication between two FreeIPA Servers In-Reply-To: <209394969.11813499.1430568941473.JavaMail.zimbra@redhat.com> References: <209394969.11813499.1430568941473.JavaMail.zimbra@redhat.com> Message-ID: Do we have any plans to implement in future? Thanks, Shaik On 2 May 2015 at 20:15, Alexander Bokovoy wrote: > ----- Original Message ----- > > > Hi, > > > can you please let me know, how to setup Cross Realm Authentication > between > > two FreeIPA Servers? > Not supported yet. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Sat May 2 14:33:06 2015 From: jbaird at follett.com (Baird, Josh) Date: Sat, 2 May 2015 14:33:06 +0000 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves In-Reply-To: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> References: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> Message-ID: Is the PowerDNS slave in the NS RRSet for the IPA domain? Unfortuantely, bind-dyndb-ldap does not support 'also-notify' which would allow us to send notifies each time a zone update occurs to slave servers that are not in the RRSet [1]. To compensate for this in my environment, I had to lower the 'refresh' timer on the IPA zone. [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of nathan at nathanpeters.com Sent: Friday, May 1, 2015 8:20 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. I also have another host running PowerDNS serving as a slave. The FreeIPA servers are setup to allow transfers to the slave by IP. When adding the zone, the slave transfered it properly. However, when I update the zone in FreeIPA, although the serial number changes, in the /var/log/messages I only see an attempt to transfer to the second IPA server, and not the slave. This is the only log entry : May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending notifies (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client 10.178.0.99#29832: received notify for zone 'mydomain.net' I have restarted all services using ipactl restart several times. I have also ensured that the slave hostname and IP are in FreeIPA DNS. I have also added an NS entry pointing to the slave. According to the FreeIPA manual, once that NS entry is added, any zone updates should trigger a notify, but still the only notifications go out to FreeIPA servers and nothing else. Any idea how to fix this so FreeIPA notifies non IPA servers? I'm pretty sure I've followed all the instructions to the letter on this one... -- 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 From abokovoy at redhat.com Sat May 2 15:03:46 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 2 May 2015 11:03:46 -0400 (EDT) Subject: [Freeipa-users] Cross Realm Authentication between two FreeIPA Servers In-Reply-To: References: <209394969.11813499.1430568941473.JavaMail.zimbra@redhat.com> Message-ID: <1915852054.11824660.1430579026608.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Do we have any plans to implement in future? Yes, once we get everything ready for fully working AD trusts support (i.e. IPA users being able to login to Windows machines). The reason for that is because we will be re-using the same infrastructure in both cases so the code will largely be the same to drive both use cases. This is very important because then we don't need to update SSSD on the machines where current AD trust feature is already supported -- they will be able to operate with IPA-IPA trust the instant moment it is established. Actual process of setting up IPA-IPA trust will be a bit different, of course, as we have better ways to set the trust up in this case. -- / Alexander Bokovoy From nathan at nathanpeters.com Sat May 2 15:12:19 2015 From: nathan at nathanpeters.com (Nathan Peters) Date: Sat, 2 May 2015 08:12:19 -0700 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves In-Reply-To: References: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> Message-ID: <01F17D22C8F4469CA6D3CD783379C48E@Azul> The last 3 sentences of my original post refer to me adding the NS records for the slave. Is that what you mean? "I have also ensured that the slave hostname and IP are in FreeIPA DNS. I have also added an NS entry pointing to the slave." -----Original Message----- From: Baird, Josh Sent: Saturday, May 02, 2015 7:33 AM To: 'nathan at nathanpeters.com' ; freeipa-users at redhat.com Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves Is the PowerDNS slave in the NS RRSet for the IPA domain? Unfortuantely, bind-dyndb-ldap does not support 'also-notify' which would allow us to send notifies each time a zone update occurs to slave servers that are not in the RRSet [1]. To compensate for this in my environment, I had to lower the 'refresh' timer on the IPA zone. [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of nathan at nathanpeters.com Sent: Friday, May 1, 2015 8:20 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. I also have another host running PowerDNS serving as a slave. The FreeIPA servers are setup to allow transfers to the slave by IP. When adding the zone, the slave transfered it properly. However, when I update the zone in FreeIPA, although the serial number changes, in the /var/log/messages I only see an attempt to transfer to the second IPA server, and not the slave. This is the only log entry : May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending notifies (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client 10.178.0.99#29832: received notify for zone 'mydomain.net' I have restarted all services using ipactl restart several times. I have also ensured that the slave hostname and IP are in FreeIPA DNS. I have also added an NS entry pointing to the slave. According to the FreeIPA manual, once that NS entry is added, any zone updates should trigger a notify, but still the only notifications go out to FreeIPA servers and nothing else. Any idea how to fix this so FreeIPA notifies non IPA servers? I'm pretty sure I've followed all the instructions to the letter on this one... -- 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 From janellenicole80 at gmail.com Sat May 2 21:12:55 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sat, 2 May 2015 14:12:55 -0700 Subject: [Freeipa-users] CA replicas on all? Message-ID: <1C321CBF-F1B5-49AB-AA13-1935CD6CDFC1@gmail.com> Hi all, Just wondering if there are issues with running CA replicas on all the servers? Are there maybe performance issues or anything that I might not be aware of? ~Janelle From tlau at tetrioncapital.com Mon May 4 05:09:36 2015 From: tlau at tetrioncapital.com (Thomas Lau) Date: Mon, 4 May 2015 13:09:36 +0800 Subject: [Freeipa-users] FreeIPA cluster shutdown sequence Message-ID: Hi All, We got a power maintenance soon, so all servers need to shutdown. Is there have a shutdown / starting up procedure for FreeIPA cluster? We are currently running two node cluster. From pspacek at redhat.com Mon May 4 05:53:06 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 04 May 2015 07:53:06 +0200 Subject: [Freeipa-users] =?utf-8?q?Web_ui_error_=E2=80=9CYour_session_has_?= =?utf-8?q?expired=2E_Please_re-login=2E=E2=80=9D_from_a_browser_on_a_remo?= =?utf-8?q?te_client=2E?= In-Reply-To: References: <55420953.90805@redhat.com> Message-ID: <55470942.9040905@redhat.com> On 30.4.2015 14:39, Christopher Lamb wrote: > Hi Petr > > Thanks, we solved this issue and reported that back on this thread. The > troubleshooting guide has even been updated as a result. > > https://www.redhat.com/archives/freeipa-users/2015-April/msg00605.html > > Your suggestion has however hit the nail on the head - the problem was > clock skew between the Server hosting freeIPA and the workstations. Petr, could we detect this situation in initial Javascript? I can imagine that server sends its current UTC time to the browser while login page is loading and then client could compare (local UTC) - (server UTC) and scream if time difference is greater than ... 5 minutes or so? -- Petr^2 Spacek From brian.topping at gmail.com Mon May 4 08:03:16 2015 From: brian.topping at gmail.com (Brian Topping) Date: Mon, 4 May 2015 15:03:16 +0700 Subject: [Freeipa-users] Setup of SRV records for new domains Message-ID: <7790F86D-F826-4C42-A614-A06C995B13FF@gmail.com> I just added a new domain and didn't see the SRV records added for it. There is a TXT record, but none of the SRV records that are in other DNS domains. After going to the "Realm Domains tab of the "IPA Server" configuration, I see that the new domain was already added there, so I removed it and added it back, hoping that might cause the SRV records to be added, but no luck. Any ideas what I should check for? Thanks, Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brian.topping at gmail.com Mon May 4 08:23:24 2015 From: brian.topping at gmail.com (Brian Topping) Date: Mon, 4 May 2015 15:23:24 +0700 Subject: [Freeipa-users] Setup of SRV records for new domains In-Reply-To: <7790F86D-F826-4C42-A614-A06C995B13FF@gmail.com> References: <7790F86D-F826-4C42-A614-A06C995B13FF@gmail.com> Message-ID: On second view, I think my brain misfiled this. Maybe the records were not set up automatically, another DNS domain I thought had the records in fact do not. As a feature request, it seems like if a domain is added to "Domain Realms", it should also get the appropriate records for client autodiscovery. Cheers, Brian > On May 4, 2015, at 3:03 PM, Brian Topping wrote: > > I just added a new domain and didn't see the SRV records added for it. There is a TXT record, but none of the SRV records that are in other DNS domains. > > After going to the "Realm Domains tab of the "IPA Server" configuration, I see that the new domain was already added there, so I removed it and added it back, hoping that might cause the SRV records to be added, but no luck. > > Any ideas what I should check for? > > Thanks, Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dkupka at redhat.com Mon May 4 08:33:33 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 04 May 2015 10:33:33 +0200 Subject: [Freeipa-users] FreeIPA cluster shutdown sequence In-Reply-To: References: Message-ID: <55472EDD.7030408@redhat.com> On 05/04/2015 07:09 AM, Thomas Lau wrote: > Hi All, > > We got a power maintenance soon, so all servers need to shutdown. Is > there have a shutdown / starting up procedure for FreeIPA cluster? We > are currently running two node cluster. > Hello, as I responded a month ago (https://www.redhat.com/archives/freeipa-users/2015-April/msg00016.html) there is no special procedure. You just turn the servers off before the power outage and then turn them back on. -- David Kupka From pspacek at redhat.com Mon May 4 08:43:11 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 04 May 2015 10:43:11 +0200 Subject: [Freeipa-users] Setup of SRV records for new domains In-Reply-To: References: <7790F86D-F826-4C42-A614-A06C995B13FF@gmail.com> Message-ID: <5547311F.6040303@redhat.com> On 4.5.2015 10:23, Brian Topping wrote: > On second view, I think my brain misfiled this. Maybe the records were > not set up automatically, another DNS domain I thought had the records in > fact do not. > > As a feature request, it seems like if a domain is added to "Domain > Realms", it should also get the appropriate records for client > autodiscovery. It is actually not necessary to create all the SRV records in all domains. Client auto-discovery is using the TXT record which is added automatically and the _kerberos TXT record is like 'redirect'. The procedure is: - client client1.sub.example.com. searches for record _kerberos.sub.example.com TXT - _kerberos.sub.example.com TXT contains realm name "EXAMPLE.COM" - now the client knows that all the SRV records are inside example.com. domain - SRV records from example.com. are used from now on AFAIK this is very standard Kerberos behavior so it should work for all standard-compliant clients. Petr^2 Spacek > Cheers, Brian > >> On May 4, 2015, at 3:03 PM, Brian Topping >> wrote: >> >> I just added a new domain and didn't see the SRV records added for it. >> There is a TXT record, but none of the SRV records that are in other >> DNS domains. >> >> After going to the "Realm Domains tab of the "IPA Server" >> configuration, I see that the new domain was already added there, so I >> removed it and added it back, hoping that might cause the SRV records >> to be added, but no luck. >> >> Any ideas what I should check for? >> >> Thanks, Brian From pspacek at redhat.com Mon May 4 08:43:57 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 04 May 2015 10:43:57 +0200 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves In-Reply-To: <01F17D22C8F4469CA6D3CD783379C48E@Azul> References: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> <01F17D22C8F4469CA6D3CD783379C48E@Azul> Message-ID: <5547314D.3020506@redhat.com> Hello! On 2.5.2015 17:12, Nathan Peters wrote: > The last 3 sentences of my original post refer to me adding the NS records for > the slave. Is that what you mean? > > "I have also ensured that the slave hostname and IP are in FreeIPA DNS. I > have also added an NS entry pointing to the slave." Which version of FreeIPA and bind-dyndb-ldap are you using? I will look into it. Petr^2 Spacek > -----Original Message----- From: Baird, Josh > Sent: Saturday, May 02, 2015 7:33 AM > To: 'nathan at nathanpeters.com' ; freeipa-users at redhat.com > Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to > slaves > > Is the PowerDNS slave in the NS RRSet for the IPA domain? Unfortuantely, > bind-dyndb-ldap does not support 'also-notify' which would allow us to send > notifies each time a zone update occurs to slave servers that are not in the > RRSet [1]. To compensate for this in my environment, I had to lower the > 'refresh' timer on the IPA zone. > > [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of nathan at nathanpeters.com > Sent: Friday, May 1, 2015 8:20 PM > To: freeipa-users at redhat.com > Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves > > I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. > > I also have another host running PowerDNS serving as a slave. > The FreeIPA servers are setup to allow transfers to the slave by IP. When > adding the zone, the slave transfered it properly. > > However, when I update the zone in FreeIPA, although the serial number > changes, in the /var/log/messages I only see an attempt to transfer to the > second IPA server, and not the slave. This is the only log entry : > > May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending notifies > (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client > 10.178.0.99#29832: received notify for zone 'mydomain.net' > > I have restarted all services using ipactl restart several times. I have also > ensured that the slave hostname and IP are in FreeIPA DNS. I have also added > an NS entry pointing to the slave. > > According to the FreeIPA manual, once that NS entry is added, any zone updates > should trigger a notify, but still the only notifications go out to FreeIPA > servers and nothing else. > > Any idea how to fix this so FreeIPA notifies non IPA servers? I'm pretty sure > I've followed all the instructions to the letter on this one... > > > -- > 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 -- Petr^2 Spacek From tlau at tetrioncapital.com Mon May 4 08:58:06 2015 From: tlau at tetrioncapital.com (Thomas Lau) Date: Mon, 4 May 2015 16:58:06 +0800 Subject: [Freeipa-users] FreeIPA cluster shutdown sequence In-Reply-To: <55472EDD.7030408@redhat.com> References: <55472EDD.7030408@redhat.com> Message-ID: thanks, sorry that I missed that message. On Mon, May 4, 2015 at 4:33 PM, David Kupka wrote: > On 05/04/2015 07:09 AM, Thomas Lau wrote: >> >> Hi All, >> >> We got a power maintenance soon, so all servers need to shutdown. Is >> there have a shutdown / starting up procedure for FreeIPA cluster? We >> are currently running two node cluster. >> > > Hello, > as I responded a month ago > (https://www.redhat.com/archives/freeipa-users/2015-April/msg00016.html) > there is no special procedure. You just turn the servers off before the > power outage and then turn them back on. > > -- > David Kupka -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong From tbabej at redhat.com Mon May 4 10:15:24 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 04 May 2015 12:15:24 +0200 Subject: [Freeipa-users] deleting ipa user In-Reply-To: References: <33d9b6a68f2e45d98b4b96b84a973c33@TCCCORPEXCH02.TCC.local> <5540E598.8000902@redhat.com> <02dbb08ff03944ad9c1f753f3d2c2d64@TCCCORPEXCH02.TCC.local> <5540EA71.3070602@redhat.com> <0651d0d2bc9749e8b13b85772dd247e4@TCCCORPEXCH02.TCC.local> <5540EFCC.40900@redhat.com> <4fe3dfe261b140a2909d0d7428f25c90@TCCCORPEXCH02.TCC.local> <5540F1A1.6050501@redhat.com> <40190450ad2f455e9add8cd3b64c63ee@TCCCORPEXCH02.TCC.local> <5540F866.8090400@redhat.com> <83cdb7ccd4d34362a78e6f33cd81cf9d@TCCCORPEXCH02.TCC.local> <5540FCF4.8070606@redhat.com> <1c36c58d3c564cae80cc61ac7cbd4f42@TCCCORPEXCH02.TCC.local> <55410681.4020004@redhat.com> <638f1a52be4e4da3bb047c31cf290f5e@TCCCORPEXCH02.TCC.local> <55410FB6.3040600@redhat.com> <5541D9C9.8000807@redhat.com> <7fb45cc879614e03a38d11a48fe4a1ef@TCCCORPEXCH02.TCC.local> <554209FD.8020104@redhat.com> Message-ID: <554746BC.4030400@redhat.com> On 04/30/2015 02:31 PM, Andy Thompson wrote: >>> It appears that f82 is the user object and f87 is the group object. So you are >> right, I don't think f82 is what we were looking for, it just happened to have >> the username in it when I grepped without filtering the uniqueid. I'm not >> sure why it was having problems with the user group object, but I don't have >> individual group objects showing up for any local accounts I've created. >> You are right. I think the private group of a user is/should be deleted at the >> same time when you delete a user. > Is it normal that private groups do not show up in the user group listing or with ipa group-find commands? I thought I remembered seeing them on a freeipa 3 installation but I've checked a couple 4 installs and they don't show up. User private groups should not show up in the results of ipa group-* commands. I'm not sure what you meant by "user group listing", but they should show up when running the "id" command. > > I just had a random issue a little bit ago with another account when I checked the user groups in the web interface it popped with an unknown error dialog. I have not been able to reproduce it again and don't see anything in the error logs or access log which would indicate any problems. > >>> All that being said, I put 389-ds-base-1.3.3.1-16.el7_1.x86_64 on the box >> yesterday and the error has not shown since. So I'm not sure if it was >> because of the minor upgrade or cycling the daemon. >> The logs gave a lot of information but without a test case it could be difficult >> to identify the RC. >> Now as I mentioned I hit (with a non systematic test case) an other bug when >> deleting a user. It was impossible to remove the entry/group. In this bug I >> tested on standalone instance but on replicated topology I wonder if it could >> have the same symptom. >> > I've not been able to reproduce the issue in my sandbox environment so I'm not sure. It is also replicated. > > -andy > From tbabej at redhat.com Mon May 4 10:32:28 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 04 May 2015 12:32:28 +0200 Subject: [Freeipa-users] Access to IPA Web-UI with different domain names In-Reply-To: References: Message-ID: <55474ABC.8010506@redhat.com> On 04/27/2015 06:06 PM, David Dimovski wrote: > Hi Folks, > does somebody have a best practice, how to access the IPA Web-UI with > different domain names? > > Example: > Our IPA 4.1 have two different IPs (extern and intern) with two domain > names. The web gui is only accessible from the domain name, which IPA > was registered with (intern domain name). When trying to access with > the extern domain name, IPA is rewriting to the intern domain name. > > After disabling the rewriting, the web ui is accessible from the two > domain names, but the login is not possible from the extern domain > name (only intern domain name), getting the following error: > Logout session expired. > > Does sombody has a idea or a clue? > > Many thanks in advance! > > Best regards > David > > > Hi, one possible solution would be to setup a reverse proxy with the external domain name, which would be passing the requests from the external world to the internal IPA sever. However, the proxy would need to circumvent our XSS protection and rewrite the HTTP_REFERRER header to the internal hostname. I haven't tested it, so maybe additional issues would come up. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon May 4 11:09:32 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 04 May 2015 13:09:32 +0200 Subject: [Freeipa-users] Access to IPA Web-UI with different domain names In-Reply-To: <55474ABC.8010506@redhat.com> References: <55474ABC.8010506@redhat.com> Message-ID: <5547536C.8030503@redhat.com> On 05/04/2015 12:32 PM, Tomas Babej wrote: > > > On 04/27/2015 06:06 PM, David Dimovski wrote: >> Hi Folks, >> does somebody have a best practice, how to access the IPA Web-UI with >> different domain names? >> >> Example: >> Our IPA 4.1 have two different IPs (extern and intern) with two >> domain names. The web gui is only accessible from the domain name, >> which IPA was registered with (intern domain name). When trying to >> access with the extern domain name, IPA is rewriting to the intern >> domain name. >> >> After disabling the rewriting, the web ui is accessible from the two >> domain names, but the login is not possible from the extern domain >> name (only intern domain name), getting the following error: >> Logout session expired. >> >> Does sombody has a idea or a clue? >> >> Many thanks in advance! >> >> Best regards >> David >> >> >> > Hi, > > one possible solution would be to setup a reverse proxy with the > external domain name, which would be passing the requests from the > external world to the internal IPA sever. > > However, the proxy would need to circumvent our XSS protection and > rewrite the HTTP_REFERRER header to the internal hostname. > > I haven't tested it, so maybe additional issues would come up. > > Tomas > > For the record, Alexander pointed out that this would not work well, as connections passed by the proxy to the internal IPA instance would be encrypted using the external's server HTTP service ticket. A proper solution here would be to create an IPA replica with the external hostname. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon May 4 12:10:52 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 04 May 2015 14:10:52 +0200 Subject: [Freeipa-users] =?windows-1252?q?Web_ui_error_=93Your_session_has?= =?windows-1252?q?_expired=2E_Please_re-login=2E=94_from_a_browser_on_a_re?= =?windows-1252?q?mote_client=2E?= In-Reply-To: <55470942.9040905@redhat.com> References: <55420953.90805@redhat.com> <55470942.9040905@redhat.com> Message-ID: <554761CC.9050700@redhat.com> On 05/04/2015 07:53 AM, Petr Spacek wrote: > On 30.4.2015 14:39, Christopher Lamb wrote: >> Hi Petr >> >> Thanks, we solved this issue and reported that back on this thread. The >> troubleshooting guide has even been updated as a result. >> >> https://www.redhat.com/archives/freeipa-users/2015-April/msg00605.html >> >> Your suggestion has however hit the nail on the head - the problem was >> clock skew between the Server hosting freeIPA and the workstations. > > Petr, could we detect this situation in initial Javascript? > > I can imagine that server sends its current UTC time to the browser while > login page is loading and then client could compare (local UTC) - (server UTC) > and scream if time difference is greater than ... 5 minutes or so? > I think it's possible. Server sends HTTP response date header[1] with format [2]. In browser: var date = new Date(xhr.getResponseHeader('Date')); var diff = Date.now() - date.getTime(); var minutes = diff / 1000 / 60; new ticket: https://fedorahosted.org/freeipa/ticket/5015 [1] https://tools.ietf.org/html/rfc2616#section-14.18 [2] https://tools.ietf.org/html/rfc2616#section-3.3.1 -- Petr Vobornik From dpal at redhat.com Mon May 4 12:27:42 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 May 2015 08:27:42 -0400 Subject: [Freeipa-users] Common Name for the ipa-cacert-manage command In-Reply-To: <5542B231.6060104@cenic.org> References: <5536C111.1000706@cenic.org> <5536C761.7090704@redhat.com> <554287D5.5090702@cenic.org> <5542943B.5030105@redhat.com> <5542958A.3070102@cenic.org> <5542A289.9070105@redhat.com> <5542B231.6060104@cenic.org> Message-ID: <554765BE.8080002@redhat.com> On 04/30/2015 06:52 PM, William Graboyes wrote: > I have to agree with Benjamen here. > > I guess it is time to get deep into API documentation. This is a hell of a lot of hoops to jump through just so that users who don't have shell access can easily change their passwords without having to see a scare page. Distributing the IPA CA is not an option at this point, as we have a very odd desktop support model. I thought all of this was to be fixed in 4.1, which is why I went 4.1... and now nothing has changed... and I am back to square 1. I am not sure I understand your expectations. There are really no other options. You can go CA-less and have Puppet or similar to replace your certs when they expire. You can use IPA CA and let certmonger do the work. IPA CA can be root or chained. It is not clear what else we can do other than finish the automatic distribution of certs when key rotation happens. > This is the only, and I am serious here, the only gating factor for FreeIPA going into production. The self-signed certs on the UI. It really isn't safe or secure to tell users to "Just trust the self signed cert." You create an easy vector for users to get sucked into a phishing trap. > > Next question, Has anyone made or documented an external password change program for freeipa? > > > > On 4/30/15 3:28 PM, Benjamen Keroack wrote: >> With respect, neither option is realistic in the common case. Unless I'm >> mistaken, a CA-less installation will break in ~1 year when host >> certificates expire and are not automatically renewed via certmonger. >> Option 2 (sub-CA) is, as far as I can tell, also not feasible since no >> public CA will sell subordinate CA certificates commercially. At least not >> that I can find. >> >> In our case, the only option is to resign ourselves to using self-signed >> certificates for the UI. End users can import IPA CA root cert if they >> choose. >> >> On Thu, Apr 30, 2015 at 2:45 PM, Dmitri Pal wrote: >> >>> On 04/30/2015 04:50 PM, William Graboyes wrote: >>> >>>> Let me ask this a different way. >>>> >>>> What is the easiest method of using a trusted third party cert for the >>>> web UI? >>>> >>> Make IPA CA-less with just certs from that 3rd party CA installed or make >>> IPA trust that CA and be a sub CA. >>> >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-ca-options >>> >>> >>> >>>> Running IPA 4.1.0 on Centos 7. >>>> >>>> Thanks, >>>> Bill >>>> On 4/30/15 1:44 PM, Rob Crittenden wrote: >>>> >>>>> William Graboyes wrote: >>>>> >>>>>> Hi list, >>>>>> >>>>>> The end goal is to eliminate self signed certs from user interaction >>>>>> with FreeIPA, without having to roll out changes to each user in the >>>>>> house (and remote locations). So basically changing the CA to a >>>>>> trusted CA that will not bring "scare" the users with "Site security >>>>>> cannot be verified, return to safety." >>>>>> >>>>>> The problem with the CN is that when it is read from the CSR the >>>>>> CN="Certificate Authority". Which is not an acceptable CN according >>>>>> to the tool we use for generating certs, The tool we use expects a CN >>>>>> of something along the lines of example.com. >>>>>> >>>>> That sounds odd. The CN of a CA doesn't represent a machine or a >>>>> specific domain, it represents itself. Granted Certificate Authority >>>>> isn't all that unique a name either, but it's what we defaulted to, IIRC >>>>> based on the dogtag defaults. >>>>> >>>>> Changing it might have other odd side-effects too as it's hardcoded in a >>>>> few other places. I'm not exactly sure what would break, if anything. >>>>> >>>>> It sounds like your tool is issuing a server cert, not a CA cert. A >>>>> server cert traditionally has used cn=FQDN,. That >>>>> doesn't really apply to a CA. >>>>> >>>>> So it's changeable if you hack some installer code, but there be dragons. >>>>> >>>>> rob >>>>> >>>>>> Thanks, >>>>>> Bill >>>>>> >>>>>> On 4/21/15 2:55 PM, Rob Crittenden wrote: >>>>>> >>>>>>> William Graboyes wrote: >>>>>>> >>>>>>>> Hi List, >>>>>>>> >>>>>>>> I am having yet another issue, when I run the following command: >>>>>>>> ipa-cacert-manage renew --external-ca >>>>>>>> >>>>>>>> It does output the CSR, however the CN is not a valid name >>>>>>>> (Certificate Authority). Is it possible to change the output of >>>>>>>> this command to use an external CA that requires a proper common >>>>>>>> name to be in the CSR? >>>>>>>> >>>>>>>> What I am trying to do is change from the internal self signed >>>>>>>> certs to an external CA signing system. >>>>>>>> >>>>>>>> What isn't valid about the name? >>>>>>> This would make the IPA CA a subordinate of the external CA. Is >>>>>>> that what you want? >>>>>>> rob >>>>>>> >>>>>> >>>>>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Director of Engineering for 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 >>> >> >> >> >> -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon May 4 12:32:33 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 May 2015 08:32:33 -0400 Subject: [Freeipa-users] CA replicas on all? In-Reply-To: <1C321CBF-F1B5-49AB-AA13-1935CD6CDFC1@gmail.com> References: <1C321CBF-F1B5-49AB-AA13-1935CD6CDFC1@gmail.com> Message-ID: <554766E1.5070106@redhat.com> On 05/02/2015 05:12 PM, Janelle wrote: > Hi all, > > Just wondering if there are issues with running CA replicas on all the servers? Are there maybe performance issues or anything that I might not be aware of? > > ~Janelle > > > I do not think we have any data of any negative properties of such setup. We allow not running CA everywhere because there were requests to allow a subset but the initial design assumed a CA on every replica. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From brian.topping at gmail.com Mon May 4 12:59:55 2015 From: brian.topping at gmail.com (Brian Topping) Date: Mon, 4 May 2015 19:59:55 +0700 Subject: [Freeipa-users] Setup of SRV records for new domains In-Reply-To: <5547311F.6040303@redhat.com> References: <7790F86D-F826-4C42-A614-A06C995B13FF@gmail.com> <5547311F.6040303@redhat.com> Message-ID: <2C74FEA7-4C6E-485C-86B6-229225E98595@gmail.com> Ah, thanks! I see what's going on now. That helps a lot. I think what I was missing was the reluctance for IPA to serve domains that are not proper TLDs. I generally maintain internal security domains with an invented TLD since they are secure by definition. When I tried that today, it was unable to auto discover on this domain and I attributed it to the lack of SRV records. Thanks for setting me straight! Brian > On May 4, 2015, at 3:43 PM, Petr Spacek wrote: > > On 4.5.2015 10:23, Brian Topping wrote: >> On second view, I think my brain misfiled this. Maybe the records were >> not set up automatically, another DNS domain I thought had the records in >> fact do not. >> >> As a feature request, it seems like if a domain is added to "Domain >> Realms", it should also get the appropriate records for client >> autodiscovery. > > It is actually not necessary to create all the SRV records in all domains. > > Client auto-discovery is using the TXT record which is added automatically > and the _kerberos TXT record is like 'redirect'. > > The procedure is: > - client client1.sub.example.com . searches for record > _kerberos.sub.example.com TXT > - _kerberos.sub.example.com TXT contains realm name "EXAMPLE.COM " > - now the client knows that all the SRV records are inside example.com . domain > - SRV records from example.com . are used from now on > > AFAIK this is very standard Kerberos behavior so it should work for all > standard-compliant clients. > > Petr^2 Spacek > >> Cheers, Brian >> >>> On May 4, 2015, at 3:03 PM, Brian Topping >>> wrote: >>> >>> I just added a new domain and didn't see the SRV records added for it. >>> There is a TXT record, but none of the SRV records that are in other >>> DNS domains. >>> >>> After going to the "Realm Domains tab of the "IPA Server" >>> configuration, I see that the new domain was already added there, so I >>> removed it and added it back, hoping that might cause the SRV records >>> to be added, but no luck. >>> >>> Any ideas what I should check for? >>> >>> Thanks, Brian > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pspacek at redhat.com Mon May 4 13:09:36 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 04 May 2015 15:09:36 +0200 Subject: [Freeipa-users] Setup of SRV records for new domains In-Reply-To: <2C74FEA7-4C6E-485C-86B6-229225E98595@gmail.com> References: <7790F86D-F826-4C42-A614-A06C995B13FF@gmail.com> <5547311F.6040303@redhat.com> <2C74FEA7-4C6E-485C-86B6-229225E98595@gmail.com> Message-ID: <55476F90.5010907@redhat.com> On 4.5.2015 14:59, Brian Topping wrote: > Ah, thanks! I see what's going on now. That helps a lot. > > I think what I was missing was the reluctance for IPA to serve domains > that are not proper TLDs. I generally maintain internal security domains > with an invented TLD since they are secure by definition. When I tried > that today, it was unable to auto discover on this domain and I > attributed it to the lack of SRV records. Generally it is better to use 'internal.example.com.' instead of invented TLDs like 'mytld.'. FreeIPA can work with 'invented' TLDs if you have properly configured DNS but it is usually a nightmare. That is the reason why it is strictly discouraged. Also, 'invented' TLDs cannot work with DNSSEC validation unless you distribute trust anchor to every single DNSSEC validator. This is one more reason for using proper sub-domains instead of invented TLDs. Let me know if you want to hear mode details about that. Have a nice day! Petr^2 Spacek > Brian > >> On May 4, 2015, at 3:43 PM, Petr Spacek wrote: >> >> On 4.5.2015 10:23, Brian Topping wrote: >>> On second view, I think my brain misfiled this. Maybe the records >>> were not set up automatically, another DNS domain I thought had the >>> records in fact do not. >>> >>> As a feature request, it seems like if a domain is added to "Domain >>> Realms", it should also get the appropriate records for client >>> autodiscovery. >> >> It is actually not necessary to create all the SRV records in all >> domains. >> >> Client auto-discovery is using the TXT record which is added >> automatically and the _kerberos TXT record is like 'redirect'. >> >> The procedure is: - client client1.sub.example.com >> . searches for record >> _kerberos.sub.example.com TXT - >> _kerberos.sub.example.com TXT >> contains realm name "EXAMPLE.COM " - now the >> client knows that all the SRV records are inside example.com >> . domain - SRV records from example.com >> . are used from now on >> >> AFAIK this is very standard Kerberos behavior so it should work for >> all standard-compliant clients. >> >> Petr^2 Spacek >> >>> Cheers, Brian >>> >>>> On May 4, 2015, at 3:03 PM, Brian Topping >>>> wrote: >>>> >>>> I just added a new domain and didn't see the SRV records added for >>>> it. There is a TXT record, but none of the SRV records that are in >>>> other DNS domains. >>>> >>>> After going to the "Realm Domains tab of the "IPA Server" >>>> configuration, I see that the new domain was already added there, >>>> so I removed it and added it back, hoping that might cause the SRV >>>> records to be added, but no luck. >>>> >>>> Any ideas what I should check for? >>>> >>>> Thanks, Brian From desantis at mail.usf.edu Mon May 4 13:26:32 2015 From: desantis at mail.usf.edu (John Desantis) Date: Mon, 4 May 2015 09:26:32 -0400 Subject: [Freeipa-users] Questions about nsslapd-sizelimit Message-ID: Hello all! I believe I may be falling victim to the nsslapd-sizelimit's default setting of 2,000. I've been wondering why some JSON calls to IPA (3.0.37, user_find) have been failing to show all user accounts in the results. Checking the FreeIPA admin UI, I can clearly find the users in question, but no matter what changes I set in the UI on the the console with search record limits and time limits, only 2,000 entries are ever returned. A final test this morning by adding an account via the UI did not augment the 2,000 entries returned in the user list; searching for the user on the console with 'ipa user-show y* --all' and via the search frame in the UI found the user. Looking over the documentation, it's stated that you can use the UI to update the limits. However, the limit is already set at 10,000 for the number of records to be returned, and the time limit is set at 60. The current dse.ldiff states that the nsslapd-sizelimit is 2,000. Is it possible that IPA isn't respecting this value since the constant number is 2,000? Is it safe to change this value via an ldapmodify? Thank you! John DeSantis From harald.dunkel at aixigo.de Mon May 4 11:19:01 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Mon, 04 May 2015 13:19:01 +0200 Subject: [Freeipa-users] using pathlen:0 for freeipa's CA certificate? Message-ID: <554755A5.3080109@aixigo.de> Hi folks, Instead of a self-signed certificate I would like to use an external CA to sign freeipa's CSR ("ipa-server-install --external-ca"). Question: Is pathlen:0, e.g. basicConstraints=critical,CA:TRUE, pathlen:0 sufficient for freeipa's CA certificate? Regards Harri From rcritten at redhat.com Mon May 4 13:47:34 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 May 2015 09:47:34 -0400 Subject: [Freeipa-users] CA replicas on all? In-Reply-To: <1C321CBF-F1B5-49AB-AA13-1935CD6CDFC1@gmail.com> References: <1C321CBF-F1B5-49AB-AA13-1935CD6CDFC1@gmail.com> Message-ID: <55477876.9020602@redhat.com> Janelle wrote: > Hi all, > > Just wondering if there are issues with running CA replicas on all the servers? Are there maybe performance issues or anything that I might not be aware of? The only downside I can think of is resources used (RAM & disk) and slightly more administration regarding replication monitoring (both by you and 389-ds). Unless you are constantly creating and deleting certs the replication load should be extremely low once you have your environment stable. rob From rcritten at redhat.com Mon May 4 13:53:47 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 May 2015 09:53:47 -0400 Subject: [Freeipa-users] Questions about nsslapd-sizelimit In-Reply-To: References: Message-ID: <554779EB.8030608@redhat.com> John Desantis wrote: > Hello all! > > I believe I may be falling victim to the nsslapd-sizelimit's default > setting of 2,000. > > I've been wondering why some JSON calls to IPA (3.0.37, user_find) > have been failing to show all user accounts in the results. Checking > the FreeIPA admin UI, I can clearly find the users in question, but no > matter what changes I set in the UI on the the console with search > record limits and time limits, only 2,000 entries are ever returned. > A final test this morning by adding an account via the UI did not > augment the 2,000 entries returned in the user list; searching for > the user on the console with 'ipa user-show y* --all' and via the > search frame in the UI found the user. > > Looking over the documentation, it's stated that you can use the UI to > update the limits. However, the limit is already set at 10,000 for > the number of records to be returned, and the time limit is set at 60. > The current dse.ldiff states that the nsslapd-sizelimit is 2,000. > > Is it possible that IPA isn't respecting this value since the constant > number is 2,000? Is it safe to change this value via an ldapmodify? > > Thank you! > John DeSantis > Why do you need to return > 2000 users at one time? IPA purposely limits the number of entries returned by default (100) specifically to discourage enumeration which is expensive. It is safe to modify this value using ldapmodify. Increasing the value is not recommended. rob From desantis at mail.usf.edu Mon May 4 14:01:00 2015 From: desantis at mail.usf.edu (John Desantis) Date: Mon, 4 May 2015 10:01:00 -0400 Subject: [Freeipa-users] Questions about nsslapd-sizelimit In-Reply-To: <554779EB.8030608@redhat.com> References: <554779EB.8030608@redhat.com> Message-ID: Rob, Thanks for your reply. My predecessor had wrote code to pull user entries from the realm in order to verify that: 1.) A home directory is created (if not already) and apply the correct ownership; 2.) A work directory (Lustre) is created (if not already) and apply the correct ownership. Given what you've said, I'll perform a work-around within the code to get a list of active users from a database table vs. the current method. John DeSantis 2015-05-04 9:53 GMT-04:00 Rob Crittenden : > John Desantis wrote: >> Hello all! >> >> I believe I may be falling victim to the nsslapd-sizelimit's default >> setting of 2,000. >> >> I've been wondering why some JSON calls to IPA (3.0.37, user_find) >> have been failing to show all user accounts in the results. Checking >> the FreeIPA admin UI, I can clearly find the users in question, but no >> matter what changes I set in the UI on the the console with search >> record limits and time limits, only 2,000 entries are ever returned. >> A final test this morning by adding an account via the UI did not >> augment the 2,000 entries returned in the user list; searching for >> the user on the console with 'ipa user-show y* --all' and via the >> search frame in the UI found the user. >> >> Looking over the documentation, it's stated that you can use the UI to >> update the limits. However, the limit is already set at 10,000 for >> the number of records to be returned, and the time limit is set at 60. >> The current dse.ldiff states that the nsslapd-sizelimit is 2,000. >> >> Is it possible that IPA isn't respecting this value since the constant >> number is 2,000? Is it safe to change this value via an ldapmodify? >> >> Thank you! >> John DeSantis >> > > Why do you need to return > 2000 users at one time? > > IPA purposely limits the number of entries returned by default (100) > specifically to discourage enumeration which is expensive. > > It is safe to modify this value using ldapmodify. Increasing the value > is not recommended. > > rob From janellenicole80 at gmail.com Mon May 4 15:49:43 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 04 May 2015 08:49:43 -0700 Subject: [Freeipa-users] interesting Kerberos issue Message-ID: <55479517.7000803@gmail.com> Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? ~J From dpal at redhat.com Mon May 4 17:30:02 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 May 2015 13:30:02 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <55479517.7000803@gmail.com> References: <55479517.7000803@gmail.com> Message-ID: <5547AC9A.4020007@redhat.com> On 05/04/2015 11:49 AM, Janelle wrote: > Happy Star Wars Day! > May the Fourth be with you! > > So I have a strange Kerberos problem trying to figure out. On a > CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket > as expected. However, if I login to a 6.6 client, it doesn't seem to > work. Both were enrolled the same, obviously one is newer. > > Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login > as root, bypassing kerberos, and then do "kinit admin" it works just > fine. But if I do "kinit usera" I get: > > kinit: Generic preauthentication failure while getting initial > credentials > > Which makes no sense. The account works with a 7.1 client but not a > 6.x client?? And yet "admin" works, no matter what. What am I missing > here? > > ~J > This is really strange. What does happen on the server when you try kinit usera? Have you checked the KDC log? Look at the usera entry, may be there is some strange attribute there that causes this failure. Compare with admin entry. May be it will shed some light. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From stacy.redmond at blueshieldca.com Mon May 4 18:50:55 2015 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Mon, 4 May 2015 18:50:55 +0000 Subject: [Freeipa-users] Removing REALM requirement and home directory location Message-ID: <5434D6A65FEF2B428D5CC8D77FA7DA7106A41CD8@wexc201p.bsc.bscal.com> I am running a RHEL7 IPA Server ipa-server 3.3.3-28 RHEL6 clients running IPA Client 3.0.0-42 I have setup an AD trust which works great, however I want to make it so the users don't have to use @realm to login and that their home directory does not default to /home/realm/username AD sbx.local IPA unix.sbx.local Works great User login: ssh username at realm@hostname $ ssh aduser1 at sbx@linuxtest1.sbx.local aduser1 at sbx@linuxtest1.sbx.local's password: Last login: Fri May 1 09:36:53 2015 from xxx.xxx.xxx.xxx Could not chdir to home directory /home/sbx.local/aduser1: No such file or directory $ Any and all help is appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon May 4 20:02:25 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 04 May 2015 16:02:25 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <55479517.7000803@gmail.com> References: <55479517.7000803@gmail.com> Message-ID: <1430769745.916.85.camel@willson.usersys.redhat.com> On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > Happy Star Wars Day! > May the Fourth be with you! > > So I have a strange Kerberos problem trying to figure out. On a > CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as > expected. However, if I login to a 6.6 client, it doesn't seem to work. > Both were enrolled the same, obviously one is newer. > > Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as > root, bypassing kerberos, and then do "kinit admin" it works just fine. > But if I do "kinit usera" I get: > > kinit: Generic preauthentication failure while getting initial credentials > > Which makes no sense. The account works with a 7.1 client but not a 6.x > client?? And yet "admin" works, no matter what. What am I missing here? Have you recently changed the user password ? If so this symptom may indicate you are having replication issues between your servers, and one of the client is hitting the server that didn't get the keys replicated to it. Simo. -- Simo Sorce * Red Hat, Inc * New York From janellenicole80 at gmail.com Mon May 4 20:12:59 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 04 May 2015 13:12:59 -0700 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <1430769745.916.85.camel@willson.usersys.redhat.com> References: <55479517.7000803@gmail.com> <1430769745.916.85.camel@willson.usersys.redhat.com> Message-ID: <5547D2CB.9040106@gmail.com> On 5/4/15 1:02 PM, Simo Sorce wrote: > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >> Happy Star Wars Day! >> May the Fourth be with you! >> >> So I have a strange Kerberos problem trying to figure out. On a >> CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as >> expected. However, if I login to a 6.6 client, it doesn't seem to work. >> Both were enrolled the same, obviously one is newer. >> >> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as >> root, bypassing kerberos, and then do "kinit admin" it works just fine. >> But if I do "kinit usera" I get: >> >> kinit: Generic preauthentication failure while getting initial credentials >> >> Which makes no sense. The account works with a 7.1 client but not a 6.x >> client?? And yet "admin" works, no matter what. What am I missing here? > Have you recently changed the user password ? > If so this symptom may indicate you are having replication issues > between your servers, and one of the client is hitting the server that > didn't get the keys replicated to it. > > Simo. > None of the above -- All the servers are replicated. The user account (a test account) has not changed PW in weeks and works everywhere else. I nee to increase some logging. I guess the strange part is as mentioned -- it works if you login directly to the 7.1 client, no matter which server it is pointed at. ~J From dpal at redhat.com Mon May 4 21:52:27 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 May 2015 17:52:27 -0400 Subject: [Freeipa-users] Removing REALM requirement and home directory location In-Reply-To: <5434D6A65FEF2B428D5CC8D77FA7DA7106A41CD8@wexc201p.bsc.bscal.com> References: <5434D6A65FEF2B428D5CC8D77FA7DA7106A41CD8@wexc201p.bsc.bscal.com> Message-ID: <5547EA1B.5030908@redhat.com> On 05/04/2015 02:50 PM, Redmond, Stacy wrote: > > I am running a RHEL7 IPA Server ipa-server 3.3.3-28 > > RHEL6 clients running IPA Client 3.0.0-42 > > I have setup an AD trust which works great, however I want to make it > so the users don't have to use @realm to login and that their home > directory does not default to /home/realm/username > > AD sbx.local > > IPA unix.sbx.local > man sssd.conf /default_domain_suffix > Works great > > User login: ssh username at realm@hostname > > $ ssh aduser1 at sbx@linuxtest1.sbx.local > > aduser1 at sbx@linuxtest1.sbx.local's password: > > Last login: Fri May 1 09:36:53 2015 from xxx.xxx.xxx.xxx > > Could not chdir to home directory /home/sbx.local/aduser1: No such > file or directory > > $ > > Any and all help is appreciated. > > > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Mon May 4 22:24:33 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Mon, 4 May 2015 15:24:33 -0700 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves In-Reply-To: <5547314D.3020506@redhat.com> References: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> <01F17D22C8F4469CA6D3CD783379C48E@Azul> <5547314D.3020506@redhat.com> Message-ID: <628a95dd36f3507d9bb1c7bad00ea167.squirrel@webmail.nathanpeters.com> freeipa-admintools.x86_64 4.1.4-1.el7.centos @mkosek-freeipa freeipa-client.x86_64 4.1.4-1.el7.centos @mkosek-freeipa freeipa-python.x86_64 4.1.4-1.el7.centos @mkosek-freeipa freeipa-server.x86_64 4.1.4-1.el7.centos @mkosek-freeipa freeipa-server-trust-ad.x86_64 4.1.4-1.el7.centos @mkosek-freeipa bind.x86_64 32:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa bind-dyndb-ldap.x86_64 6.1-1.el7.centos @mkosek-freeipa bind-libs.x86_64 32:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa bind-libs-lite.x86_64 32:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa bind-license.noarch 32:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa bind-pkcs11.x86_64 32:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa bind-pkcs11-libs.x86_64 32:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa bind-pkcs11-utils.x86_64 32:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa And for reference here are the relevant A and NS records from my domain @ NS dc1.mydomain.net. @ NS dc2.mydomain.net. @ NS dns1.mydomain.net. dns1 A 10.21.0.14 > Hello! > > On 2.5.2015 17:12, Nathan Peters wrote: >> The last 3 sentences of my original post refer to me adding the NS >> records for >> the slave. Is that what you mean? >> >> "I have also ensured that the slave hostname and IP are in FreeIPA DNS. >> I >> have also added an NS entry pointing to the slave." > > Which version of FreeIPA and bind-dyndb-ldap are you using? > > I will look into it. > > Petr^2 Spacek > > >> -----Original Message----- From: Baird, Josh >> Sent: Saturday, May 02, 2015 7:33 AM >> To: 'nathan at nathanpeters.com' ; freeipa-users at redhat.com >> Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being >> sent to >> slaves >> >> Is the PowerDNS slave in the NS RRSet for the IPA domain? >> Unfortuantely, >> bind-dyndb-ldap does not support 'also-notify' which would allow us to >> send >> notifies each time a zone update occurs to slave servers that are not in >> the >> RRSet [1]. To compensate for this in my environment, I had to lower the >> 'refresh' timer on the IPA zone. >> >> [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of >> nathan at nathanpeters.com >> Sent: Friday, May 1, 2015 8:20 PM >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent >> to slaves >> >> I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. >> >> I also have another host running PowerDNS serving as a slave. >> The FreeIPA servers are setup to allow transfers to the slave by IP. >> When >> adding the zone, the slave transfered it properly. >> >> However, when I update the zone in FreeIPA, although the serial number >> changes, in the /var/log/messages I only see an attempt to transfer to >> the >> second IPA server, and not the slave. This is the only log entry : >> >> May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending >> notifies >> (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client >> 10.178.0.99#29832: received notify for zone 'mydomain.net' >> >> I have restarted all services using ipactl restart several times. I >> have also >> ensured that the slave hostname and IP are in FreeIPA DNS. I have also >> added >> an NS entry pointing to the slave. >> >> According to the FreeIPA manual, once that NS entry is added, any zone >> updates >> should trigger a notify, but still the only notifications go out to >> FreeIPA >> servers and nothing else. >> >> Any idea how to fix this so FreeIPA notifies non IPA servers? I'm >> pretty sure >> I've followed all the instructions to the letter on this one... >> >> >> -- >> 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 > > > -- > Petr^2 Spacek > > -- > 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 > From npmccallum at redhat.com Tue May 5 01:06:18 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 04 May 2015 21:06:18 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <55479517.7000803@gmail.com> References: <55479517.7000803@gmail.com> Message-ID: <1430787978.4335.7.camel@redhat.com> On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > Happy Star Wars Day! > May the Fourth be with you! > > So I have a strange Kerberos problem trying to figure out. On a > CLIENT, (CentOS 7.1) if I login to account "usera" they get a > ticket as > expected. However, if I login to a 6.6 client, it doesn't seem to > work. > Both were enrolled the same, obviously one is newer. > > Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login > as > root, bypassing kerberos, and then do "kinit admin" it works just > fine. > But if I do "kinit usera" I get: > > kinit: Generic preauthentication failure while getting initial > credentials > > Which makes no sense. The account works with a 7.1 client but not a > 6.x > client?? And yet "admin" works, no matter what. What am I missing > here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel From janellenicole80 at gmail.com Tue May 5 01:22:21 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 04 May 2015 18:22:21 -0700 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <1430787978.4335.7.camel@redhat.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> Message-ID: <55481B4D.9030509@gmail.com> On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >> Happy Star Wars Day! >> May the Fourth be with you! >> >> So I have a strange Kerberos problem trying to figure out. On a >> CLIENT, (CentOS 7.1) if I login to account "usera" they get a >> ticket as >> expected. However, if I login to a 6.6 client, it doesn't seem to >> work. >> Both were enrolled the same, obviously one is newer. >> >> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >> as >> root, bypassing kerberos, and then do "kinit admin" it works just >> fine. >> But if I do "kinit usera" I get: >> >> kinit: Generic preauthentication failure while getting initial >> credentials >> >> Which makes no sense. The account works with a 7.1 client but not a >> 6.x >> client?? And yet "admin" works, no matter what. What am I missing >> here? > If I had to guess, usera is enabled for OTP-only login. Is that > correct? > > If so, clients require RHEL 7.1 for OTP support. Also, the error you > are getting is the result of not enabling FAST support for OTP > authentication (see the -T option). > > Nathaniel Apparently I am not being clear. The user account can login all over the place with no problems -- RHEL 7.1 or 6.6. HOWEVER, on 7.1, a login provides a direct tgt, but no matter what you do on any other host using kinit (after logging in with an SSH key perhaps or as another user) and even know the password, you get this error. Again, logging in with the password, not OTP, works just fine. Confusing, ~J From dpal at redhat.com Tue May 5 01:24:31 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 May 2015 21:24:31 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <55481B4D.9030509@gmail.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481B4D.9030509@gmail.com> Message-ID: <55481BCF.2000901@redhat.com> On 05/04/2015 09:22 PM, Janelle wrote: > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >> On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >>> Happy Star Wars Day! >>> May the Fourth be with you! >>> >>> So I have a strange Kerberos problem trying to figure out. On a >>> CLIENT, (CentOS 7.1) if I login to account "usera" they get a >>> ticket as >>> expected. However, if I login to a 6.6 client, it doesn't seem to >>> work. >>> Both were enrolled the same, obviously one is newer. >>> >>> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >>> as >>> root, bypassing kerberos, and then do "kinit admin" it works just >>> fine. >>> But if I do "kinit usera" I get: >>> >>> kinit: Generic preauthentication failure while getting initial >>> credentials >>> >>> Which makes no sense. The account works with a 7.1 client but not a >>> 6.x >>> client?? And yet "admin" works, no matter what. What am I missing >>> here? >> If I had to guess, usera is enabled for OTP-only login. Is that >> correct? >> >> If so, clients require RHEL 7.1 for OTP support. Also, the error you >> are getting is the result of not enabling FAST support for OTP >> authentication (see the -T option). >> >> Nathaniel > Apparently I am not being clear. The user account can login all over > the place with no problems -- RHEL 7.1 or 6.6. HOWEVER, on 7.1, a > login provides a direct tgt, but no matter what you do on any other > host using kinit (after logging in with an SSH key perhaps or as > another user) and even know the password, you get this error. > > Again, logging in with the password, not OTP, works just fine. > > Confusing, > ~J > Do you get any SELinux AVCs? May be it is an issue of the ticket cache permissions/labels? -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From nagemnna at gmail.com Tue May 5 01:37:11 2015 From: nagemnna at gmail.com (Megan .) Date: Mon, 4 May 2015 21:37:11 -0400 Subject: [Freeipa-users] regex with sudo commands Message-ID: Good Evening! I'm running 3.0.0-42 on Centos 6.6. I setup a number of sudo commands today with regular expressions and now users seem to be having issues running any sudo command. Are there any known issues with having regex in sudo commands within the IPA server? Here is an example of a sudo rule I have setup. When my user runs sudo -ll he only sees the below command, and he should have a large number of commands available (like /sbin/service httpd restart) SSSD Role: deploy for UAT RunAsUsers: appusr Commands: /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* /usr/share/appusr/apache-ant-1.9.4/bin/ant -f /usr/share/appusr/onworld-tools/scripts/config_deploy.xml deploy-[a-zA-Z0-9\-] -Denv=uat I also purged /var/lib/sss/db and restated sssd thinking it might be related to caching but it didn't help. Thanks in advance! From janellenicole80 at gmail.com Tue May 5 01:38:29 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 04 May 2015 18:38:29 -0700 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <1430787978.4335.7.camel@redhat.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> Message-ID: <55481F15.9090507@gmail.com> On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >> Happy Star Wars Day! >> May the Fourth be with you! >> >> So I have a strange Kerberos problem trying to figure out. On a >> CLIENT, (CentOS 7.1) if I login to account "usera" they get a >> ticket as >> expected. However, if I login to a 6.6 client, it doesn't seem to >> work. >> Both were enrolled the same, obviously one is newer. >> >> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >> as >> root, bypassing kerberos, and then do "kinit admin" it works just >> fine. >> But if I do "kinit usera" I get: >> >> kinit: Generic preauthentication failure while getting initial >> credentials >> >> Which makes no sense. The account works with a 7.1 client but not a >> 6.x >> client?? And yet "admin" works, no matter what. What am I missing >> here? > If I had to guess, usera is enabled for OTP-only login. Is that > correct? > > If so, clients require RHEL 7.1 for OTP support. Also, the error you > are getting is the result of not enabling FAST support for OTP > authentication (see the -T option). > > Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J From christoph.kaminski at biotronik.com Tue May 5 05:42:07 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Tue, 5 May 2015 07:42:07 +0200 Subject: [Freeipa-users] Split Horizon DNS config Message-ID: Hi can someone validate this config for bind + split horizon (only the views part): acl internal { 127.0.0.1; 172.16.0.0/12; }; view "internal" { match-clients { internal; }; recursion yes; dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-HSO.socket"; arg "base cn=dns, dc=hso"; arg "fake_mname ipa-2.mgmt.hss.int."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/ipa-2.mgmt.hss.int"; arg "serial_autoincrement yes"; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; }; view "external" { match-clients { any; }; recursion yes; zone "mgmt.hss.int" { type master; file "mgmt.hss.int.db"; }; zone "in-addr.arpa" { type forward; forward only; forwarders { 172.16.8.210; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; }; it works but its a little bit unclean hack IMHO. Bind 9.9 in rhel7.1 doesnt support 'in-view' thats the reason why I use a the same host but the ip from internal acl her: zone "in-addr.arpa" { type forward; forward only; forwarders { 172.16.8.210; }; }; is there something what can make problems? MfG Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue May 5 08:31:08 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 05 May 2015 10:31:08 +0200 Subject: [Freeipa-users] Removing REALM requirement and home directory location In-Reply-To: <5434D6A65FEF2B428D5CC8D77FA7DA7106A41CD8@wexc201p.bsc.bscal.com> References: <5434D6A65FEF2B428D5CC8D77FA7DA7106A41CD8@wexc201p.bsc.bscal.com> Message-ID: <55487FCC.2090106@redhat.com> On 05/04/2015 08:50 PM, Redmond, Stacy wrote: > > I am running a RHEL7 IPA Server ipa-server 3.3.3-28 > > RHEL6 clients running IPA Client 3.0.0-42 > > I have setup an AD trust which works great, however I want to make it > so the users don?t have to use @realm to login and that their home > directory does not default to /home/realm/username > Also note that you can override the home directory location using the override_homedir directive. See man sssd.conf for more details. > AD sbx.local > > IPA unix.sbx.local > > Works great > > User login: ssh username at realm@hostname > > $ ssh aduser1 at sbx@linuxtest1.sbx.local > > aduser1 at sbx@linuxtest1.sbx.local's password: > > Last login: Fri May 1 09:36:53 2015 from xxx.xxx.xxx.xxx > > Could not chdir to home directory /home/sbx.local/aduser1: No such > file or directory > > $ > > Any and all help is appreciated. > > > Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue May 5 08:34:38 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 May 2015 10:34:38 +0200 Subject: [Freeipa-users] Cross Realm Authentication between two FreeIPA Servers In-Reply-To: <1915852054.11824660.1430579026608.JavaMail.zimbra@redhat.com> References: <209394969.11813499.1430568941473.JavaMail.zimbra@redhat.com> <1915852054.11824660.1430579026608.JavaMail.zimbra@redhat.com> Message-ID: <5548809E.7040504@redhat.com> On 05/02/2015 05:03 PM, Alexander Bokovoy wrote: > ----- Original Message ----- > >> Do we have any plans to implement in future? > Yes, once we get everything ready for fully working AD trusts support > (i.e. IPA users being able to login to Windows machines). The reason for that > is because we will be re-using the same infrastructure in both cases so > the code will largely be the same to drive both use cases. > > This is very important because then we don't need to update SSSD on the machines > where current AD trust feature is already supported -- they will be able to > operate with IPA-IPA trust the instant moment it is established. Actual process > of setting up IPA-IPA trust will be a bit different, of course, as we have better > ways to set the trust up in this case. BTW, this is the ticket you can use for tracking purposes: https://fedorahosted.org/freeipa/ticket/4867 Martin From mkosek at redhat.com Tue May 5 08:43:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 May 2015 10:43:42 +0200 Subject: [Freeipa-users] using pathlen:0 for freeipa's CA certificate? In-Reply-To: <554755A5.3080109@aixigo.de> References: <554755A5.3080109@aixigo.de> Message-ID: <554882BE.60806@redhat.com> On 05/04/2015 01:19 PM, Harald Dunkel wrote: > Hi folks, > > Instead of a self-signed certificate I would like to use an external > CA to sign freeipa's CSR ("ipa-server-install --external-ca"). > Question: > > Is pathlen:0, e.g. > > basicConstraints=critical,CA:TRUE, pathlen:0 > > sufficient for freeipa's CA certificate? I would say it should be sufficient for FreeIPA CA for now, given it does not allow subordinate CAs. However, I am still CCing Fraser and Honza for reference, in case there would be some limitation in Dogtag/our CA certificate that would limit use of the basicConstraints extension. Note that this basiConstrain would surely prevent you from using the upcoming feature http://www.freeipa.org/page/V4/Sub-CAs but this is OK with you, I assume. BTW, Fraser, we should record a task to properly watch for the pathlen limitation and have nice error messages around it when admin attempts to use Sub-CAs. Final note, there is a related ticket: https://fedorahosted.org/freeipa/ticket/3466 Martin From tbabej at redhat.com Tue May 5 08:49:28 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 05 May 2015 10:49:28 +0200 Subject: [Freeipa-users] regex with sudo commands In-Reply-To: References: Message-ID: <55488418.5030706@redhat.com> Hello! On 05/05/2015 03:37 AM, Megan . wrote: > Good Evening! > > I'm running 3.0.0-42 on Centos 6.6. > > I setup a number of sudo commands today with regular expressions and > now users seem to be having issues running any sudo command. Are > there any known issues with having regex in sudo commands within the > IPA server? > > Here is an example of a sudo rule I have setup. When my user runs > sudo -ll he only sees the below command, and he should have a large > number of commands available (like /sbin/service httpd restart) > > SSSD Role: deploy for UAT > RunAsUsers: appusr > Commands: > /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py > -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* > /usr/share/appusr/apache-ant-1.9.4/bin/ant -f > /usr/share/appusr/onworld-tools/scripts/config_deploy.xml > deploy-[a-zA-Z0-9\-] -Denv=uat As far as I know, sudo does not support regular expressions in sudo rules. It supports wildcards however, but that's not the same thing, even though syntax is similiar. The matching is done using the glob(3) and fnmatch(3) functions. See man sudoers, section wildcards. Also, I don't think the sudo -ll expands the sudo commands with wildcards. I just tried it with simple '/sbin/m*', and I see Sudoers entry: RunAsUsers: root Commands: /sbin/m* Things work as expected, with me being able to execute executables in sbin starting with the letter m. > > > I also purged /var/lib/sss/db and restated sssd thinking it might be > related to caching but it didn't help. > > Thanks in advance! > HTH, Tomas From jhrozek at redhat.com Tue May 5 08:50:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 5 May 2015 10:50:28 +0200 Subject: [Freeipa-users] regex with sudo commands In-Reply-To: References: Message-ID: <20150505085028.GO25659@hendrix.arn.redhat.com> On Mon, May 04, 2015 at 09:37:11PM -0400, Megan . wrote: > Good Evening! > > I'm running 3.0.0-42 on Centos 6.6. > > I setup a number of sudo commands today with regular expressions and > now users seem to be having issues running any sudo command. Are > there any known issues with having regex in sudo commands within the > IPA server? > > Here is an example of a sudo rule I have setup. When my user runs > sudo -ll he only sees the below command, and he should have a large > number of commands available (like /sbin/service httpd restart) > > SSSD Role: deploy for UAT > RunAsUsers: appusr > Commands: > /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py > -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* > /usr/share/appusr/apache-ant-1.9.4/bin/ant -f > /usr/share/appusr/onworld-tools/scripts/config_deploy.xml > deploy-[a-zA-Z0-9\-] -Denv=uat > > > I also purged /var/lib/sss/db and restated sssd thinking it might be > related to caching but it didn't help. > > Thanks in advance! Pavel (CC) might have a better idea but I think we need to see the logs and the ldb cache dump to make sure we're storing the value exactly as we should. From mkosek at redhat.com Tue May 5 08:53:06 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 May 2015 10:53:06 +0200 Subject: [Freeipa-users] regex with sudo commands In-Reply-To: References: Message-ID: <554884F2.3070509@redhat.com> On 05/05/2015 03:37 AM, Megan . wrote: > Good Evening! > > I'm running 3.0.0-42 on Centos 6.6. > > I setup a number of sudo commands today with regular expressions and > now users seem to be having issues running any sudo command. Are > there any known issues with having regex in sudo commands within the > IPA server? > > Here is an example of a sudo rule I have setup. When my user runs > sudo -ll he only sees the below command, and he should have a large > number of commands available (like /sbin/service httpd restart) > > SSSD Role: deploy for UAT > RunAsUsers: appusr > Commands: > /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py > -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* > /usr/share/appusr/apache-ant-1.9.4/bin/ant -f > /usr/share/appusr/onworld-tools/scripts/config_deploy.xml > deploy-[a-zA-Z0-9\-] -Denv=uat > > > I also purged /var/lib/sss/db and restated sssd thinking it might be > related to caching but it didn't help. > > Thanks in advance! > CCing Pavel Brezina for reference as the sudo guru, but I think he will miss more information for your bug. For example, it would help to show the SUDO commands for IPA that should be applied for the respective users: $ ipa sudorule-show ... Martin From pbrezina at redhat.com Tue May 5 09:35:19 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Tue, 05 May 2015 11:35:19 +0200 Subject: [Freeipa-users] regex with sudo commands In-Reply-To: <554884F2.3070509@redhat.com> References: <554884F2.3070509@redhat.com> Message-ID: <55488ED7.5000201@redhat.com> On 05/05/2015 10:53 AM, Martin Kosek wrote: > On 05/05/2015 03:37 AM, Megan . wrote: >> Good Evening! >> >> I'm running 3.0.0-42 on Centos 6.6. >> >> I setup a number of sudo commands today with regular expressions and >> now users seem to be having issues running any sudo command. Are >> there any known issues with having regex in sudo commands within the >> IPA server? >> >> Here is an example of a sudo rule I have setup. When my user runs >> sudo -ll he only sees the below command, and he should have a large >> number of commands available (like /sbin/service httpd restart) >> >> SSSD Role: deploy for UAT >> RunAsUsers: appusr >> Commands: >> /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py >> -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* >> /usr/share/appusr/apache-ant-1.9.4/bin/ant -f >> /usr/share/appusr/onworld-tools/scripts/config_deploy.xml >> deploy-[a-zA-Z0-9\-] -Denv=uat >> >> >> I also purged /var/lib/sss/db and restated sssd thinking it might be >> related to caching but it didn't help. >> >> Thanks in advance! >> > > CCing Pavel Brezina for reference as the sudo guru, but I think he will miss > more information for your bug. For example, it would help to show the SUDO > commands for IPA that should be applied for the respective users: > > $ ipa sudorule-show ... > > Martin > I believe Tomas already provided the correct answer. From nagemnna at gmail.com Tue May 5 09:36:12 2015 From: nagemnna at gmail.com (Megan .) Date: Tue, 5 May 2015 05:36:12 -0400 Subject: [Freeipa-users] regex with sudo commands In-Reply-To: <55488ED7.5000201@redhat.com> References: <554884F2.3070509@redhat.com> <55488ED7.5000201@redhat.com> Message-ID: Ok, Thank you. On Tue, May 5, 2015 at 5:35 AM, Pavel B?ezina wrote: > On 05/05/2015 10:53 AM, Martin Kosek wrote: >> >> On 05/05/2015 03:37 AM, Megan . wrote: >>> >>> Good Evening! >>> >>> I'm running 3.0.0-42 on Centos 6.6. >>> >>> I setup a number of sudo commands today with regular expressions and >>> now users seem to be having issues running any sudo command. Are >>> there any known issues with having regex in sudo commands within the >>> IPA server? >>> >>> Here is an example of a sudo rule I have setup. When my user runs >>> sudo -ll he only sees the below command, and he should have a large >>> number of commands available (like /sbin/service httpd restart) >>> >>> SSSD Role: deploy for UAT >>> RunAsUsers: appusr >>> Commands: >>> /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py >>> -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* >>> /usr/share/appusr/apache-ant-1.9.4/bin/ant -f >>> /usr/share/appusr/onworld-tools/scripts/config_deploy.xml >>> deploy-[a-zA-Z0-9\-] -Denv=uat >>> >>> >>> I also purged /var/lib/sss/db and restated sssd thinking it might be >>> related to caching but it didn't help. >>> >>> Thanks in advance! >>> >> >> CCing Pavel Brezina for reference as the sudo guru, but I think he will >> miss >> more information for your bug. For example, it would help to show the SUDO >> commands for IPA that should be applied for the respective users: >> >> $ ipa sudorule-show ... >> >> Martin >> > > I believe Tomas already provided the correct answer. From vaclav.adamec at suchy-zleb.cz Tue May 5 10:38:35 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 5 May 2015 12:38:35 +0200 Subject: [Freeipa-users] IPA RUV unable to decode Message-ID: Hi, I tried migrate to newest version IPA, but result is quite unstable and removing old replicas ends with RUV which cannot be decoded (it stucked in queue forever): ipa-replica-manage del ipa-master-dmz002.test.com -fc Cleaning a master is irreversible. This should not normally be require, so use cautiously. Continue to clean master? [no]: yes ipa-replica-manage list-ruv unable to decode: {replica 8} 55091239000400080000 55091239000400080000 unable to decode: {replica 7} 552f84cd000300070000 552f84cd000300070000 unable to decode: {replica 11} 551a42f70000000b0000 551aa3140001000b0000 unable to decode: {replica 15} 551e82e10001000f0000 551e82e10001000f0000 unable to decode: {replica 14} 551e82ec0001000e0000 551e82ec0001000e0000 unable to decode: {replica 20} 552f4b72000600140000 552f4b72000600140000 unable to decode: {replica 10} 551a25af0001000a0000 551a25af0001000a0000 unable to decode: {replica 3} 551e864c000300030000 551e864c000300030000 unable to decode: {replica 5} 55083ad2000300050000 55083ad2000300050000 unable to decode: {replica 9} 550913e7000000090000 550913e7000000090000 unable to decode: {replica 19} 55210193000300130000 55210193000300130000 unable to decode: {replica 12} 551a48290000000c0000 551a48c50000000c0000 ipa-master-dmz001.test.com:389: 25 ipa-master-dmz002.test.com:389: 21 it is possible to clear this queue and leave only valid servers ? Thanks in advance ipa-client-4.1.0-18.el7_1.3.x86_64 ipa-server-4.1.0-18.el7_1.3.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue May 5 11:27:40 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 May 2015 13:27:40 +0200 Subject: [Freeipa-users] IPA RUV unable to decode In-Reply-To: References: Message-ID: <5548A92C.2070602@redhat.com> On 05/05/2015 12:38 PM, Vaclav Adamec wrote: > Hi, > I tried migrate to newest version IPA, but result is quite unstable and > removing old replicas ends with RUV which cannot be decoded (it stucked in > queue forever): > > ipa-replica-manage del ipa-master-dmz002.test.com -fc > Cleaning a master is irreversible. > This should not normally be require, so use cautiously. > Continue to clean master? [no]: yes > > ipa-replica-manage list-ruv > unable to decode: {replica 8} 55091239000400080000 55091239000400080000 > unable to decode: {replica 7} 552f84cd000300070000 552f84cd000300070000 > unable to decode: {replica 11} 551a42f70000000b0000 551aa3140001000b0000 > unable to decode: {replica 15} 551e82e10001000f0000 551e82e10001000f0000 > unable to decode: {replica 14} 551e82ec0001000e0000 551e82ec0001000e0000 > unable to decode: {replica 20} 552f4b72000600140000 552f4b72000600140000 > unable to decode: {replica 10} 551a25af0001000a0000 551a25af0001000a0000 > unable to decode: {replica 3} 551e864c000300030000 551e864c000300030000 > unable to decode: {replica 5} 55083ad2000300050000 55083ad2000300050000 > unable to decode: {replica 9} 550913e7000000090000 550913e7000000090000 > unable to decode: {replica 19} 55210193000300130000 55210193000300130000 > unable to decode: {replica 12} 551a48290000000c0000 551a48c50000000c0000 > ipa-master-dmz001.test.com:389: 25 > ipa-master-dmz002.test.com:389: 21 > > it is possible to clear this queue and leave only valid servers ? > > Thanks in advance > > ipa-client-4.1.0-18.el7_1.3.x86_64 > ipa-server-4.1.0-18.el7_1.3.x86_64 Ludwig or Thierry, do you know? The questions about RUV cleaning seems to be recurring, I suspect there will be a pattern (bug) and not just configuration issue. From lkrispen at redhat.com Tue May 5 11:49:59 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 05 May 2015 13:49:59 +0200 Subject: [Freeipa-users] IPA RUV unable to decode In-Reply-To: <5548A92C.2070602@redhat.com> References: <5548A92C.2070602@redhat.com> Message-ID: <5548AE67.5050202@redhat.com> On 05/05/2015 01:27 PM, Martin Kosek wrote: > On 05/05/2015 12:38 PM, Vaclav Adamec wrote: >> Hi, >> I tried migrate to newest version IPA, but result is quite unstable and >> removing old replicas ends with RUV which cannot be decoded (it stucked in >> queue forever): >> >> ipa-replica-manage del ipa-master-dmz002.test.com -fc >> Cleaning a master is irreversible. >> This should not normally be require, so use cautiously. >> Continue to clean master? [no]: yes >> >> ipa-replica-manage list-ruv >> unable to decode: {replica 8} 55091239000400080000 55091239000400080000 >> unable to decode: {replica 7} 552f84cd000300070000 552f84cd000300070000 >> unable to decode: {replica 11} 551a42f70000000b0000 551aa3140001000b0000 >> unable to decode: {replica 15} 551e82e10001000f0000 551e82e10001000f0000 >> unable to decode: {replica 14} 551e82ec0001000e0000 551e82ec0001000e0000 >> unable to decode: {replica 20} 552f4b72000600140000 552f4b72000600140000 >> unable to decode: {replica 10} 551a25af0001000a0000 551a25af0001000a0000 >> unable to decode: {replica 3} 551e864c000300030000 551e864c000300030000 >> unable to decode: {replica 5} 55083ad2000300050000 55083ad2000300050000 >> unable to decode: {replica 9} 550913e7000000090000 550913e7000000090000 >> unable to decode: {replica 19} 55210193000300130000 55210193000300130000 >> unable to decode: {replica 12} 551a48290000000c0000 551a48c50000000c0000 >> ipa-master-dmz001.test.com:389: 25 >> ipa-master-dmz002.test.com:389: 21 >> >> it is possible to clear this queue and leave only valid servers ? >> >> Thanks in advance >> >> ipa-client-4.1.0-18.el7_1.3.x86_64 >> ipa-server-4.1.0-18.el7_1.3.x86_64 > Ludwig or Thierry, do you know? The questions about RUV cleaning seems to be > recurring, I suspect there will be a pattern (bug) and not just configuration > issue. we have seen this in a recent thread, and it is clear that the RUV is corrupted and cannot be decoded, but we don't have a scenario how this is state is reached. From dpal at redhat.com Tue May 5 13:47:18 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 05 May 2015 09:47:18 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <55481F15.9090507@gmail.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> Message-ID: <5548C9E6.6050306@redhat.com> On 05/04/2015 09:38 PM, Janelle wrote: > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >> On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >>> Happy Star Wars Day! >>> May the Fourth be with you! >>> >>> So I have a strange Kerberos problem trying to figure out. On a >>> CLIENT, (CentOS 7.1) if I login to account "usera" they get a >>> ticket as >>> expected. However, if I login to a 6.6 client, it doesn't seem to >>> work. >>> Both were enrolled the same, obviously one is newer. >>> >>> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >>> as >>> root, bypassing kerberos, and then do "kinit admin" it works just >>> fine. >>> But if I do "kinit usera" I get: >>> >>> kinit: Generic preauthentication failure while getting initial >>> credentials >>> >>> Which makes no sense. The account works with a 7.1 client but not a >>> 6.x >>> client?? And yet "admin" works, no matter what. What am I missing >>> here? >> If I had to guess, usera is enabled for OTP-only login. Is that >> correct? >> >> If so, clients require RHEL 7.1 for OTP support. Also, the error you >> are getting is the result of not enabling FAST support for OTP >> authentication (see the -T option). >> >> Nathaniel > Ok, this did give me an idea (Thanks Nathaniel) -- the account was > set for BOTH "password" and OTP. > Apparently setting both does nothing. Yes a user can login with their > password-only, but trying to use kinit does not work. > > I am not sure I understand where the FAST support or the -T option is > to be applied. On kinit? That does not seem correct. Perhaps I am > misunderstanding this option? > > ~J > If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From mareynol at redhat.com Tue May 5 14:49:10 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Tue, 05 May 2015 10:49:10 -0400 Subject: [Freeipa-users] IPA RUV unable to decode In-Reply-To: <5548AE67.5050202@redhat.com> References: <5548A92C.2070602@redhat.com> <5548AE67.5050202@redhat.com> Message-ID: <5548D866.7030606@redhat.com> On 05/05/2015 07:49 AM, Ludwig Krispenz wrote: > > On 05/05/2015 01:27 PM, Martin Kosek wrote: >> On 05/05/2015 12:38 PM, Vaclav Adamec wrote: >>> Hi, >>> I tried migrate to newest version IPA, but result is quite >>> unstable and >>> removing old replicas ends with RUV which cannot be decoded (it >>> stucked in >>> queue forever): >>> >>> ipa-replica-manage del ipa-master-dmz002.test.com -fc >>> Cleaning a master is irreversible. >>> This should not normally be require, so use cautiously. >>> Continue to clean master? [no]: yes >>> >>> ipa-replica-manage list-ruv >>> unable to decode: {replica 8} 55091239000400080000 55091239000400080000 >>> unable to decode: {replica 7} 552f84cd000300070000 552f84cd000300070000 >>> unable to decode: {replica 11} 551a42f70000000b0000 >>> 551aa3140001000b0000 >>> unable to decode: {replica 15} 551e82e10001000f0000 >>> 551e82e10001000f0000 >>> unable to decode: {replica 14} 551e82ec0001000e0000 >>> 551e82ec0001000e0000 >>> unable to decode: {replica 20} 552f4b72000600140000 >>> 552f4b72000600140000 >>> unable to decode: {replica 10} 551a25af0001000a0000 >>> 551a25af0001000a0000 >>> unable to decode: {replica 3} 551e864c000300030000 551e864c000300030000 >>> unable to decode: {replica 5} 55083ad2000300050000 55083ad2000300050000 >>> unable to decode: {replica 9} 550913e7000000090000 550913e7000000090000 >>> unable to decode: {replica 19} 55210193000300130000 >>> 55210193000300130000 >>> unable to decode: {replica 12} 551a48290000000c0000 >>> 551a48c50000000c0000 >>> ipa-master-dmz001.test.com:389: 25 >>> ipa-master-dmz002.test.com:389: 21 >>> >>> it is possible to clear this queue and leave only valid servers ? >>> >>> Thanks in advance >>> >>> ipa-client-4.1.0-18.el7_1.3.x86_64 >>> ipa-server-4.1.0-18.el7_1.3.x86_64 >> Ludwig or Thierry, do you know? The questions about RUV cleaning >> seems to be >> recurring, I suspect there will be a pattern (bug) and not just >> configuration >> issue. > we have seen this in a recent thread, and it is clear that the RUV is > corrupted and cannot be decoded, but we don't have a scenario how this > is state is reached. The cleaning task (cleanAllRUV) can remove these invalid replica RUVs (RUV's missing the ldap URL). To reproduce these "invalid" RUV's it requires replication being disabled and re-enabled with a different replica id. To manually clean these invalid RUV elements, outside of using the IPA CLI, you can directly issue the cleanAllRUV task to the Directory Server using ldapmodify: # ldapmodify -D "cn=directory manager" -W -a dn: cn=clean 8, cn=cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc=example,dc=com replica-id: 8 cn: clean 8 Run these one at a time, as there is a current limit of running 4 concurrent tasks. It is best to monitor the Directory Server errors log, or search on the task entry itself, to see when it has finished before firing off the next task. For more on using cleanAllRUV see: http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv http://www.port389.org/docs/389ds/design/cleanallruv-design.html Regards, Mark From nathan at nathanpeters.com Tue May 5 16:09:51 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Tue, 5 May 2015 09:09:51 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues Message-ID: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> I am having some strange issues after upgrade from FreeIPA 4.1.2 to 4.1.3/4.1.4 on CentOS 7. Here is my setup: FreeIPA domain : ipadomain.net Trusted AD domain : sub.addomain.net In my AD domain, we have our UPN set to addomain.net so users typically login as username at addomain.net instead of username at sub.addomain.net. In my /etc/sssd/sssd.conf on the ipa dc I have the following values set: use_fully_qualified_names = True [sssd] default_domain_suffix = sub.addomain.net This is what I see in the logs when I attempt to login as 'username' (with do domain): May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: Cannot find KDC for realm "ADDOMAIN.NET" May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: Cannot find KDC for realm "ADDOMAIN.NET" May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=username May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): received for user username: 4 (System error) May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for username from 10.5.5.57 port 53118 ssh2 However, if in AD I switch the UPN on 'username' to the default of 'sub.addomain.net' I get a successful login: May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=username May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=username May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for username from 10.5.5.57 port 46077 ssh2 May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting user-1539201103.slice. May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice user-1539201103.slice. May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of user username at sub.addomain.net. May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user username at sub.addomain.net. May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of user username at sub.addomain.net. May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session): session opened for user username by (uid=0) As a temporary workaround I set dns_lookup_kdc = false in my /etc/krb5.conf file and that worked to allow me to login with just 'username' but even after a successful login, I was seeing those 'cannot find KDC for realm' message in the log. Is there a proper way to allow people from a trusted AD domain to login with their alternative UPNs? From sbose at redhat.com Tue May 5 16:39:59 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 5 May 2015 18:39:59 +0200 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> Message-ID: <20150505163959.GV3267@p.redhat.com> On Tue, May 05, 2015 at 09:09:51AM -0700, nathan at nathanpeters.com wrote: > I am having some strange issues after upgrade from FreeIPA 4.1.2 to > 4.1.3/4.1.4 on CentOS 7. > > Here is my setup: > FreeIPA domain : ipadomain.net > Trusted AD domain : sub.addomain.net > > In my AD domain, we have our UPN set to addomain.net so users typically > login as username at addomain.net instead of username at sub.addomain.net. > > In my /etc/sssd/sssd.conf on the ipa dc I have the following values set: > use_fully_qualified_names = True > [sssd] > default_domain_suffix = sub.addomain.net > > > This is what I see in the logs when I attempt to login as 'username' (with > do domain): > > May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: > Cannot find KDC for realm "ADDOMAIN.NET" > May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: > Cannot find KDC for realm "ADDOMAIN.NET" > May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=username > May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): > received for user username: 4 (System error) > May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for > username from 10.5.5.57 port 53118 ssh2 > > However, if in AD I switch the UPN on 'username' to the default of > 'sub.addomain.net' I get a successful login: > > May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=username > May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth): > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=username > May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for > username from 10.5.5.57 port 46077 ssh2 > May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting > user-1539201103.slice. > May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice > user-1539201103.slice. > May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of > user username at sub.addomain.net. > May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user > username at sub.addomain.net. > May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of > user username at sub.addomain.net. > May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session): > session opened for user username by (uid=0) > > As a temporary workaround I set dns_lookup_kdc = false in my > /etc/krb5.conf file and that worked to allow me to login with just > 'username' but even after a successful login, I was seeing those 'cannot > find KDC for realm' message in the log. > > Is there a proper way to allow people from a trusted AD domain to login > with their alternative UPNs? I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET section to the realms section of /etc/krb5.conf to all IPA clients and servers. Although SSSD as a client in a AD domain can handle those UPNs there is a missing part on the FreeIPA server side which is needed to make it work. The item is tracked in https://fedorahosted.org/freeipa/ticket/3559 . Since the UPN-suffix can be freely chosen, i.e. it does not have to be a DNS domain, the client will ask it's local KDC with a special so called enterprise principal if it knows about this UPN suffix and if the KDC knows about it it will tell the client where to ask for it. IF ticket #3559 gets implemented the entry in /etc/krb5.conf would not be needed anymore. HTH bye, Sumit > > > -- > 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 From nathan at nathanpeters.com Tue May 5 16:47:32 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Tue, 5 May 2015 09:47:32 -0700 Subject: [Freeipa-users] FreeIPA 4.1.4 Strange winbindd errors Message-ID: I am getting some really strange winbindd errors in my logs on a new install of FreeIPA 4.1.4 server. Any ideas what these mean? This is on the server, so I don't see how the server could not contact itself. The kerberos service is definitely running on this server because i can kinit and klist just fine. All relevant firewall ports are open. SELinux is disabled. May 05 16:41:20 dc1.mydomain.net winbindd[8377]: [2015/05/05 16:41:20.469497, 0] ipa_sam.c:4144(bind_callback_cleanup) May 05 16:41:20 dc1.mydomain.net winbindd[8377]: kerberos error: code=-1765328228, message=Cannot contact any KDC for realm 'MYDOMAIN.NET' May 05 16:41:20 dc1.mydomain.net winbindd[8377]: [2015/05/05 16:41:20.469712, 0] ../source3/lib/smbldap.c:998(smbldap_connect_system) May 05 16:41:20 dc1.mydomain.net winbindd[8377]: failed to bind to server ldapi://%2fvar%2frun%2fslapd-MYDOMAIN-NET.socket with dn="[Anonymous bind]" Error: Local error May 05 16:41:20 dc1.mydomain.net winbindd[8377]: (unknown) From nathan at nathanpeters.com Tue May 5 16:53:38 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Tue, 5 May 2015 09:53:38 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <20150505163959.GV3267@p.redhat.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> Message-ID: Hmm, so if this is the [realms] section of my /etc/krb5.conf what do I have to do ? [realms] IPADOMAIN.NET = { kdc = dc1.ipadomain.net:88 master_kdc = dc1.ipadomain.net:88 admin_server = dc1.ipadomain.net:749 default_domain = ipadomain.net pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/ auth_to_local = DEFAULT } Would I just literally copy that section and change the names? eg: SUB.ADDOMAIN.NET = { kdc = dc1.ipadomain.net:88 master_kdc = dc1.ipadomain.net:88 admin_server = dc1.ipadomain.net:749 default_domain = ipadomain.net pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/ auth_to_local = DEFAULT } > On Tue, May 05, 2015 at 09:09:51AM -0700, nathan at nathanpeters.com wrote: >> I am having some strange issues after upgrade from FreeIPA 4.1.2 to >> 4.1.3/4.1.4 on CentOS 7. >> >> Here is my setup: >> FreeIPA domain : ipadomain.net >> Trusted AD domain : sub.addomain.net >> >> In my AD domain, we have our UPN set to addomain.net so users typically >> login as username at addomain.net instead of username at sub.addomain.net. >> >> In my /etc/sssd/sssd.conf on the ipa dc I have the following values set: >> use_fully_qualified_names = True >> [sssd] >> default_domain_suffix = sub.addomain.net >> >> >> This is what I see in the logs when I attempt to login as 'username' >> (with >> do domain): >> >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: >> Cannot find KDC for realm "ADDOMAIN.NET" >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: >> Cannot find KDC for realm "ADDOMAIN.NET" >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=username >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): >> received for user username: 4 (System error) >> May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for >> username from 10.5.5.57 port 53118 ssh2 >> >> However, if in AD I switch the UPN on 'username' to the default of >> 'sub.addomain.net' I get a successful login: >> >> May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=username >> May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth): >> authentication success; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=username >> May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for >> username from 10.5.5.57 port 46077 ssh2 >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting >> user-1539201103.slice. >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice >> user-1539201103.slice. >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of >> user username at sub.addomain.net. >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of >> user >> username at sub.addomain.net. >> May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 >> of >> user username at sub.addomain.net. >> May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session): >> session opened for user username by (uid=0) >> >> As a temporary workaround I set dns_lookup_kdc = false in my >> /etc/krb5.conf file and that worked to allow me to login with just >> 'username' but even after a successful login, I was seeing those 'cannot >> find KDC for realm' message in the log. >> >> Is there a proper way to allow people from a trusted AD domain to login >> with their alternative UPNs? > > I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET > section to the realms section of /etc/krb5.conf to all IPA clients and > servers. > > Although SSSD as a client in a AD domain can handle those UPNs there is > a missing part on the FreeIPA server side which is needed to make it > work. The item is tracked in > https://fedorahosted.org/freeipa/ticket/3559 . > > Since the UPN-suffix can be freely chosen, i.e. it does not have to be a > DNS domain, the client will ask it's local KDC with a special so called > enterprise principal if it knows about this UPN suffix and if the KDC > knows about it it will tell the client where to ask for it. IF ticket > #3559 gets implemented the entry in /etc/krb5.conf would not be needed > anymore. > > HTH > > bye, > Sumit > >> >> >> -- >> 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 > From vaclav.adamec at suchy-zleb.cz Tue May 5 18:11:14 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 5 May 2015 20:11:14 +0200 Subject: [Freeipa-users] IPA RUV unable to decode In-Reply-To: <5548D866.7030606@redhat.com> References: <5548A92C.2070602@redhat.com> <5548AE67.5050202@redhat.com> <5548D866.7030606@redhat.com> Message-ID: Ok, so removing all replicas + uninstall and remove all ruv (except master) via cleanruv script seems to works. Thanks everybody for help, I'll try it in production now Vasek On Tue, May 5, 2015 at 4:49 PM, Mark Reynolds wrote: > > > On 05/05/2015 07:49 AM, Ludwig Krispenz wrote: > >> >> On 05/05/2015 01:27 PM, Martin Kosek wrote: >> >>> On 05/05/2015 12:38 PM, Vaclav Adamec wrote: >>> >>>> Hi, >>>> I tried migrate to newest version IPA, but result is quite unstable >>>> and >>>> removing old replicas ends with RUV which cannot be decoded (it stucked >>>> in >>>> queue forever): >>>> >>>> ipa-replica-manage del ipa-master-dmz002.test.com -fc >>>> Cleaning a master is irreversible. >>>> This should not normally be require, so use cautiously. >>>> Continue to clean master? [no]: yes >>>> >>>> ipa-replica-manage list-ruv >>>> unable to decode: {replica 8} 55091239000400080000 55091239000400080000 >>>> unable to decode: {replica 7} 552f84cd000300070000 552f84cd000300070000 >>>> unable to decode: {replica 11} 551a42f70000000b0000 551aa3140001000b0000 >>>> unable to decode: {replica 15} 551e82e10001000f0000 551e82e10001000f0000 >>>> unable to decode: {replica 14} 551e82ec0001000e0000 551e82ec0001000e0000 >>>> unable to decode: {replica 20} 552f4b72000600140000 552f4b72000600140000 >>>> unable to decode: {replica 10} 551a25af0001000a0000 551a25af0001000a0000 >>>> unable to decode: {replica 3} 551e864c000300030000 551e864c000300030000 >>>> unable to decode: {replica 5} 55083ad2000300050000 55083ad2000300050000 >>>> unable to decode: {replica 9} 550913e7000000090000 550913e7000000090000 >>>> unable to decode: {replica 19} 55210193000300130000 55210193000300130000 >>>> unable to decode: {replica 12} 551a48290000000c0000 551a48c50000000c0000 >>>> ipa-master-dmz001.test.com:389: 25 >>>> ipa-master-dmz002.test.com:389: 21 >>>> >>>> it is possible to clear this queue and leave only valid servers ? >>>> >>>> Thanks in advance >>>> >>>> ipa-client-4.1.0-18.el7_1.3.x86_64 >>>> ipa-server-4.1.0-18.el7_1.3.x86_64 >>>> >>> Ludwig or Thierry, do you know? The questions about RUV cleaning seems >>> to be >>> recurring, I suspect there will be a pattern (bug) and not just >>> configuration >>> issue. >>> >> we have seen this in a recent thread, and it is clear that the RUV is >> corrupted and cannot be decoded, but we don't have a scenario how this is >> state is reached. >> > The cleaning task (cleanAllRUV) can remove these invalid replica RUVs > (RUV's missing the ldap URL). To reproduce these "invalid" RUV's it > requires replication being disabled and re-enabled with a different replica > id. > > To manually clean these invalid RUV elements, outside of using the IPA > CLI, you can directly issue the cleanAllRUV task to the Directory Server > using ldapmodify: > > # ldapmodify -D "cn=directory manager" -W -a > dn: cn=clean 8, cn=cleanallruv, cn=tasks, cn=config > objectclass: extensibleObject > replica-base-dn: dc=example,dc=com > replica-id: 8 > cn: clean 8 > > Run these one at a time, as there is a current limit of running 4 > concurrent tasks. It is best to monitor the Directory Server errors log, > or search on the task entry itself, to see when it has finished before > firing off the next task. > > For more on using cleanAllRUV see: > > http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv > http://www.port389.org/docs/389ds/design/cleanallruv-design.html > > Regards, > Mark > > -- > 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 > -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Tue May 5 18:12:49 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Tue, 5 May 2015 11:12:49 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <20150505163959.GV3267@p.redhat.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> Message-ID: <510a34431f3394aff3d5bb92b72dd1c4.squirrel@webmail.nathanpeters.com> FYI, this is what I get when I added another realm section to my /etc/krb5.conf May 05 18:00:26 dc1.ipadomain.net [sssd[krb5_child[2792]]][2792]: Looping detected inside krb5_get_in_tkt May 05 18:00:26 dc1.ipadomain.net [sssd[krb5_child[2792]]][2792]: Looping detected inside krb5_get_in_tkt May 05 18:00:26 dc1.ipadomain.net sshd[2789]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=username May 05 18:00:26 dc1.ipadomain.net sshd[2789]: pam_sss(sshd:auth): received for user username: 4 (System error) May 05 18:00:27 dc1.ipadomain.net sshd[2789]: Failed password for username from 10.5.5.57 port 54775 ssh2 Here is what I added ADDOMAIN.NET = { kdc = dc1.ipadomain.net:88 master_kdc = dc1.ipadomain.net:88 admin_server = dc1.ipadomain.net:749 } > On Tue, May 05, 2015 at 09:09:51AM -0700, nathan at nathanpeters.com wrote: >> I am having some strange issues after upgrade from FreeIPA 4.1.2 to >> 4.1.3/4.1.4 on CentOS 7. >> >> Here is my setup: >> FreeIPA domain : ipadomain.net >> Trusted AD domain : sub.addomain.net >> >> In my AD domain, we have our UPN set to addomain.net so users typically >> login as username at addomain.net instead of username at sub.addomain.net. >> >> In my /etc/sssd/sssd.conf on the ipa dc I have the following values set: >> use_fully_qualified_names = True >> [sssd] >> default_domain_suffix = sub.addomain.net >> >> >> This is what I see in the logs when I attempt to login as 'username' >> (with >> do domain): >> >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: >> Cannot find KDC for realm "ADDOMAIN.NET" >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: >> Cannot find KDC for realm "ADDOMAIN.NET" >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=username >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): >> received for user username: 4 (System error) >> May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for >> username from 10.5.5.57 port 53118 ssh2 >> >> However, if in AD I switch the UPN on 'username' to the default of >> 'sub.addomain.net' I get a successful login: >> >> May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=username >> May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth): >> authentication success; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=username >> May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for >> username from 10.5.5.57 port 46077 ssh2 >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting >> user-1539201103.slice. >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice >> user-1539201103.slice. >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of >> user username at sub.addomain.net. >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of >> user >> username at sub.addomain.net. >> May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 >> of >> user username at sub.addomain.net. >> May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session): >> session opened for user username by (uid=0) >> >> As a temporary workaround I set dns_lookup_kdc = false in my >> /etc/krb5.conf file and that worked to allow me to login with just >> 'username' but even after a successful login, I was seeing those 'cannot >> find KDC for realm' message in the log. >> >> Is there a proper way to allow people from a trusted AD domain to login >> with their alternative UPNs? > > I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET > section to the realms section of /etc/krb5.conf to all IPA clients and > servers. > > Although SSSD as a client in a AD domain can handle those UPNs there is > a missing part on the FreeIPA server side which is needed to make it > work. The item is tracked in > https://fedorahosted.org/freeipa/ticket/3559 . > > Since the UPN-suffix can be freely chosen, i.e. it does not have to be a > DNS domain, the client will ask it's local KDC with a special so called > enterprise principal if it knows about this UPN suffix and if the KDC > knows about it it will tell the client where to ask for it. IF ticket > #3559 gets implemented the entry in /etc/krb5.conf would not be needed > anymore. > > HTH > > bye, > Sumit > >> >> >> -- >> 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 > From sbose at redhat.com Tue May 5 18:28:40 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 5 May 2015 20:28:40 +0200 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> Message-ID: <20150505182840.GW3267@p.redhat.com> On Tue, May 05, 2015 at 09:53:38AM -0700, nathan at nathanpeters.com wrote: > Hmm, so if this is the [realms] section of my /etc/krb5.conf what do I > have to do ? > > [realms] > IPADOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = > RULE:[1:$1@$0](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/ > auth_to_local = DEFAULT > } > > Would I just literally copy that section and change the names? > eg: > > SUB.ADDOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net you should add the AD DC and AD realm here The following lines you can just drop. HTH bye, Sumit > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = > RULE:[1:$1@$0](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/ > auth_to_local = DEFAULT > } > > > > On Tue, May 05, 2015 at 09:09:51AM -0700, nathan at nathanpeters.com wrote: > >> I am having some strange issues after upgrade from FreeIPA 4.1.2 to > >> 4.1.3/4.1.4 on CentOS 7. > >> > >> Here is my setup: > >> FreeIPA domain : ipadomain.net > >> Trusted AD domain : sub.addomain.net > >> > >> In my AD domain, we have our UPN set to addomain.net so users typically > >> login as username at addomain.net instead of username at sub.addomain.net. > >> > >> In my /etc/sssd/sssd.conf on the ipa dc I have the following values set: > >> use_fully_qualified_names = True > >> [sssd] > >> default_domain_suffix = sub.addomain.net > >> > >> > >> This is what I see in the logs when I attempt to login as 'username' > >> (with > >> do domain): > >> > >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: > >> Cannot find KDC for realm "ADDOMAIN.NET" > >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]: > >> Cannot find KDC for realm "ADDOMAIN.NET" > >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): > >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > >> rhost=10.5.5.57 user=username > >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth): > >> received for user username: 4 (System error) > >> May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for > >> username from 10.5.5.57 port 53118 ssh2 > >> > >> However, if in AD I switch the UPN on 'username' to the default of > >> 'sub.addomain.net' I get a successful login: > >> > >> May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth): > >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > >> rhost=10.5.5.57 user=username > >> May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth): > >> authentication success; logname= uid=0 euid=0 tty=ssh ruser= > >> rhost=10.5.5.57 user=username > >> May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for > >> username from 10.5.5.57 port 46077 ssh2 > >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting > >> user-1539201103.slice. > >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice > >> user-1539201103.slice. > >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of > >> user username at sub.addomain.net. > >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of > >> user > >> username at sub.addomain.net. > >> May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 > >> of > >> user username at sub.addomain.net. > >> May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session): > >> session opened for user username by (uid=0) > >> > >> As a temporary workaround I set dns_lookup_kdc = false in my > >> /etc/krb5.conf file and that worked to allow me to login with just > >> 'username' but even after a successful login, I was seeing those 'cannot > >> find KDC for realm' message in the log. > >> > >> Is there a proper way to allow people from a trusted AD domain to login > >> with their alternative UPNs? > > > > I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET > > section to the realms section of /etc/krb5.conf to all IPA clients and > > servers. > > > > Although SSSD as a client in a AD domain can handle those UPNs there is > > a missing part on the FreeIPA server side which is needed to make it > > work. The item is tracked in > > https://fedorahosted.org/freeipa/ticket/3559 . > > > > Since the UPN-suffix can be freely chosen, i.e. it does not have to be a > > DNS domain, the client will ask it's local KDC with a special so called > > enterprise principal if it knows about this UPN suffix and if the KDC > > knows about it it will tell the client where to ask for it. IF ticket > > #3559 gets implemented the entry in /etc/krb5.conf would not be needed > > anymore. > > > > HTH > > > > bye, > > Sumit > > > >> > >> > >> -- > >> 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 > > > > From alanwevans at gmail.com Tue May 5 19:48:58 2015 From: alanwevans at gmail.com (Alan Evans) Date: Tue, 5 May 2015 13:48:58 -0600 Subject: [Freeipa-users] User creation with native ldap tools Message-ID: Hello, I thought I saw something like this asked before but after searching the archive it seems I can't find it. I am using FreeIPA 3.3.3 on Cent 7 from EPEL. Is it possible using native ldap tools, ldapadd and ldappasswd in particular, for user creation and password management? I am trying to use an IDM to synchronize accounts from one directory to FreeIPA. The IDM does not have native FreeIPA support but does have LDAP support. I have successfully gotten some objects created but I am having problems with their passwords. I have tried using https://ipa/ui/migration, resetting passwords in IPA UI, ldappasswd and the ipa-cli but when I kinit these users I get the following. May 04 21:21:26 ipa01 krb5kdc[12959](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: CLIENT KEY EXPIRED: foouser at EXAMPLE.COM for krbtgt/ EXAMPLE.COM at EXAMPLE.COM, Password has expired May 04 21:21:26 ipa01 krb5kdc[12959](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: NEEDED_PREAUTH: foouser at EXAMPLE.COM for kadmin/ changepw at EXAMPLE.COM, Additional pre-authentication required May 04 21:26:44 ipa01 krb5kdc[12957](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: NEEDED_PREAUTH: foouser at EXAMPLE.COM for krbtgt/ EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required May 04 21:27:59 ipa01 krb5kdc[12956](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: CLIENT KEY EXPIRED: foouser at EXAMPLE.COM for krbtgt/ EXAMPLE.COM at EXAMPLE.COM, Password has expired May 04 21:27:59 ipa01 krb5kdc[12958](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: NEEDED_PREAUTH: foouser at EXAMPLE.COM for kadmin/ changepw at EXAMPLE.COM, Additional pre-authentication required May 04 21:31:05 ipa01 krb5kdc[12957](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: NEEDED_PREAUTH: foouser at EXAMPLE.COM for krbtgt/ EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required May 04 21:31:48 ipa01 krb5kdc[12957](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: CLIENT KEY EXPIRED: foouser at EXAMPLE.COM for krbtgt/ EXAMPLE.COM at EXAMPLE.COM, Password has expired May 04 21:31:48 ipa01 krb5kdc[12959](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: NEEDED_PREAUTH: foouser at EXAMPLE.COM for kadmin/ changepw at EXAMPLE.COM, Additional pre-authentication required May 04 21:32:23 ipa01 krb5kdc[13581](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: CLIENT KEY EXPIRED: foouser at EXAMPLE.COM for krbtgt/ EXAMPLE.COM at EXAMPLE.COM, Password has expired May 04 21:32:23 ipa01 krb5kdc[13582](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.131.144.139: NEEDED_PREAUTH: foouser at EXAMPLE.COM for kadmin/ changepw at EXAMPLE.COM, Additional pre-authentication required I did get a few google hits on 'CLIENT KEY EXPIRED' but I am not sure I understand what they're referring to and if they apply in this situation. Thank you, -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From APtashnik at cccis.com Tue May 5 20:01:05 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Tue, 5 May 2015 20:01:05 +0000 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves In-Reply-To: <628a95dd36f3507d9bb1c7bad00ea167.squirrel@webmail.nathanpeters.com> References: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> <01F17D22C8F4469CA6D3CD783379C48E@Azul> <5547314D.3020506@redhat.com> <628a95dd36f3507d9bb1c7bad00ea167.squirrel@webmail.nathanpeters.com> Message-ID: <03E8359E-5F35-4251-8B06-A60566A969A2@cccis.com> I did notice the same behavior. This is my setup: [root at ipa-idm]# yum list installed ipa-* Installed Packages ipa-admintools.x86_64 4.1.0-18.el7_1.3 @rhui-REGION-rhel-server-releases ipa-client.x86_64 4.1.0-18.el7_1.3 @rhui-REGION-rhel-server-releases ipa-python.x86_64 4.1.0-18.el7_1.3 @rhui-REGION-rhel-server-releases ipa-server.x86_64 4.1.0-18.el7_1.3 @rhui-REGION-rhel-server-releases [root at ipa-idm]# yum list installed bind* Installed Packages bind.x86_64 32:9.9.4-18.el7_1.1 @rhui-REGION-rhel-server-releases bind-dyndb-ldap.x86_64 6.0-2.el7 @rhui-REGION-rhel-server-releases bind-libs.x86_64 32:9.9.4-18.el7_1.1 @rhui-REGION-rhel-server-releases bind-libs-lite.x86_64 32:9.9.4-18.el7_1.1 @rhui-REGION-rhel-server-releases bind-license.noarch 32:9.9.4-18.el7_1.1 @rhui-REGION-rhel-server-releases bind-utils.x86_64 32:9.9.4-18.el7_1.1 @rhui-REGION-rhel-server-releases In my setup slaves are various DNS servers including Win2k3, Win2k8 and Bind that I don?t have access to, but according to IPA server logs they don?t receive ?NOTIFY? messages OR IPA server does not send them to slaves. Regards, Andrey On 5/4/15, 10:24 PM, "nathan at nathanpeters.com" wrote: >freeipa-admintools.x86_64 4.1.4-1.el7.centos >@mkosek-freeipa >freeipa-client.x86_64 4.1.4-1.el7.centos >@mkosek-freeipa >freeipa-python.x86_64 4.1.4-1.el7.centos >@mkosek-freeipa >freeipa-server.x86_64 4.1.4-1.el7.centos >@mkosek-freeipa >freeipa-server-trust-ad.x86_64 4.1.4-1.el7.centos >@mkosek-freeipa > >bind.x86_64 32:9.9.4-20.el7.centos.pkcs11 >@mkosek-freeipa >bind-dyndb-ldap.x86_64 6.1-1.el7.centos >@mkosek-freeipa >bind-libs.x86_64 32:9.9.4-20.el7.centos.pkcs11 >@mkosek-freeipa >bind-libs-lite.x86_64 32:9.9.4-20.el7.centos.pkcs11 >@mkosek-freeipa >bind-license.noarch 32:9.9.4-20.el7.centos.pkcs11 >@mkosek-freeipa >bind-pkcs11.x86_64 32:9.9.4-20.el7.centos.pkcs11 >@mkosek-freeipa >bind-pkcs11-libs.x86_64 32:9.9.4-20.el7.centos.pkcs11 >@mkosek-freeipa >bind-pkcs11-utils.x86_64 32:9.9.4-20.el7.centos.pkcs11 >@mkosek-freeipa > >And for reference here are the relevant A and NS records from my domain > >@ NS dc1.mydomain.net. >@ NS dc2.mydomain.net. >@ NS dns1.mydomain.net. >dns1 A 10.21.0.14 > >> Hello! >> >> On 2.5.2015 17:12, Nathan Peters wrote: >>> The last 3 sentences of my original post refer to me adding the NS >>> records for >>> the slave. Is that what you mean? >>> >>> "I have also ensured that the slave hostname and IP are in FreeIPA DNS. >>> I >>> have also added an NS entry pointing to the slave." >> >> Which version of FreeIPA and bind-dyndb-ldap are you using? >> >> I will look into it. >> >> Petr^2 Spacek >> >> >>> -----Original Message----- From: Baird, Josh >>> Sent: Saturday, May 02, 2015 7:33 AM >>> To: 'nathan at nathanpeters.com' ; freeipa-users at redhat.com >>> Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being >>> sent to >>> slaves >>> >>> Is the PowerDNS slave in the NS RRSet for the IPA domain? >>> Unfortuantely, >>> bind-dyndb-ldap does not support 'also-notify' which would allow us to >>> send >>> notifies each time a zone update occurs to slave servers that are not >>>in >>> the >>> RRSet [1]. To compensate for this in my environment, I had to lower >>>the >>> 'refresh' timer on the IPA zone. >>> >>> [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 >>> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of >>> nathan at nathanpeters.com >>> Sent: Friday, May 1, 2015 8:20 PM >>> To: freeipa-users at redhat.com >>> Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent >>> to slaves >>> >>> I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. >>> >>> I also have another host running PowerDNS serving as a slave. >>> The FreeIPA servers are setup to allow transfers to the slave by IP. >>> When >>> adding the zone, the slave transfered it properly. >>> >>> However, when I update the zone in FreeIPA, although the serial number >>> changes, in the /var/log/messages I only see an attempt to transfer to >>> the >>> second IPA server, and not the slave. This is the only log entry : >>> >>> May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending >>> notifies >>> (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client >>> 10.178.0.99#29832: received notify for zone 'mydomain.net' >>> >>> I have restarted all services using ipactl restart several times. I >>> have also >>> ensured that the slave hostname and IP are in FreeIPA DNS. I have also >>> added >>> an NS entry pointing to the slave. >>> >>> According to the FreeIPA manual, once that NS entry is added, any zone >>> updates >>> should trigger a notify, but still the only notifications go out to >>> FreeIPA >>> servers and nothing else. >>> >>> Any idea how to fix this so FreeIPA notifies non IPA servers? I'm >>> pretty sure >>> I've followed all the instructions to the letter on this one... >>> >>> >>> -- >>> 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 >> >> >> -- >> Petr^2 Spacek >> >> -- >> 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 From dpal at redhat.com Tue May 5 20:09:04 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 05 May 2015 16:09:04 -0400 Subject: [Freeipa-users] User creation with native ldap tools In-Reply-To: References: Message-ID: <55492360.60204@redhat.com> On 05/05/2015 03:48 PM, Alan Evans wrote: > Hello, I thought I saw something like this asked before but after > searching the archive it seems I can't find it. > > I am using FreeIPA 3.3.3 on Cent 7 from EPEL. Is it possible using > native ldap tools, ldapadd and ldappasswd in particular, for user > creation and password management? > > I am trying to use an IDM to synchronize accounts from one directory > to FreeIPA. The IDM does not have native FreeIPA support but does > have LDAP support. > > I have successfully gotten some objects created but I am having > problems with their passwords. > > I have tried using https://ipa/ui/migration, resetting passwords in > IPA UI, ldappasswd and the ipa-cli but when I kinit these users I get > the following. > > > May 04 21:21:26 ipa01 krb5kdc[12959](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : CLIENT KEY EXPIRED: > foouser at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM , > Password has expired > May 04 21:21:26 ipa01 krb5kdc[12959](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : NEEDED_PREAUTH: > foouser at EXAMPLE.COM for > kadmin/changepw at EXAMPLE.COM , Additional > pre-authentication required > May 04 21:26:44 ipa01 krb5kdc[12957](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : NEEDED_PREAUTH: > foouser at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM , > Additional pre-authentication required > May 04 21:27:59 ipa01 krb5kdc[12956](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : CLIENT KEY EXPIRED: > foouser at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM , > Password has expired > May 04 21:27:59 ipa01 krb5kdc[12958](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : NEEDED_PREAUTH: > foouser at EXAMPLE.COM for > kadmin/changepw at EXAMPLE.COM , Additional > pre-authentication required > May 04 21:31:05 ipa01 krb5kdc[12957](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : NEEDED_PREAUTH: > foouser at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM , > Additional pre-authentication required > May 04 21:31:48 ipa01 krb5kdc[12957](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : CLIENT KEY EXPIRED: > foouser at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM , > Password has expired > May 04 21:31:48 ipa01 krb5kdc[12959](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : NEEDED_PREAUTH: > foouser at EXAMPLE.COM for > kadmin/changepw at EXAMPLE.COM , Additional > pre-authentication required > May 04 21:32:23 ipa01 krb5kdc[13581](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : CLIENT KEY EXPIRED: > foouser at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM , > Password has expired > May 04 21:32:23 ipa01 krb5kdc[13582](info): AS_REQ (6 etypes {18 17 16 > 23 25 26}) 10.131.144.139 : NEEDED_PREAUTH: > foouser at EXAMPLE.COM for > kadmin/changepw at EXAMPLE.COM , Additional > pre-authentication required > > > I did get a few google hits on 'CLIENT KEY EXPIRED' but I am not sure > I understand what they're referring to and if they apply in this > situation. > > Thank you, > -Alan > > This might be caused by the mismatch of the LDAP password hashes. The password hashes that you had in other directory might not have the right hash types. There is a way to change the hashing scheme in IPA directory so that hashes would become accepted but I do not recall the setting from top of my head. In general this is not yet supported. We are working on the feature for 4.2. http://www.freeipa.org/page/V4/User_Life-Cycle_Management -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue May 5 20:20:21 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 May 2015 16:20:21 -0400 Subject: [Freeipa-users] User creation with native ldap tools In-Reply-To: References: Message-ID: <55492605.1010604@redhat.com> Alan Evans wrote: > Hello, I thought I saw something like this asked before but after > searching the archive it seems I can't find it. > > I am using FreeIPA 3.3.3 on Cent 7 from EPEL. Is it possible using > native ldap tools, ldapadd and ldappasswd in particular, for user > creation and password management? For adding users not yet, see https://fedorahosted.org/freeipa/ticket/3813 > I am trying to use an IDM to synchronize accounts from one directory to > FreeIPA. The IDM does not have native FreeIPA support but does have > LDAP support. > > I have successfully gotten some objects created but I am having problems > with their passwords. > > I have tried using https://ipa/ui/migration, resetting passwords in IPA > UI, ldappasswd and the ipa-cli but when I kinit these users I get the > following. See http://www.freeipa.org/page/New_Passwords_Expired When someone other than the user sets the password it is marked as expired so only the user knows it. rob From asacamano at gmail.com Tue May 5 20:27:05 2015 From: asacamano at gmail.com (Andrew Sacamano) Date: Tue, 5 May 2015 14:27:05 -0600 Subject: [Freeipa-users] Stuck getting sudo working with Ubuntu client In-Reply-To: <55374AC0.4030608@ubuntu.com> References: <20150417202822.GA13306@mail.corp.redhat.com> <20150420072957.GC30713@mail.corp.redhat.com> <20150421194556.GA6409@mail.corp.redhat.com> <55374AC0.4030608@ubuntu.com> Message-ID: Thanks again Lukas and Timo, I'm very sorry it took so long for me to get to this - I got pulled into an urgent project at work and am just getting my head above water today. I've filed https://fedorahosted.org/sssd/ticket/2648 Many thanks again, and please let me know if there is anything I can do to facilitate the process. Cheers, Andrew On Wed, Apr 22, 2015 at 1:16 AM, Timo Aaltonen wrote: > On 21.04.2015 22:45, Lukas Slebodnik wrote: > > On (20/04/15 17:54), Andrew Sacamano wrote: > >> Thanks again, Lukas! > >> > >> I was wondering if the overlaps of names was a problem, so I redid > parts of > >> my IPA setup to rename them - thanks for pointing out the ticket! > >> > >> Also, your suggestion to use ldap_group_object_class = ipaUserGroup > worked > >> - which saves me the trouble of tracking that down in six months when my > >> IPA domain grows and the performance issues associated with enumerate > begin > >> to manifest. > >> > >> Many thanks - you are extraordinarily helpful. My colleagues and I are > >> quite grateful for all your advice! > >> > > You are welcome, > > I'm glad I could help. > > > > You can file a ticket to backport patch for ticket #2471 in your > distribution. > > Please do, I've pulled the patch in git but need a bug# for SRU: > > https://bugs.launchpad.net/ubuntu/+source/sssd/+filebug > > > -- > t > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Tue May 5 20:43:34 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 05 May 2015 23:43:34 +0300 Subject: [Freeipa-users] Stuck getting sudo working with Ubuntu client In-Reply-To: References: <20150417202822.GA13306@mail.corp.redhat.com> <20150420072957.GC30713@mail.corp.redhat.com> <20150421194556.GA6409@mail.corp.redhat.com> <55374AC0.4030608@ubuntu.com> Message-ID: <55492B76.4030401@ubuntu.com> On 05.05.2015 23:27, Andrew Sacamano wrote: > Thanks again Lukas and Timo, > > I'm very sorry it took so long for me to get to this - I got pulled into > an urgent project at work and am just getting my head above water today. > > I've filed https://fedorahosted.org/sssd/ticket/2648 err, the bug needs to be on launchpad, since that's where it belongs > On Wed, Apr 22, 2015 at 1:16 AM, Timo Aaltonen > wrote: > > On 21.04.2015 22 :45, Lukas Slebodnik wrote: > > On (20/04/15 17:54), Andrew Sacamano wrote: > >> Thanks again, Lukas! > >> > >> I was wondering if the overlaps of names was a problem, so I > redid parts of > >> my IPA setup to rename them - thanks for pointing out the ticket! > >> > >> Also, your suggestion to use ldap_group_object_class = > ipaUserGroup worked > >> - which saves me the trouble of tracking that down in six months > when my > >> IPA domain grows and the performance issues associated with > enumerate begin > >> to manifest. > >> > >> Many thanks - you are extraordinarily helpful. My colleagues and > I are > >> quite grateful for all your advice! > >> > > You are welcome, > > I'm glad I could help. > > > > You can file a ticket to backport patch for ticket #2471 in your > distribution. > > Please do, I've pulled the patch in git but need a bug# for SRU: > > https://bugs.launchpad.net/ubuntu/+source/sssd/+filebug > > > -- > t > > -- t From nathan at nathanpeters.com Tue May 5 21:21:40 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Tue, 5 May 2015 14:21:40 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <20150505182840.GW3267@p.redhat.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> Message-ID: I'm a little confused by that. If I add the AD dc, will my client try to contact AD directly to get a ticket? Doesn't it have to do get the ticket through FreeIPA by proxy somehow? And to confirm what you meant by add the AD dc and realm, it would be like this ? SUB.ADDOMAIN.NET = { kdc = dc1.addomain.net:88 } I don't need the master_kdc, admin_server, default_domain entries? > On Tue, May 05, 2015 at 09:53:38AM -0700, nathan at nathanpeters.com wrote: >> Hmm, so if this is the [realms] section of my /etc/krb5.conf what do I >> have to do ? >> >> [realms] >> IPADOMAIN.NET = { >> kdc = dc1.ipadomain.net:88 >> master_kdc = dc1.ipadomain.net:88 >> admin_server = dc1.ipadomain.net:749 >> default_domain = ipadomain.net >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = >> RULE:[1:$1@$0](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/ >> auth_to_local = DEFAULT >> } >> >> Would I just literally copy that section and change the names? >> eg: >> >> SUB.ADDOMAIN.NET = { >> kdc = dc1.ipadomain.net:88 >> master_kdc = dc1.ipadomain.net:88 >> admin_server = dc1.ipadomain.net:749 >> default_domain = ipadomain.net > > you should add the AD DC and AD realm here > > The following lines you can just drop. > > HTH > > bye, > Sumit From jhrozek at redhat.com Wed May 6 03:41:29 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 6 May 2015 05:41:29 +0200 Subject: [Freeipa-users] Stuck getting sudo working with Ubuntu client In-Reply-To: <55492B76.4030401@ubuntu.com> References: <20150417202822.GA13306@mail.corp.redhat.com> <20150420072957.GC30713@mail.corp.redhat.com> <20150421194556.GA6409@mail.corp.redhat.com> <55374AC0.4030608@ubuntu.com> <55492B76.4030401@ubuntu.com> Message-ID: <20150506033157.GC3722@hendrix.payandsurf.com> On Tue, May 05, 2015 at 11:43:34PM +0300, Timo Aaltonen wrote: > On 05.05.2015 23:27, Andrew Sacamano wrote: > > Thanks again Lukas and Timo, > > > > I'm very sorry it took so long for me to get to this - I got pulled into > > an urgent project at work and am just getting my head above water today. > > > > I've filed https://fedorahosted.org/sssd/ticket/2648 > > err, the bug needs to be on launchpad, since that's where it belongs Yep, I closed the upstream ticket and included a link to launchpad. From jhrozek at redhat.com Wed May 6 03:43:25 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 6 May 2015 05:43:25 +0200 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> Message-ID: <20150506034325.GD3722@hendrix.payandsurf.com> On Tue, May 05, 2015 at 02:21:40PM -0700, nathan at nathanpeters.com wrote: > I'm a little confused by that. > > If I add the AD dc, will my client try to contact AD directly to get a > ticket? > > Doesn't it have to do get the ticket through FreeIPA by proxy somehow? No, authentication is always performed against an AD DC directly. > > And to confirm what you meant by add the AD dc and realm, it would be like > this ? > > SUB.ADDOMAIN.NET = { > kdc = dc1.addomain.net:88 > } > > I don't need the master_kdc, admin_server, default_domain entries? With a recent version of libkrb5 I don't think you need to set master_kdc, libkrb5 should be able to follow referrals itself. admin_servre, if unset, defaults to KDC. default_domain doesn't need to be set either. From nathan at nathanpeters.com Wed May 6 04:14:52 2015 From: nathan at nathanpeters.com (Nathan Peters) Date: Tue, 5 May 2015 21:14:52 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <20150506034325.GD3722@hendrix.payandsurf.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com><20150505163959.GV3267@p.redhat.com><20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> Message-ID: <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> >From this link : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb The diagram in that section shows the client communicating with FreeIPA and FreeIPA contacting AD. So why are you saying the client authenticates with the AD DC directly? Also this page here : https://www.freeipa.org/page/Active_Directory_trust_setup does not list having to add the AD domain in the krb5.conf. Is that not necessary in the example because they are not using a different UPN for their users like we are? -----Original Message----- From: Jakub Hrozek Sent: Tuesday, May 05, 2015 8:43 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues On Tue, May 05, 2015 at 02:21:40PM -0700, nathan at nathanpeters.com wrote: > I'm a little confused by that. > > If I add the AD dc, will my client try to contact AD directly to get a > ticket? > > Doesn't it have to do get the ticket through FreeIPA by proxy somehow? No, authentication is always performed against an AD DC directly. > > And to confirm what you meant by add the AD dc and realm, it would be like > this ? > > SUB.ADDOMAIN.NET = { > kdc = dc1.addomain.net:88 > } > > I don't need the master_kdc, admin_server, default_domain entries? With a recent version of libkrb5 I don't think you need to set master_kdc, libkrb5 should be able to follow referrals itself. admin_servre, if unset, defaults to KDC. default_domain doesn't need to be set either. -- 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 From christoph.kaminski at biotronik.com Wed May 6 05:48:17 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Wed, 6 May 2015 07:48:17 +0200 Subject: [Freeipa-users] Known issues with IPA on VM? Message-ID: Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) Greetz Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed May 6 06:12:48 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 6 May 2015 08:12:48 +0200 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> Message-ID: <20150506061248.GY3267@p.redhat.com> On Tue, May 05, 2015 at 09:14:52PM -0700, Nathan Peters wrote: > >From this link : > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb > > The diagram in that section shows the client communicating with FreeIPA and > FreeIPA contacting AD. > > So why are you saying the client authenticates with the AD DC directly? If you want to look up user data like e.g. the UID or the home directory the IPA client will talk to the IPA server exclusively, if the server does not know about the requested AD user it will try to get this information from a AD DC. For authentication this is different, because only the AD DC should know the password of the user. Hence authentication ans password changes as well are done directly with the AD DC. > > Also this page here : > https://www.freeipa.org/page/Active_Directory_trust_setup > > does not list having to add the AD domain in the krb5.conf. Is that not > necessary in the example because they are not using a different UPN for > their users like we are? yes, it is because of the UPN in your case. As I said before this special entry in krb5.conf would not be needed anymore if the IPA KDC supports the Kerberos client referrals for the trusted domains. Adding the entry to krb5.conf in only a work-around here. bye, Sumit > > -----Original Message----- From: Jakub Hrozek > Sent: Tuesday, May 05, 2015 8:43 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD > trust and UPN issues > > On Tue, May 05, 2015 at 02:21:40PM -0700, nathan at nathanpeters.com wrote: > >I'm a little confused by that. > > > >If I add the AD dc, will my client try to contact AD directly to get a > >ticket? > > > >Doesn't it have to do get the ticket through FreeIPA by proxy somehow? > > No, authentication is always performed against an AD DC directly. > > > > >And to confirm what you meant by add the AD dc and realm, it would be like > >this ? > > > >SUB.ADDOMAIN.NET = { > > kdc = dc1.addomain.net:88 > >} > > > >I don't need the master_kdc, admin_server, default_domain entries? > > With a recent version of libkrb5 I don't think you need to set > master_kdc, libkrb5 should be able to follow referrals itself. > admin_servre, if unset, defaults to KDC. default_domain doesn't need to > be set either. > > -- > 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 From techpkiuser at gmail.com Wed May 6 06:20:05 2015 From: techpkiuser at gmail.com (Kamal Perera) Date: Wed, 6 May 2015 11:50:05 +0530 Subject: [Freeipa-users] How to renew an expired admin certificate In-Reply-To: <553F2F15.3080108@redhat.com> References: <553F2F15.3080108@redhat.com> Message-ID: Thanks I will check. On Tue, Apr 28, 2015 at 12:26 PM, Niranjan M.R wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/28/2015 11:20 AM, Kamal Perera wrote: > > Dear All, > > > > I'm in the process of regaining one of the old CA systems which was not > being used for a long time. > > > > In the root CA, administrator certificate is expired and cannot access > the agent interface. In order to renew it, i would need the access to the > agent > > interface. > > Could you roll back the system date and try ? > > > > > Please help me to proceed with the login in to the agent interface. > > > > Regards, > > Kamal > > > > > > > - -- > Niranjan > irc: mrniranjan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iKYEARECAGYFAlU/LxVfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl > bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF > RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8ef5wCfUP8ObZnJ6nO2gqqRnWU/VUWr > u00AoMpIaGxdjEXm/7uAK0oUDsWq/Mn0 > =2nS3 > -----END PGP SIGNATURE----- > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 6 06:22:07 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 08:22:07 +0200 Subject: [Freeipa-users] IPA RUV unable to decode In-Reply-To: <5548D866.7030606@redhat.com> References: <5548A92C.2070602@redhat.com> <5548AE67.5050202@redhat.com> <5548D866.7030606@redhat.com> Message-ID: <5549B30F.9070404@redhat.com> On 05/05/2015 04:49 PM, Mark Reynolds wrote: > > > On 05/05/2015 07:49 AM, Ludwig Krispenz wrote: >> >> On 05/05/2015 01:27 PM, Martin Kosek wrote: >>> On 05/05/2015 12:38 PM, Vaclav Adamec wrote: >>>> Hi, >>>> I tried migrate to newest version IPA, but result is quite unstable and >>>> removing old replicas ends with RUV which cannot be decoded (it stucked in >>>> queue forever): >>>> >>>> ipa-replica-manage del ipa-master-dmz002.test.com -fc >>>> Cleaning a master is irreversible. >>>> This should not normally be require, so use cautiously. >>>> Continue to clean master? [no]: yes >>>> >>>> ipa-replica-manage list-ruv >>>> unable to decode: {replica 8} 55091239000400080000 55091239000400080000 >>>> unable to decode: {replica 7} 552f84cd000300070000 552f84cd000300070000 >>>> unable to decode: {replica 11} 551a42f70000000b0000 551aa3140001000b0000 >>>> unable to decode: {replica 15} 551e82e10001000f0000 551e82e10001000f0000 >>>> unable to decode: {replica 14} 551e82ec0001000e0000 551e82ec0001000e0000 >>>> unable to decode: {replica 20} 552f4b72000600140000 552f4b72000600140000 >>>> unable to decode: {replica 10} 551a25af0001000a0000 551a25af0001000a0000 >>>> unable to decode: {replica 3} 551e864c000300030000 551e864c000300030000 >>>> unable to decode: {replica 5} 55083ad2000300050000 55083ad2000300050000 >>>> unable to decode: {replica 9} 550913e7000000090000 550913e7000000090000 >>>> unable to decode: {replica 19} 55210193000300130000 55210193000300130000 >>>> unable to decode: {replica 12} 551a48290000000c0000 551a48c50000000c0000 >>>> ipa-master-dmz001.test.com:389: 25 >>>> ipa-master-dmz002.test.com:389: 21 >>>> >>>> it is possible to clear this queue and leave only valid servers ? >>>> >>>> Thanks in advance >>>> >>>> ipa-client-4.1.0-18.el7_1.3.x86_64 >>>> ipa-server-4.1.0-18.el7_1.3.x86_64 >>> Ludwig or Thierry, do you know? The questions about RUV cleaning seems to be >>> recurring, I suspect there will be a pattern (bug) and not just configuration >>> issue. >> we have seen this in a recent thread, and it is clear that the RUV is >> corrupted and cannot be decoded, but we don't have a scenario how this is >> state is reached. > The cleaning task (cleanAllRUV) can remove these invalid replica RUVs (RUV's > missing the ldap URL). To reproduce these "invalid" RUV's it requires > replication being disabled and re-enabled with a different replica id. > > To manually clean these invalid RUV elements, outside of using the IPA CLI, you > can directly issue the cleanAllRUV task to the Directory Server using ldapmodify: > > # ldapmodify -D "cn=directory manager" -W -a > dn: cn=clean 8, cn=cleanallruv, cn=tasks, cn=config > objectclass: extensibleObject > replica-base-dn: dc=example,dc=com > replica-id: 8 > cn: clean 8 > > Run these one at a time, as there is a current limit of running 4 concurrent > tasks. It is best to monitor the Directory Server errors log, or search on the > task entry itself, to see when it has finished before firing off the next task. > > For more on using cleanAllRUV see: > > http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv > http://www.port389.org/docs/389ds/design/cleanallruv-design.html > > Regards, > Mark Just for the record, ipa-replica-manage has a CLI for the CleanAllRUV task management: # man ipa-replica-manage ... list-ruv - List the replication IDs on this server. clean-ruv [REPLICATION_ID] - Run the CLEANALLRUV task to remove a replication ID. abort-clean-ruv [REPLICATION_ID] - Abort a running CLEANALLRUV task. list-clean-ruv - List all running CLEANALLRUV and abort CLEANALLRUV tasks. ... From techpkiuser at gmail.com Wed May 6 06:24:32 2015 From: techpkiuser at gmail.com (Kamal Perera) Date: Wed, 6 May 2015 11:54:32 +0530 Subject: [Freeipa-users] Revocation of Issuing CA certificates Message-ID: Dear All, How is the revocation of issuing CA certificates are handled? We are using OCSP responders for revocation checking of certificates issued by the Issuing CAs. So do we have to setup another OCSP or CRL distribution point to let the applications to query for the revocation of issuing CA certificates? Regards, Kamal -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed May 6 06:27:12 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 06 May 2015 08:27:12 +0200 Subject: [Freeipa-users] Fwd: Re: IPA RUV unable to decode In-Reply-To: References: Message-ID: <5549B440.7000403@redhat.com> let's keep the info on the list, more peple more ideas -------- Original Message -------- Subject: Re: [Freeipa-users] IPA RUV unable to decode Date: Tue, 5 May 2015 18:32:15 +0200 From: Vaclav Adamec To: Ludwig Krispenz master: ipa-replica-manage del -fc ipa-replica-prepare ... + copy gpg replicas: ipa-server-install --uninstall ipa-replica-install ... one by one on all replicas (1 CA master and 5 replicas which are also set in DNS as SRV records). Plus whole the time there was script/job which register clients (ipa-client-install --uninstall + ipa-client-install ... --force-join .... different active replica servers - via DNS). Seems that I have some issue with replica itself, it seems to work, but when it's loaded with such "heavy" operation replica servers goes down (dir process died) even master itself went down with minor codes errs in log. On Tue, May 5, 2015 at 3:25 PM, Ludwig Krispenz > wrote: On 05/05/2015 02:24 PM, Vaclav Adamec wrote: > For me it was quite easy to reached this state, I just setup > replica on 6 servers (two datacenters, with ~15ms latency, same > stable ntp source), run test scripts which add/verify random > account, add/remove hosts (unregister seems to be "heaviest" > operation to replicas). During these tests I removed some remove > servers from replica and try to add them back, what exactly did you do: ipa-server-install --uninstall ipa-server-install ? any other commands ? > result is like this. Seems that with higher load it happens more > often (register/unregister multiple servers, with actual setup it > is about 10 new registration in same time to different replica > servers), also sometimes I got replication conflicts or dir > service complete failure (dirsrv down, started with gssapi minor > code error). But even If I stop tests queue is not freed, RUV > still there (old replicas). > > On Tue, May 5, 2015 at 1:49 PM, Ludwig Krispenz > > wrote: > > > On 05/05/2015 01:27 PM, Martin Kosek wrote: > > On 05/05/2015 12:38 PM, Vaclav Adamec wrote: > > Hi, > I tried migrate to newest version IPA, but result is > quite unstable and > removing old replicas ends with RUV which cannot be > decoded (it stucked in > queue forever): > > ipa-replica-manage del ipa-master-dmz002.test.com > -fc > Cleaning a master is irreversible. > This should not normally be require, so use cautiously. > Continue to clean master? [no]: yes > > ipa-replica-manage list-ruv > unable to decode: {replica 8} 55091239000400080000 > 55091239000400080000 > unable to decode: {replica 7} 552f84cd000300070000 > 552f84cd000300070000 > unable to decode: {replica 11} 551a42f70000000b0000 > 551aa3140001000b0000 > unable to decode: {replica 15} 551e82e10001000f0000 > 551e82e10001000f0000 > unable to decode: {replica 14} 551e82ec0001000e0000 > 551e82ec0001000e0000 > unable to decode: {replica 20} 552f4b72000600140000 > 552f4b72000600140000 > unable to decode: {replica 10} 551a25af0001000a0000 > 551a25af0001000a0000 > unable to decode: {replica 3} 551e864c000300030000 > 551e864c000300030000 > unable to decode: {replica 5} 55083ad2000300050000 > 55083ad2000300050000 > unable to decode: {replica 9} 550913e7000000090000 > 550913e7000000090000 > unable to decode: {replica 19} 55210193000300130000 > 55210193000300130000 > unable to decode: {replica 12} 551a48290000000c0000 > 551a48c50000000c0000 > ipa-master-dmz001.test.com:389 > : 25 > ipa-master-dmz002.test.com:389 > : 21 > > it is possible to clear this queue and leave only > valid servers ? > > Thanks in advance > > ipa-client-4.1.0-18.el7_1.3.x86_64 > ipa-server-4.1.0-18.el7_1.3.x86_64 > > Ludwig or Thierry, do you know? The questions about RUV > cleaning seems to be > recurring, I suspect there will be a pattern (bug) and not > just configuration > issue. > > we have seen this in a recent thread, and it is clear that the > RUV is corrupted and cannot be decoded, but we don't have a > scenario how this is state is reached. > > > > > -- > -- May the fox be with you ... > /\ > (~( > ) ) /\_/\ > (_=---_(@ @) > ( \ / > /|/----\|\ V > " " " " > > -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 6 06:25:56 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 08:25:56 +0200 Subject: [Freeipa-users] Known issues with IPA on VM? In-Reply-To: References: Message-ID: <5549B3F4.5050204@redhat.com> On 05/06/2015 07:48 AM, Christoph Kaminski wrote: > Hi > > we have some undefinably problems here with IPA inside a VM (rhev/kvm). We > has often zombie processes (defunct) with certmonger and dirsrv and > segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with > same Install (rhel7.1). We see these problems only on the VM's. Is there > something already known about such problems? > > (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) I do not recall any specific VM problems in particular (maybe except that NTPD does not work too well in VMs), so I would recommend checking for the real reasons of crash. Maybe there are some useful errors in the DS/certmonger log files. If not, seeing the stack trace of the crash would help us/dirsrv developers identify the problem: http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes From mkosek at redhat.com Wed May 6 06:27:47 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 08:27:47 +0200 Subject: [Freeipa-users] Revocation of Issuing CA certificates In-Reply-To: References: Message-ID: <5549B463.6070107@redhat.com> On 05/06/2015 08:24 AM, Kamal Perera wrote: > Dear All, > > > How is the revocation of issuing CA certificates are handled? We are using > OCSP responders for revocation checking of certificates issued by the > Issuing CAs. So do we have to setup another OCSP or CRL distribution point > to let the applications to query for the revocation of issuing CA > certificates? I think I do not understand the question. IPA CA does not issue CA certificates (at least via IPA API), what certificates did you want to check? From vaclav.adamec at suchy-zleb.cz Wed May 6 06:49:42 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Wed, 6 May 2015 08:49:42 +0200 Subject: [Freeipa-users] IPA RUV unable to decode In-Reply-To: <5549B30F.9070404@redhat.com> References: <5548A92C.2070602@redhat.com> <5548AE67.5050202@redhat.com> <5548D866.7030606@redhat.com> <5549B30F.9070404@redhat.com> Message-ID: This tool cannot clear undecoded RUVs, I had sucess only with cleanallruv.pl script. Btw anybody know about some IDM training in Europe (RedHat/FreeIPA) ? Vasek On Wed, May 6, 2015 at 8:22 AM, Martin Kosek wrote: > On 05/05/2015 04:49 PM, Mark Reynolds wrote: > > > > > > On 05/05/2015 07:49 AM, Ludwig Krispenz wrote: > >> > >> On 05/05/2015 01:27 PM, Martin Kosek wrote: > >>> On 05/05/2015 12:38 PM, Vaclav Adamec wrote: > >>>> Hi, > >>>> I tried migrate to newest version IPA, but result is quite unstable > and > >>>> removing old replicas ends with RUV which cannot be decoded (it > stucked in > >>>> queue forever): > >>>> > >>>> ipa-replica-manage del ipa-master-dmz002.test.com -fc > >>>> Cleaning a master is irreversible. > >>>> This should not normally be require, so use cautiously. > >>>> Continue to clean master? [no]: yes > >>>> > >>>> ipa-replica-manage list-ruv > >>>> unable to decode: {replica 8} 55091239000400080000 > 55091239000400080000 > >>>> unable to decode: {replica 7} 552f84cd000300070000 > 552f84cd000300070000 > >>>> unable to decode: {replica 11} 551a42f70000000b0000 > 551aa3140001000b0000 > >>>> unable to decode: {replica 15} 551e82e10001000f0000 > 551e82e10001000f0000 > >>>> unable to decode: {replica 14} 551e82ec0001000e0000 > 551e82ec0001000e0000 > >>>> unable to decode: {replica 20} 552f4b72000600140000 > 552f4b72000600140000 > >>>> unable to decode: {replica 10} 551a25af0001000a0000 > 551a25af0001000a0000 > >>>> unable to decode: {replica 3} 551e864c000300030000 > 551e864c000300030000 > >>>> unable to decode: {replica 5} 55083ad2000300050000 > 55083ad2000300050000 > >>>> unable to decode: {replica 9} 550913e7000000090000 > 550913e7000000090000 > >>>> unable to decode: {replica 19} 55210193000300130000 > 55210193000300130000 > >>>> unable to decode: {replica 12} 551a48290000000c0000 > 551a48c50000000c0000 > >>>> ipa-master-dmz001.test.com:389: 25 > >>>> ipa-master-dmz002.test.com:389: 21 > >>>> > >>>> it is possible to clear this queue and leave only valid servers ? > >>>> > >>>> Thanks in advance > >>>> > >>>> ipa-client-4.1.0-18.el7_1.3.x86_64 > >>>> ipa-server-4.1.0-18.el7_1.3.x86_64 > >>> Ludwig or Thierry, do you know? The questions about RUV cleaning seems > to be > >>> recurring, I suspect there will be a pattern (bug) and not just > configuration > >>> issue. > >> we have seen this in a recent thread, and it is clear that the RUV is > >> corrupted and cannot be decoded, but we don't have a scenario how this > is > >> state is reached. > > The cleaning task (cleanAllRUV) can remove these invalid replica RUVs > (RUV's > > missing the ldap URL). To reproduce these "invalid" RUV's it requires > > replication being disabled and re-enabled with a different replica id. > > > > To manually clean these invalid RUV elements, outside of using the IPA > CLI, you > > can directly issue the cleanAllRUV task to the Directory Server using > ldapmodify: > > > > # ldapmodify -D "cn=directory manager" -W -a > > dn: cn=clean 8, cn=cleanallruv, cn=tasks, cn=config > > objectclass: extensibleObject > > replica-base-dn: dc=example,dc=com > > replica-id: 8 > > cn: clean 8 > > > > Run these one at a time, as there is a current limit of running 4 > concurrent > > tasks. It is best to monitor the Directory Server errors log, or search > on the > > task entry itself, to see when it has finished before firing off the > next task. > > > > For more on using cleanAllRUV see: > > > > http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv > > http://www.port389.org/docs/389ds/design/cleanallruv-design.html > > > > Regards, > > Mark > > Just for the record, ipa-replica-manage has a CLI for the CleanAllRUV task > management: > > # man ipa-replica-manage > ... > list-ruv > - List the replication IDs on this server. > > clean-ruv [REPLICATION_ID] > - Run the CLEANALLRUV task to remove a replication ID. > > abort-clean-ruv [REPLICATION_ID] > - Abort a running CLEANALLRUV task. > > list-clean-ruv > - List all running CLEANALLRUV and abort CLEANALLRUV tasks. > ... > > -- > 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 > -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " -------------- next part -------------- An HTML attachment was scrubbed... URL: From ender at kofeina.net Wed May 6 07:52:55 2015 From: ender at kofeina.net (=?iso-8859-2?Q?=A3ukasz_Jaworski?=) Date: Wed, 6 May 2015 09:52:55 +0200 Subject: [Freeipa-users] Problem with replication Message-ID: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> Hi, One of our replica hanged up morning. Error log after dirsrv restart: [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) I did "re-initialize" from other replica. Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) # ipactl status Failed to get list of services to probe status! Configured hostname 'replica09.local' does not match any master server in LDAP: replica01.local replica02.local replica03.local replica04.local replica05.local replica06.local replica07.local replica08.local replica09.local replica10.local replica09.local After dirsrv stop/start: In error logs there are many: [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) etc. [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 Packages: freeipa-server-4.1.3-2.fc21.x86_64 389-ds-base-1.3.3.8-1.fc21.x86_64 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 Best regards, Ender -- Lukasz Jaworski From pspacek at redhat.com Wed May 6 08:06:15 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 May 2015 10:06:15 +0200 Subject: [Freeipa-users] Split Horizon DNS config In-Reply-To: References: Message-ID: <5549CB77.5080104@redhat.com> On 5.5.2015 07:42, Christoph Kaminski wrote: > Hi > > can someone validate this config for bind + split horizon (only the views > part): > > acl internal { > 127.0.0.1; > 172.16.0.0/12; > }; > > view "internal" > { > match-clients { internal; }; > recursion yes; > > dynamic-db "ipa" { > library "ldap.so"; > arg "uri ldapi://%2fvar%2frun%2fslapd-HSO.socket"; > > arg "base cn=dns, dc=hso"; > arg "fake_mname ipa-2.mgmt.hss.int."; > arg "auth_method sasl"; > arg "sasl_mech GSSAPI"; > arg "sasl_user DNS/ipa-2.mgmt.hss.int"; > arg "serial_autoincrement yes"; > }; > > zone "." IN { > type hint; > file "named.ca"; > }; > > include "/etc/named.rfc1912.zones"; > include "/etc/named.root.key"; > > }; > > view "external" > { > match-clients { any; }; > recursion yes; > > zone "mgmt.hss.int" { > type master; > file "mgmt.hss.int.db"; > }; > > zone "in-addr.arpa" { > type forward; > forward only; > forwarders { 172.16.8.210; }; > }; > > zone "." IN { > type hint; > file "named.ca"; > }; > > include "/etc/named.rfc1912.zones"; > include "/etc/named.root.key"; > }; > > it works but its a little bit unclean hack IMHO. Bind 9.9 in rhel7.1 > doesnt support 'in-view' thats the reason why I use a the same host but > the ip from internal acl her: > > zone "in-addr.arpa" { > type forward; > forward only; > forwarders { 172.16.8.210; }; > }; > > is there something what can make problems? Technically it should work but it is untested. General advice about views is 'do not use them' :-) It is much cleaner to put internal names in a sub-domain like int.example.com. (while example.com. is the public-facing domain) and restrict access to this sub-domain using ACL. In long term it will make your life much easier when it comes to DNSSEC validation. Please see http://www.freeipa.org/page/Deployment_Recommendations#DNS for other related recommendations. I hope this helps. -- Petr^2 Spacek From pspacek at redhat.com Wed May 6 08:34:42 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 May 2015 10:34:42 +0200 Subject: [Freeipa-users] Split Horizon DNS config In-Reply-To: <5549CB77.5080104@redhat.com> References: <5549CB77.5080104@redhat.com> Message-ID: <5549D222.9010903@redhat.com> On 6.5.2015 10:06, Petr Spacek wrote: > General advice about views is > 'do not use them' :-) > > It is much cleaner to put internal names in a sub-domain like int.example.com. > (while example.com. is the public-facing domain) and restrict access to this > sub-domain using ACL. > > In long term it will make your life much easier when it comes to DNSSEC > validation. Please see > http://www.freeipa.org/page/Deployment_Recommendations#DNS for other related > recommendations. > > I hope this helps. I tried to summarize this for future generations: http://www.freeipa.org/page/DNS#Caveats -- Petr^2 Spacek From lkrispen at redhat.com Wed May 6 08:52:21 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 06 May 2015 10:52:21 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> Message-ID: <5549D645.3090001@redhat.com> Hi, there seem to be different issues, - I don't know what the ipactl status is looking for when it generates the error message about no matching master, but I don't think it is related to the retro changelog. - the retro changelog errors for adding and deleting -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. Could you verify which changes are in the changelog, and if these are changing: ldapsearch -b "cn=changelog" dn On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: > Hi, > > One of our replica hanged up morning. Error log after dirsrv restart: > [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete > [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) > [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. > [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) > [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. > [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. > [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] > [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 > [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 > [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete > [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) > > I did "re-initialize" from other replica. > > Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) > > # ipactl status > Failed to get list of services to probe status! > Configured hostname 'replica09.local' does not match any master server in LDAP: > replica01.local > replica02.local > replica03.local > replica04.local > replica05.local > replica06.local > replica07.local > replica08.local > replica09.local > replica10.local > replica09.local > > After dirsrv stop/start: > > In error logs there are many: > [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) > [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) > [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) > [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) > [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) > [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) > [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) > etc. > > [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. > [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) > [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. > [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. > [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] > [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 > > Packages: > freeipa-server-4.1.3-2.fc21.x86_64 > 389-ds-base-1.3.3.8-1.fc21.x86_64 > 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 > > Best regards, > Ender > From lkrispen at redhat.com Wed May 6 09:10:19 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 06 May 2015 11:10:19 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: <95442B05-915B-4CA3-8218-EBFDDC6B7F67@kofeina.net> References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> <95442B05-915B-4CA3-8218-EBFDDC6B7F67@kofeina.net> Message-ID: <5549DA7B.9070307@redhat.com> please reply to the mailing list On 05/06/2015 11:00 AM, ?ukasz Jaworski wrote: > Hi, > > ipactl stops working after dirsrv-stop/start. > > There are many changes in the changelog: > from 39399 to 44397 > > (?) > # 44393, changelog > dn: changenumber=44393,cn=changelog > > # 44394, changelog > dn: changenumber=44394,cn=changelog > > # 44395, changelog > dn: changenumber=44395,cn=changelog > > # 44396, changelog > dn: changenumber=44396,cn=changelog > > # 44397, changelog > dn: changenumber=44397,cn=changelog > > # search result > search: 2 > result: 11 Administrative limit exceeded > > # numResponses: 5001 > # numEntries: 5000 > > Best regards, > Lukasz Jaworski 'Ender' > > Wiadomo?? napisana przez Ludwig Krispenz w dniu 6 maj 2015, o godz. 10:52: > >> Hi, >> >> there seem to be different issues, >> - I don't know what the ipactl status is looking for when it generates the error message about no matching master, >> but I don't think it is related to the retro changelog. >> >> - the retro changelog errors for adding and deleting >> -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. >> the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases >> -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. >> Could you verify which changes are in the changelog, and if these are changing: >> ldapsearch -b "cn=changelog" dn >> >> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>> Hi, >>> >>> One of our replica hanged up morning. Error log after dirsrv restart: >>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) >>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) >>> [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. >>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. >>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) >>> >>> I did "re-initialize" from other replica. >>> >>> Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) >>> >>> # ipactl status >>> Failed to get list of services to probe status! >>> Configured hostname 'replica09.local' does not match any master server in LDAP: >>> replica01.local >>> replica02.local >>> replica03.local >>> replica04.local >>> replica05.local >>> replica06.local >>> replica07.local >>> replica08.local >>> replica09.local >>> replica10.local >>> replica09.local >>> >>> After dirsrv stop/start: >>> >>> In error logs there are many: >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) >>> etc. >>> >>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) >>> [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. >>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. >>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>> >>> Packages: >>> freeipa-server-4.1.3-2.fc21.x86_64 >>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>> >>> Best regards, >>> Ender >>> >> -- >> 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 From ender at kofeina.net Wed May 6 09:10:26 2015 From: ender at kofeina.net (=?windows-1250?Q?=A3ukasz_Jaworski?=) Date: Wed, 6 May 2015 11:10:26 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: <5549D645.3090001@redhat.com> References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> Message-ID: Hi, ipactl stops working after dirsrv-stop/start. There are many changes in the changelog: from 39399 to 44397 (?) # 44393, changelog dn: changenumber=44393,cn=changelog # 44394, changelog dn: changenumber=44394,cn=changelog # 44395, changelog dn: changenumber=44395,cn=changelog # 44396, changelog dn: changenumber=44396,cn=changelog # 44397, changelog dn: changenumber=44397,cn=changelog # search result search: 2 result: 11 Administrative limit exceeded # numResponses: 5001 # numEntries: 5000 After some seconds dirsrv stops responding. In error log: [06/May/2015:11:00:04 +0200] agmt="cn=cloneAgreement1-replica09.local-pki-tomcat" (replica08:389) - Can't locate CSN 55100d8c0000069f0000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [06/May/2015:11:00:04 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 ldapsearch hangs. Dirsrv is not responding now. This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. Lukasz Jaworski 'Ender' Wiadomo?? napisana przez Ludwig Krispenz w dniu 6 maj 2015, o godz. 10:52: > Hi, > > there seem to be different issues, > - I don't know what the ipactl status is looking for when it generates the error message about no matching master, > but I don't think it is related to the retro changelog. > > - the retro changelog errors for adding and deleting > -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. > the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases > -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. > Could you verify which changes are in the changelog, and if these are changing: > ldapsearch -b "cn=changelog" dn > > On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >> Hi, >> >> One of our replica hanged up morning. Error log after dirsrv restart: >> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) >> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) >> [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. >> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. >> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) >> >> I did "re-initialize" from other replica. >> >> Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) >> >> # ipactl status >> Failed to get list of services to probe status! >> Configured hostname 'replica09.local' does not match any master server in LDAP: >> replica01.local >> replica02.local >> replica03.local >> replica04.local >> replica05.local >> replica06.local >> replica07.local >> replica08.local >> replica09.local >> replica10.local >> replica09.local >> >> After dirsrv stop/start: >> >> In error logs there are many: >> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) >> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) >> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) >> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) >> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) >> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) >> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) >> etc. >> >> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) >> [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. >> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. >> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >> >> Packages: >> freeipa-server-4.1.3-2.fc21.x86_64 >> 389-ds-base-1.3.3.8-1.fc21.x86_64 >> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >> >> Best regards, >> Ender >> > > -- > 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 From Alexander.Frolushkin at megafon.ru Wed May 6 09:15:18 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Wed, 6 May 2015 09:15:18 +0000 Subject: [Freeipa-users] Known issues with IPA on VM? In-Reply-To: References: Message-ID: <960471ec49d743548a0e3d7a3657f11d@sib-ums03.Megafon.ru> Hello. We have periodically hanging and crashing dirsrv in our ipa servers. All of them running in VM on Vmware. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Christoph Kaminski Sent: Wednesday, May 06, 2015 11:48 AM To: Freeipa-users Subject: [Freeipa-users] Known issues with IPA on VM? Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) Greetz Christoph Kaminski ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed May 6 09:25:28 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 06 May 2015 11:25:28 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> Message-ID: <5549DE08.1090502@redhat.com> On 05/06/2015 11:10 AM, ?ukasz Jaworski wrote: > Hi, > > ipactl stops working after dirsrv-stop/start. > > There are many changes in the changelog: > from 39399 to 44397 > > (?) > # 44393, changelog > dn: changenumber=44393,cn=changelog > > # 44394, changelog > dn: changenumber=44394,cn=changelog > > # 44395, changelog > dn: changenumber=44395,cn=changelog > > # 44396, changelog > dn: changenumber=44396,cn=changelog > > # 44397, changelog > dn: changenumber=44397,cn=changelog > > # search result > search: 2 > result: 11 Administrative limit exceeded > > # numResponses: 5001 > # numEntries: 5000 > > > After some seconds dirsrv stops responding. > > In error log: > [06/May/2015:11:00:04 +0200] agmt="cn=cloneAgreement1-replica09.local-pki-tomcat" (replica08:389) - Can't locate CSN 55100d8c0000069f0000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. > [06/May/2015:11:00:04 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 > > ldapsearch hangs. Dirsrv is not responding now. if the server is hanging, can you get a pstack > > This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. the messages indicate there could be many concurrent operations, because individual ops are not fast enough, could your VM have less/slower resources than the physical machines ? > > Lukasz Jaworski 'Ender' > > Wiadomo?? napisana przez Ludwig Krispenz w dniu 6 maj 2015, o godz. 10:52: > >> Hi, >> >> there seem to be different issues, >> - I don't know what the ipactl status is looking for when it generates the error message about no matching master, >> but I don't think it is related to the retro changelog. >> >> - the retro changelog errors for adding and deleting >> -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. >> the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases >> -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. >> Could you verify which changes are in the changelog, and if these are changing: >> ldapsearch -b "cn=changelog" dn >> >> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>> Hi, >>> >>> One of our replica hanged up morning. Error log after dirsrv restart: >>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) >>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) >>> [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. >>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. >>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) >>> >>> I did "re-initialize" from other replica. >>> >>> Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) >>> >>> # ipactl status >>> Failed to get list of services to probe status! >>> Configured hostname 'replica09.local' does not match any master server in LDAP: >>> replica01.local >>> replica02.local >>> replica03.local >>> replica04.local >>> replica05.local >>> replica06.local >>> replica07.local >>> replica08.local >>> replica09.local >>> replica10.local >>> replica09.local >>> >>> After dirsrv stop/start: >>> >>> In error logs there are many: >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) >>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) >>> etc. >>> >>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) >>> [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. >>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. >>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>> >>> Packages: >>> freeipa-server-4.1.3-2.fc21.x86_64 >>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>> >>> Best regards, >>> Ender >>> >> -- >> 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 From david.dejaeghere at gmail.com Wed May 6 09:25:42 2015 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Wed, 6 May 2015 11:25:42 +0200 Subject: [Freeipa-users] Known issues with IPA on VM? In-Reply-To: <960471ec49d743548a0e3d7a3657f11d@sib-ums03.Megafon.ru> References: <960471ec49d743548a0e3d7a3657f11d@sib-ums03.Megafon.ru> Message-ID: Running FreeIPA 4.1 on Fedora 21 on Xenserver 6.2 in HVM mode. No issues. Kind Regards, David 2015-05-06 11:15 GMT+02:00 Alexander Frolushkin < Alexander.Frolushkin at megafon.ru>: > Hello. > > We have periodically hanging and crashing dirsrv in our ipa servers. > > All of them running in VM on Vmware. > > > > WBR, > > Alexander Frolushkin > > Cell +79232508764 > > Work +79232507764 > > > > *From:* freeipa-users-bounces at redhat.com [mailto: > freeipa-users-bounces at redhat.com] *On Behalf Of *Christoph Kaminski > *Sent:* Wednesday, May 06, 2015 11:48 AM > *To:* Freeipa-users > *Subject:* [Freeipa-users] Known issues with IPA on VM? > > > > Hi > > we have some undefinably problems here with IPA inside a VM (rhev/kvm). We > has often zombie processes (defunct) with certmonger and dirsrv and > segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same > Install (rhel7.1). We see these problems only on the VM's. Is there > something already known about such problems? > > (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) > > Greetz > Christoph Kaminski > > ------------------------------ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? > ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? > ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? > ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, > ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? > ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, > ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? > ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the > use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally privileged > information. The contents may not be disclosed or used by anyone other than > the addressee. If you are not the intended recipient(s), any use, > disclosure, copying, distribution or any action taken or omitted to be > taken in reliance on it is prohibited and may be unlawful. If you have > received this communication in error please notify us immediately by > responding to this email and then delete the e-mail and all attachments and > any copies thereof. > > (c)20mf50 > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ender at kofeina.net Wed May 6 09:31:56 2015 From: ender at kofeina.net (=?windows-1250?Q?=A3ukasz_Jaworski?=) Date: Wed, 6 May 2015 11:31:56 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: <5549DE08.1090502@redhat.com> References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> <5549DE08.1090502@redhat.com> Message-ID: >> ldapsearch hangs. Dirsrv is not responding now. > if the server is hanging, can you get a pstack >> Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x00007fc6a961f987 in deadlock_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x00007fc6a9623a4e in checkpoint_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x00007fc6a961fc0f in trickle_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x00007fc6a961a667 in perf_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x00007fc6abd455be in cos_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libcos-plugin.so #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007fc6a937be84 in _cl5TrimMain () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #3 0x00007fc6a93949e5 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #5 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #6 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #7 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x00007fc6a9395158 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #5 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #6 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #7 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #8 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 36 (Thread 0x7fc6a1203700 (LWP 1907)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x7fc6a0a02700 (LWP 1908)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x7fc693fff700 (LWP 1909)): #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007fc6b593a773 in housecleaning () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 33 (Thread 0x7fc6937fe700 (LWP 1910)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6a939f76f in replica_write_ruv () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #7 0x00007fc6a939f9fe in replica_update_state () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #8 0x00007fc6b542965a in eq_loop () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #10 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #11 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 32 (Thread 0x7fc692924700 (LWP 1912)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 31 (Thread 0x7fc692123700 (LWP 1913)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 30 (Thread 0x7fc691922700 (LWP 1914)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 #22 0x00007fc6b5943fc6 in do_search () #23 0x00007fc6b5932b4c in connection_threadmain () #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 29 (Thread 0x7fc691121700 (LWP 1915)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 #22 0x00007fc6b5943fc6 in do_search () #23 0x00007fc6b5932b4c in connection_threadmain () #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 28 (Thread 0x7fc690920700 (LWP 1916)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 #22 0x00007fc6b5943fc6 in do_search () #23 0x00007fc6b5932b4c in connection_threadmain () #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 27 (Thread 0x7fc67ffff700 (LWP 1917)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #10 0x00007fc6add50ced in __db_get () from /lib64/libdb-5.3.so #11 0x00007fc6add5473b in __db_get_pp () from /lib64/libdb-5.3.so #12 0x00007fc6a962a9bb in id2entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #13 0x00007fc6a9626cbd in dn2entry_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #14 0x00007fc6a9629bb1 in find_entry_internal.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007fc6a9629e99 in find_entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6a9663b5b in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #17 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 #18 0x00007fc6b546553e in search_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 #19 0x00007fc6b54657c8 in search_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #20 0x00007fc6b5465b73 in slapi_search_internal_get_entry () from /usr/lib64/dirsrv/libslapd.so.0 #21 0x00007fc6aad02234 in ipalockout_preop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #22 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #23 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #24 0x00007fc6b592c3d8 in do_bind () #25 0x00007fc6b5932974 in connection_threadmain () #26 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #27 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #28 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 25 (Thread 0x7fc67effd700 (LWP 1919)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 24 (Thread 0x7fc67e7fc700 (LWP 1920)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 23 (Thread 0x7fc67dffb700 (LWP 1921)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 22 (Thread 0x7fc67d7fa700 (LWP 1922)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6b592c22d in do_bind () #10 0x00007fc6b5932974 in connection_threadmain () #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 21 (Thread 0x7fc67cff9700 (LWP 1923)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6b592c22d in do_bind () #10 0x00007fc6b5932974 in connection_threadmain () #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 20 (Thread 0x7fc67c7f8700 (LWP 1924)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 19 (Thread 0x7fc67bff7700 (LWP 1925)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6b592c22d in do_bind () #10 0x00007fc6b5932974 in connection_threadmain () #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 18 (Thread 0x7fc67b7f6700 (LWP 1926)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x7fc67aff5700 (LWP 1927)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x7fc67a7f4700 (LWP 1928)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x7fc679ff3700 (LWP 1929)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): #0 0x00007fc6b31eff1d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fc6b31ea9be in pthread_mutex_lock () from /lib64/libpthread.so.0 #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so #3 0x00007fc6a7ec99b0 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #4 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #7 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #12 0x00007fc6a8d3758d in memberof_postop_modify () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #13 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #14 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #15 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #17 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 #18 0x00007fc6b5932925 in connection_threadmain () #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so #11 0x00007fc6a9672b70 in ldbm_back_seq () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 #13 0x00007fc6b54652a9 in slapi_seq_callback () from /usr/lib64/dirsrv/libslapd.so.0 #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #16 0x00007fc6a7ec99b5 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #17 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #18 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #19 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #20 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #21 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 #22 0x00007fc6b5932925 in connection_threadmain () #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fc6787f0700 (LWP 1932)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7fc677fef700 (LWP 1933)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7fc6777ee700 (LWP 1934)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6b592c22d in do_bind () #10 0x00007fc6b5932974 in connection_threadmain () #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7fc676fed700 (LWP 1935)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6b592c22d in do_bind () #10 0x00007fc6b5932974 in connection_threadmain () #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7fc6767ec700 (LWP 1936)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 #22 0x00007fc6b5943fc6 in do_search () #23 0x00007fc6b5932b4c in connection_threadmain () #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7fc6757ea700 (LWP 1938)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7fc674fe9700 (LWP 1939)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 #22 0x00007fc6b5943fc6 in do_search () #23 0x00007fc6b5932b4c in connection_threadmain () #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fc673fe7700 (LWP 1941)): #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007fc6b5930b9e in connection_wait_for_new_work () #3 0x00007fc6b5931dc9 in connection_threadmain () #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fc6737e6700 (LWP 1942)): #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x00007fc6b5933855 in time_thread () #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fc6b58fb800 (LWP 1863)): #0 0x00007fc6b2f18c8d in poll () from /lib64/libc.so.6 #1 0x00007fc6b3843da8 in _pr_poll_with_poll () from /lib64/libnspr4.so #2 0x00007fc6b5936b11 in slapd_daemon () #3 0x00007fc6b59294f4 in main () >> This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. > the messages indicate there could be many concurrent operations, because individual ops are not fast enough, could your VM have less/slower resources than the physical machines ? VMs have less rsources and slower than physical machines. VM: 4 cpu, hd via drbd on sas drives, physical: more cores, faster (ssd) drives Best regards, Lukasz Jaworski 'Ender' >> Lukasz Jaworski 'Ender' >> >> Wiadomo?? napisana przez Ludwig Krispenz w dniu 6 maj 2015, o godz. 10:52: >> >>> Hi, >>> >>> there seem to be different issues, >>> - I don't know what the ipactl status is looking for when it generates the error message about no matching master, >>> but I don't think it is related to the retro changelog. >>> >>> - the retro changelog errors for adding and deleting >>> -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. >>> the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases >>> -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. >>> Could you verify which changes are in the changelog, and if these are changing: >>> ldapsearch -b "cn=changelog" dn >>> >>> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>>> Hi, >>>> >>>> One of our replica hanged up morning. Error log after dirsrv restart: >>>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) >>>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) >>>> [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. >>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. >>>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) >>>> >>>> I did "re-initialize" from other replica. >>>> >>>> Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) >>>> >>>> # ipactl status >>>> Failed to get list of services to probe status! >>>> Configured hostname 'replica09.local' does not match any master server in LDAP: >>>> replica01.local >>>> replica02.local >>>> replica03.local >>>> replica04.local >>>> replica05.local >>>> replica06.local >>>> replica07.local >>>> replica08.local >>>> replica09.local >>>> replica10.local >>>> replica09.local >>>> >>>> After dirsrv stop/start: >>>> >>>> In error logs there are many: >>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) >>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) >>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) >>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) >>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) >>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) >>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) >>>> etc. >>>> >>>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) >>>> [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. >>>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. >>>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>> >>>> Packages: >>>> freeipa-server-4.1.3-2.fc21.x86_64 >>>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>>> >>>> Best regards, >>>> Ender >>>> >>> -- >>> 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 > From tbordaz at redhat.com Wed May 6 09:47:11 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 06 May 2015 11:47:11 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> <5549DE08.1090502@redhat.com> Message-ID: <5549E31F.4040809@redhat.com> This is looking like thread 13 prevents thread 12 run (and all the others). Now thread 13 is likely waiting for db page? We may need output of db_stat (db_state -N -h /var/lib/dirsrv/slapd-xxx/db/ -CA) thanks thierry On 05/06/2015 11:31 AM, ?ukasz Jaworski wrote: >>> ldapsearch hangs. Dirsrv is not responding now. >> if the server is hanging, can you get a pstack > Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): > #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 > #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 > #2 0x00007fc6a961f987 in deadlock_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): > #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 > #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 > #2 0x00007fc6a9623a4e in checkpoint_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): > #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 > #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 > #2 0x00007fc6a961fc0f in trickle_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): > #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 > #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 > #2 0x00007fc6a961a667 in perf_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 > #3 0x00007fc6abd455be in cos_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libcos-plugin.so > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): > #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so > #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so > #3 0x00007fc6a937be84 in _cl5TrimMain () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #3 0x00007fc6a93949e5 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #4 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #5 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #6 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #7 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): > #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so > #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so > #3 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #4 0x00007fc6a9395158 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #5 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #6 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #7 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #8 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 > #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 36 (Thread 0x7fc6a1203700 (LWP 1907)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 > #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 35 (Thread 0x7fc6a0a02700 (LWP 1908)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 > #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 34 (Thread 0x7fc693fff700 (LWP 1909)): > #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so > #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so > #3 0x00007fc6b593a773 in housecleaning () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 33 (Thread 0x7fc6937fe700 (LWP 1910)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so > #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6a939f76f in replica_write_ruv () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #7 0x00007fc6a939f9fe in replica_update_state () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so > #8 0x00007fc6b542965a in eq_loop () from /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #10 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #11 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 32 (Thread 0x7fc692924700 (LWP 1912)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 31 (Thread 0x7fc692123700 (LWP 1913)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 30 (Thread 0x7fc691922700 (LWP 1914)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so > #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so > #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so > #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 > #22 0x00007fc6b5943fc6 in do_search () > #23 0x00007fc6b5932b4c in connection_threadmain () > #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 29 (Thread 0x7fc691121700 (LWP 1915)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so > #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so > #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so > #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 > #22 0x00007fc6b5943fc6 in do_search () > #23 0x00007fc6b5932b4c in connection_threadmain () > #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 28 (Thread 0x7fc690920700 (LWP 1916)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so > #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so > #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so > #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 > #22 0x00007fc6b5943fc6 in do_search () > #23 0x00007fc6b5932b4c in connection_threadmain () > #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 27 (Thread 0x7fc67ffff700 (LWP 1917)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so > #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so > #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #10 0x00007fc6add50ced in __db_get () from /lib64/libdb-5.3.so > #11 0x00007fc6add5473b in __db_get_pp () from /lib64/libdb-5.3.so > #12 0x00007fc6a962a9bb in id2entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #13 0x00007fc6a9626cbd in dn2entry_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #14 0x00007fc6a9629bb1 in find_entry_internal.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #15 0x00007fc6a9629e99 in find_entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6a9663b5b in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #17 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 > #18 0x00007fc6b546553e in search_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #19 0x00007fc6b54657c8 in search_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #20 0x00007fc6b5465b73 in slapi_search_internal_get_entry () from /usr/lib64/dirsrv/libslapd.so.0 > #21 0x00007fc6aad02234 in ipalockout_preop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so > #22 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #23 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #24 0x00007fc6b592c3d8 in do_bind () > #25 0x00007fc6b5932974 in connection_threadmain () > #26 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #27 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #28 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 25 (Thread 0x7fc67effd700 (LWP 1919)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 24 (Thread 0x7fc67e7fc700 (LWP 1920)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 23 (Thread 0x7fc67dffb700 (LWP 1921)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 22 (Thread 0x7fc67d7fa700 (LWP 1922)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so > #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so > #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6b592c22d in do_bind () > #10 0x00007fc6b5932974 in connection_threadmain () > #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 21 (Thread 0x7fc67cff9700 (LWP 1923)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so > #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so > #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6b592c22d in do_bind () > #10 0x00007fc6b5932974 in connection_threadmain () > #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 20 (Thread 0x7fc67c7f8700 (LWP 1924)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 19 (Thread 0x7fc67bff7700 (LWP 1925)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so > #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so > #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6b592c22d in do_bind () > #10 0x00007fc6b5932974 in connection_threadmain () > #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 18 (Thread 0x7fc67b7f6700 (LWP 1926)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 17 (Thread 0x7fc67aff5700 (LWP 1927)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 16 (Thread 0x7fc67a7f4700 (LWP 1928)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 15 (Thread 0x7fc679ff3700 (LWP 1929)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): > #0 0x00007fc6b31eff1d in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007fc6b31ea9be in pthread_mutex_lock () from /lib64/libpthread.so.0 > #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so > #3 0x00007fc6a7ec99b0 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #4 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #7 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #8 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #12 0x00007fc6a8d3758d in memberof_postop_modify () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #13 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #14 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #15 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #17 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #18 0x00007fc6b5932925 in connection_threadmain () > #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so > #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so > #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so > #11 0x00007fc6a9672b70 in ldbm_back_seq () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #13 0x00007fc6b54652a9 in slapi_seq_callback () from /usr/lib64/dirsrv/libslapd.so.0 > #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #16 0x00007fc6a7ec99b5 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #17 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #18 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #19 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #20 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #21 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #22 0x00007fc6b5932925 in connection_threadmain () > #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 12 (Thread 0x7fc6787f0700 (LWP 1932)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 11 (Thread 0x7fc677fef700 (LWP 1933)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 10 (Thread 0x7fc6777ee700 (LWP 1934)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so > #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so > #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6b592c22d in do_bind () > #10 0x00007fc6b5932974 in connection_threadmain () > #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x7fc676fed700 (LWP 1935)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so > #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so > #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 > #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6b592c22d in do_bind () > #10 0x00007fc6b5932974 in connection_threadmain () > #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x7fc6767ec700 (LWP 1936)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so > #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so > #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so > #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 > #22 0x00007fc6b5943fc6 in do_search () > #23 0x00007fc6b5932b4c in connection_threadmain () > #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 6 (Thread 0x7fc6757ea700 (LWP 1938)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 5 (Thread 0x7fc674fe9700 (LWP 1939)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so > #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so > #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so > #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so > #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 > #22 0x00007fc6b5943fc6 in do_search () > #23 0x00007fc6b5932b4c in connection_threadmain () > #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fc673fe7700 (LWP 1941)): > #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so > #2 0x00007fc6b5930b9e in connection_wait_for_new_work () > #3 0x00007fc6b5931dc9 in connection_threadmain () > #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fc6737e6700 (LWP 1942)): > #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 > #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 > #2 0x00007fc6b5933855 in time_thread () > #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fc6b58fb800 (LWP 1863)): > #0 0x00007fc6b2f18c8d in poll () from /lib64/libc.so.6 > #1 0x00007fc6b3843da8 in _pr_poll_with_poll () from /lib64/libnspr4.so > #2 0x00007fc6b5936b11 in slapd_daemon () > #3 0x00007fc6b59294f4 in main () > > >>> This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. >> the messages indicate there could be many concurrent operations, because individual ops are not fast enough, could your VM have less/slower resources than the physical machines ? > VMs have less rsources and slower than physical machines. > VM: 4 cpu, hd via drbd on sas drives, > > physical: more cores, faster (ssd) drives > > Best regards, > Lukasz Jaworski 'Ender' > > > >>> Lukasz Jaworski 'Ender' >>> >>> Wiadomo?? napisana przez Ludwig Krispenz w dniu 6 maj 2015, o godz. 10:52: >>> >>>> Hi, >>>> >>>> there seem to be different issues, >>>> - I don't know what the ipactl status is looking for when it generates the error message about no matching master, >>>> but I don't think it is related to the retro changelog. >>>> >>>> - the retro changelog errors for adding and deleting >>>> -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. >>>> the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases >>>> -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. >>>> Could you verify which changes are in the changelog, and if these are changing: >>>> ldapsearch -b "cn=changelog" dn >>>> >>>> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>>>> Hi, >>>>> >>>>> One of our replica hanged up morning. Error log after dirsrv restart: >>>>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) >>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>>>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) >>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. >>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. >>>>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>>>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) >>>>> >>>>> I did "re-initialize" from other replica. >>>>> >>>>> Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) >>>>> >>>>> # ipactl status >>>>> Failed to get list of services to probe status! >>>>> Configured hostname 'replica09.local' does not match any master server in LDAP: >>>>> replica01.local >>>>> replica02.local >>>>> replica03.local >>>>> replica04.local >>>>> replica05.local >>>>> replica06.local >>>>> replica07.local >>>>> replica08.local >>>>> replica09.local >>>>> replica10.local >>>>> replica09.local >>>>> >>>>> After dirsrv stop/start: >>>>> >>>>> In error logs there are many: >>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) >>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) >>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) >>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) >>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) >>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) >>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) >>>>> etc. >>>>> >>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>>>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) >>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. >>>>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. >>>>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>> >>>>> Packages: >>>>> freeipa-server-4.1.3-2.fc21.x86_64 >>>>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>>>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>>>> >>>>> Best regards, >>>>> Ender >>>>> >>>> -- >>>> 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 > From ender at kofeina.net Wed May 6 10:01:59 2015 From: ender at kofeina.net (=?windows-1250?Q?=A3ukasz_Jaworski?=) Date: Wed, 6 May 2015 12:01:59 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: <5549E31F.4040809@redhat.com> References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> <5549DE08.1090502@redhat.com> <5549E31F.4040809@redhat.com> Message-ID: dbstat: MacBookPro-10DDB1EAF1CC-1522:~ ender$ cat FILE Default locking region information: 139 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 200 Initial number of locks allocated 0 Initial number of lockers allocated 200 Initial number of lock objects allocated 10000 Maximum number of locks possible 10000 Maximum number of lockers possible 10000 Maximum number of lock objects possible 312 Current number of locks allocated 151 Current number of lockers allocated 250 Current number of lock objects allocated 40 Number of lock object partitions 8191 Size of object hash table 275 Number of current locks 303 Maximum number of locks at any one time 6 Maximum number of locks in any one bucket 174 Maximum number of locks stolen by for an empty partition 13 Maximum number of locks stolen for any one partition 124 Number of current lockers 124 Maximum number of lockers at any one time 223 Number of current lock objects 233 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 49 Maximum number of objects stolen by for an empty partition 5 Maximum number of objects stolen for any one partition 82905 Total number of locks requested 82018 Total number of locks released 0 Total number of locks upgraded 68 Total number of locks downgraded 8 Lock requests not available due to conflicts, for which we waited 12 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 2MB 304KB Region size 0 The number of partition locks that required waiting (0%) 0 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 0 The number of locker allocations that required waiting (0%) 4 The number of region locks that required waiting (0%) 5 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID /var/lib/dirsrv/slapd-xxxx/db/__db.001 Region name 0x7fd376ff3000 Region address 0x7fd376ff30a0 Region allocation head 0x7fd376ffb2b0 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 796 allocations, 0 failures, 539 frees, 3 longest Allocations by power-of-two sizes: 1KB 781 2KB 3 4KB 6 8KB 3 16KB 0 32KB 1 64KB 0 128KB 0 256KB 2 512KB 0 1024KB 1 REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 2 Lock region region mutex [4/3168 0% !Own] 16381 locker table size 8191 object table size 34128 obj_off 889656 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=122 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 1 READ 1 HELD userRoot/id2entry.db handle 0 2 dd=121 locks held 0 write locks 0 pid/thread 1863/140490519340800 flags 0 priority 100 2 READ 1 WAIT userRoot/id2entry.db page 2495 3 dd=120 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 3 READ 1 HELD ipaca/id2entry.db handle 0 4 dd=119 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 5 dd=118 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 5 READ 1 HELD ipaca/entryrdn.db handle 0 6 dd=117 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 7 dd=116 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 8 dd=115 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 9 dd=114 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db handle 0 d dd=113 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 d READ 1 HELD ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 f dd=112 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 f READ 1 HELD ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 10 dd=111 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 10 READ 1 HELD ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 13 dd=110 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 13 READ 1 HELD ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db handle 0 14 dd=109 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 14 READ 1 HELD ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 15 dd=108 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 15 READ 1 HELD ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 16 dd=107 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 16 READ 1 HELD ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 17 dd=106 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db handle 0 1c dd=105 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db handle 0 1d dd=104 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 1d READ 1 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 1f dd=103 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 1f READ 1 HELD ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 20 dd=102 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 20 READ 1 HELD ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 25 dd=101 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db handle 0 26 dd=100 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 26 READ 1 HELD ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 2a dd=99 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 2a READ 1 HELD ipaca/vlv#carevocationpkitomcatindex.db handle 0 2b dd=98 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 2b READ 1 HELD changelog/id2entry.db handle 0 2c dd=97 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 2d dd=96 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 2d READ 1 HELD changelog/entryusn.db handle 0 2e dd=95 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 2f dd=94 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 2f READ 1 HELD userRoot/entryusn.db handle 0 30 dd=93 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 31 dd=92 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 31 READ 1 HELD ipaca/entryusn.db handle 0 32 dd=91 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 33 dd=90 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 33 READ 1 HELD userRoot/entryrdn.db handle 0 34 dd=89 locks held 0 write locks 0 pid/thread 1863/140490839312128 flags 0 priority 100 35 dd=88 locks held 0 write locks 0 pid/thread 1863/140490510948096 flags 0 priority 100 36 dd=87 locks held 0 write locks 0 pid/thread 1863/140490519340800 flags 0 priority 100 37 dd=86 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 37 READ 1 HELD userRoot/objectclass.db handle 0 38 dd=85 locks held 0 write locks 0 pid/thread 1863/140490351486720 flags 0 priority 100 39 dd=84 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 39 READ 1 HELD userRoot/ancestorid.db handle 0 3a dd=83 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 3b dd=82 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 3b READ 1 HELD userRoot/macAddress.db handle 0 3c dd=81 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 3d dd=80 locks held 0 write locks 0 pid/thread 1863/140490435413760 flags 0 priority 100 3e dd=79 locks held 0 write locks 0 pid/thread 1863/140490343094016 flags 0 priority 100 3f dd=78 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 40 dd=77 locks held 0 write locks 0 pid/thread 1863/140490839312128 flags 0 priority 100 41 dd=76 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 42 dd=75 locks held 0 write locks 0 pid/thread 1863/140490510948096 flags 0 priority 100 43 dd=74 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 44 dd=73 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 44 READ 1 HELD changelog/entryrdn.db handle 0 45 dd=72 locks held 0 write locks 0 pid/thread 1863/140490494162688 flags 0 priority 100 46 dd=71 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 47 dd=70 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 48 dd=69 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 48 READ 1 HELD changelog/objectclass.db handle 0 49 dd=68 locks held 0 write locks 0 pid/thread 1863/140490334701312 flags 0 priority 100 49 READ 1 WAIT changelog/objectclass.db page 1 4a dd=67 locks held 0 write locks 0 pid/thread 1863/140491066709760 flags 0 priority 100 4b dd=66 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 4b READ 1 HELD ipaca/objectclass.db handle 0 4c dd=65 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 4d dd=64 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 4e dd=63 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 4e READ 1 HELD changelog/aci.db handle 0 4f dd=62 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 50 dd=61 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 50 READ 1 HELD userRoot/aci.db handle 0 51 dd=60 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 52 dd=59 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 52 READ 1 HELD ipaca/aci.db handle 0 53 dd=58 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 54 dd=57 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 54 READ 1 HELD userRoot/parentid.db handle 0 55 dd=56 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 56 dd=55 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 57 dd=54 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 57 READ 1 HELD userRoot/nsuniqueid.db handle 0 58 dd=53 locks held 0 write locks 0 pid/thread 1863/140490494162688 flags 0 priority 100 59 dd=52 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 5a dd=51 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 5b dd=50 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 5b READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db handle 0 5c dd=49 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 5d dd=48 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 5e dd=47 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 5e READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db handle 0 5f dd=46 locks held 0 write locks 0 pid/thread 1863/140491104614144 flags 0 priority 100 60 dd=45 locks held 0 write locks 0 pid/thread 1863/140491104614144 flags 0 priority 100 61 dd=44 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 62 dd=43 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 63 dd=42 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 63 READ 1 HELD changelog/nsuniqueid.db handle 0 64 dd=41 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 64 READ 1 HELD changelog/changenumber.db handle 0 65 dd=40 locks held 0 write locks 0 pid/thread 1863/140490410235648 flags 0 priority 100 65 READ 1 WAIT changelog/changenumber.db page 68 66 dd=39 locks held 0 write locks 0 pid/thread 1863/140490854885120 flags 0 priority 100 67 dd=38 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 67 READ 1 HELD changelog/targetuniqueid.db handle 0 68 dd=37 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 68 READ 1 HELD changelog/parentid.db handle 0 69 dd=36 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 69 READ 1 HELD changelog/ancestorid.db handle 0 6a dd=35 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 6a READ 1 HELD changelog/numsubordinates.db handle 0 6b dd=34 locks held 0 write locks 0 pid/thread 1863/140490359879424 flags 0 priority 100 6b READ 1 WAIT changelog/objectclass.db page 1 6c dd=33 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 6c READ 1 HELD userRoot/nsTombstoneCSN.db handle 0 6d dd=32 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 6d READ 1 HELD userRoot/nscpEntryDN.db handle 0 6e dd=31 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 6e READ 1 HELD userRoot/numsubordinates.db handle 0 6f dd=30 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 6f READ 1 HELD userRoot/member.db handle 0 70 dd=29 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 70 READ 1 HELD userRoot/uniquemember.db handle 0 71 dd=28 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 71 READ 1 HELD userRoot/owner.db handle 0 72 dd=27 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 72 READ 1 HELD userRoot/seeAlso.db handle 0 73 dd=26 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 73 READ 1 HELD userRoot/manager.db handle 0 74 dd=25 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 74 READ 1 HELD userRoot/secretary.db handle 0 75 dd=24 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 75 READ 1 HELD userRoot/memberUser.db handle 0 76 dd=23 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 76 READ 1 HELD userRoot/memberHost.db handle 0 77 dd=22 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 77 READ 1 HELD userRoot/sourcehost.db handle 0 78 dd=21 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 78 READ 1 HELD userRoot/memberservice.db handle 0 79 dd=20 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 79 READ 1 HELD userRoot/managedby.db handle 0 7a dd=19 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 7a READ 1 HELD userRoot/memberallowcmd.db handle 0 7b dd=18 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 7b READ 1 HELD userRoot/memberdenycmd.db handle 0 7c dd=17 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 7c READ 1 HELD userRoot/ipasudorunas.db handle 0 7d dd=16 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 7d READ 1 HELD userRoot/ipasudorunasgroup.db handle 0 7e dd=15 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db handle 0 7f dd=14 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 7f READ 1 HELD userRoot/ipaassignedidview.db handle 0 80 dd=13 locks held 0 write locks 0 pid/thread 1863/140490494162688 flags 0 priority 100 81 dd=12 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 82 dd=11 locks held 1 write locks 0 pid/thread 1863/140490510948096 flags 10 priority 100 82 READ 1 HELD userRoot/krbPrincipalName.db handle 0 83 dd=10 locks held 0 write locks 0 pid/thread 1863/140490435413760 flags 0 priority 100 84 dd= 9 locks held 0 write locks 0 pid/thread 1863/140490510948096 flags 0 priority 100 85 dd= 8 locks held 1 write locks 0 pid/thread 1863/140490452199168 flags 10 priority 100 85 READ 1 HELD ipaca/requeststate.db handle 0 86 dd= 7 locks held 1 write locks 0 pid/thread 1863/140490452199168 flags 10 priority 100 86 READ 1 HELD ipaca/requesttype.db handle 0 87 dd= 4 locks held 1 write locks 0 pid/thread 1863/140490418628352 flags 10 priority 100 87 READ 1 HELD userRoot/memberOf.db handle 0 88 dd= 3 locks held 0 write locks 0 pid/thread 1863/140490822526720 flags 0 priority 100 88 READ 1 WAIT changelog/objectclass.db page 1 89 dd= 2 locks held 0 write locks 0 pid/thread 1863/140490805741312 flags 0 priority 100 89 READ 1 WAIT changelog/objectclass.db page 1 8a dd= 1 locks held 0 write locks 0 pid/thread 1863/140490839312128 flags 0 priority 100 8b dd= 0 locks held 0 write locks 0 pid/thread 1863/140490814134016 flags 0 priority 100 8b READ 1 WAIT changelog/objectclass.db page 1 800000f6 dd= 6 locks held 108 write locks 57 pid/thread 1863/140490418628352 flags 0 priority 100 800000f6 READ 4 HELD userRoot/member.db page 356 800000f6 READ 4 HELD userRoot/member.db page 360 800000f6 READ 2 HELD userRoot/member.db page 403 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 800000f6 READ 4 HELD userRoot/member.db page 405 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 800000f6 READ 3 HELD userRoot/memberHost.db page 96 800000f6 READ 10 HELD userRoot/memberUser.db page 166 800000f6 READ 15 HELD userRoot/member.db page 70 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 800000f6 READ 3 HELD userRoot/memberHost.db page 209 800000f6 READ 6 HELD userRoot/memberUser.db page 14 800000f6 READ 3 HELD userRoot/member.db page 26 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 800000f6 READ 5 HELD userRoot/memberHost.db page 87 800000f6 READ 10 HELD userRoot/member.db page 50 800000f6 READ 1 HELD userRoot/memberHost.db page 28 800000f6 READ 1 HELD userRoot/memberUser.db page 92 800000f6 READ 1 HELD userRoot/member.db page 43 800000f6 READ 2 HELD userRoot/memberUser.db page 103 800000f6 READ 2 HELD userRoot/member.db page 337 800000f6 READ 2 HELD userRoot/memberallowcmd.db page 44 800000f6 READ 2 HELD userRoot/memberdenycmd.db page 1 800000f6 READ 2 HELD userRoot/ipasudorunas.db page 1 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db page 1 800000f6 READ 2 HELD userRoot/objectclass.db page 10 800000f6 READ 15 HELD userRoot/member.db page 406 800000f6 READ 61 HELD userRoot/objectclass.db page 61 800000f6 READ 36 HELD userRoot/memberUser.db page 81 800000f6 READ 35 HELD userRoot/memberHost.db page 195 800000f6 READ 2 HELD userRoot/objectclass.db page 50 800000f6 READ 1 HELD changelog/nsuniqueid.db page 191 800000f6 READ 3 HELD changelog/entryrdn.db page 387 800000f6 READ 2 HELD changelog/entryrdn.db page 388 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 800000f6 WRITE 3 HELD changelog/objectclass.db page 1 800000f6 WRITE 1 HELD changelog/targetuniqueid.db page 47 800000f6 WRITE 1 HELD changelog/changenumber.db page 68 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page 191 800000f6 WRITE 1 HELD changelog/parentid.db page 1 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 800000f6 WRITE 1 HELD changelog/ancestorid.db page 1 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 800000f6 WRITE 1 HELD changelog/numsubordinates.db page 1 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 800000f6 READ 1 HELD userRoot/entryusn.db page 27 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 80000106 dd= 5 locks held 17 write locks 13 pid/thread 1863/140490410235648 flags 0 priority 100 80000106 WRITE 2 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 1 80000106 WRITE 4 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 5 80000106 WRITE 2 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 80000106 WRITE 4 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db page 1 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db page 5 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db page 1 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db page 5 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 80000106 READ 1 HELD ipaca/entryusn.db page 13 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 80000106 READ 1 HELD ipaca/requesttype.db page 1 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 80000106 READ 1 HELD ipaca/requeststate.db page 1 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 800001eb dd=4294967295 locks held 75 write locks 39 pid/thread 1863/140490418628352 flags 0 priority 100 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 800001eb READ 1 HELD userRoot/entryusn.db page 27 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 800001eb READ 1 HELD userRoot/memberOf.db page 219 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 800001eb READ 1 HELD userRoot/memberOf.db page 259 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 800001eb READ 1 HELD userRoot/memberOf.db page 253 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 800001eb READ 1 HELD userRoot/memberOf.db page 207 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 800001eb READ 1 HELD userRoot/memberOf.db page 91 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 800001eb READ 1 HELD userRoot/memberOf.db page 10 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 800001eb READ 1 HELD userRoot/memberOf.db page 211 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 800001eb READ 1 HELD userRoot/memberOf.db page 143 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 800001eb READ 1 HELD userRoot/memberOf.db page 121 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 800001eb READ 1 HELD userRoot/memberOf.db page 228 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 800001eb READ 1 HELD userRoot/memberOf.db page 78 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 800001eb READ 1 HELD userRoot/memberOf.db page 272 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 800001eb READ 1 HELD userRoot/memberOf.db page 189 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 800001eb READ 1 HELD userRoot/memberOf.db page 156 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 800001eb READ 1 HELD userRoot/memberOf.db page 148 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 800001eb READ 1 HELD userRoot/memberOf.db page 142 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 800001eb READ 1 HELD userRoot/memberOf.db page 258 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 800001eb READ 3 HELD userRoot/memberOf.db page 260 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 800001eb READ 1 HELD userRoot/memberOf.db page 218 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 800001eb READ 1 HELD userRoot/memberOf.db page 106 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 800001eb READ 1 HELD userRoot/memberOf.db page 141 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 800001eb READ 1 HELD userRoot/memberOf.db page 120 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 800001eb READ 2 HELD userRoot/memberOf.db page 126 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 800001eb READ 1 HELD userRoot/memberOf.db page 97 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 800001eb READ 1 HELD userRoot/memberOf.db page 196 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 800001eb READ 1 HELD userRoot/memberOf.db page 240 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 800001eb READ 1 HELD userRoot/memberOf.db page 73 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 800001eb READ 1 HELD userRoot/memberOf.db page 42 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 800001eb READ 1 HELD userRoot/memberOf.db page 251 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 800001eb READ 1 HELD userRoot/memberOf.db page 75 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 800001eb READ 2 HELD userRoot/memberOf.db page 271 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 800001eb READ 1 HELD userRoot/memberOf.db page 262 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 800001eb READ 3 HELD userRoot/memberOf.db page 255 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 800001eb READ 1 HELD userRoot/memberOf.db page 245 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 800001eb READ 1 HELD userRoot/memberOf.db page 19 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 2d READ 1 HELD changelog/entryusn.db handle 0 39 READ 1 HELD userRoot/ancestorid.db handle 0 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db handle 0 44 READ 1 HELD changelog/entryrdn.db handle 0 800000f6 READ 1 HELD changelog/nsuniqueid.db page 191 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page 191 63 READ 1 HELD changelog/nsuniqueid.db handle 0 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db handle 0 d READ 1 HELD ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 75 READ 1 HELD userRoot/memberUser.db handle 0 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 800000f6 READ 6 HELD userRoot/memberUser.db page 14 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 800000f6 READ 36 HELD userRoot/memberUser.db page 81 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 800000f6 READ 1 HELD userRoot/memberUser.db page 92 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 800000f6 READ 2 HELD userRoot/memberUser.db page 103 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 800000f6 READ 10 HELD userRoot/memberUser.db page 166 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 68 READ 1 HELD changelog/parentid.db handle 0 800000f6 WRITE 1 HELD changelog/parentid.db page 1 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 14 READ 1 HELD ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 50 READ 1 HELD userRoot/aci.db handle 0 7f READ 1 HELD userRoot/ipaassignedidview.db handle 0 72 READ 1 HELD userRoot/seeAlso.db handle 0 70 READ 1 HELD userRoot/uniquemember.db handle 0 800000f6 READ 15 HELD userRoot/member.db page 406 800000f6 READ 4 HELD userRoot/member.db page 405 800000f6 READ 2 HELD userRoot/member.db page 403 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 16 READ 1 HELD ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 52 READ 1 HELD ipaca/aci.db handle 0 800000f6 READ 2 HELD userRoot/member.db page 337 800000f6 READ 4 HELD userRoot/member.db page 360 800000f6 READ 4 HELD userRoot/member.db page 356 73 READ 1 HELD userRoot/manager.db handle 0 7c READ 1 HELD userRoot/ipasudorunas.db handle 0 800000f6 READ 2 HELD userRoot/ipasudorunas.db page 1 7d READ 1 HELD userRoot/ipasudorunasgroup.db handle 0 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db page 1 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 800000f6 READ 3 HELD userRoot/member.db page 26 6f READ 1 HELD userRoot/member.db handle 0 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 800000f6 READ 10 HELD userRoot/member.db page 50 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 800000f6 READ 1 HELD userRoot/member.db page 43 800000f6 READ 15 HELD userRoot/member.db page 70 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 800001eb READ 1 HELD userRoot/memberOf.db page 272 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 800001eb READ 1 HELD userRoot/memberOf.db page 259 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 800001eb READ 1 HELD userRoot/memberOf.db page 258 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 800001eb READ 3 HELD userRoot/memberOf.db page 260 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 800001eb READ 1 HELD userRoot/memberOf.db page 262 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 800001eb READ 2 HELD userRoot/memberOf.db page 271 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 26 READ 1 HELD ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 1f READ 1 HELD ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 800001eb READ 1 HELD userRoot/memberOf.db page 19 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 87 READ 1 HELD userRoot/memberOf.db handle 0 800001eb READ 1 HELD userRoot/memberOf.db page 10 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 800001eb READ 1 HELD userRoot/memberOf.db page 42 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 800001eb READ 1 HELD userRoot/memberOf.db page 91 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 800001eb READ 1 HELD userRoot/memberOf.db page 73 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 800001eb READ 1 HELD userRoot/memberOf.db page 75 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 800001eb READ 1 HELD userRoot/memberOf.db page 78 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 800001eb READ 1 HELD userRoot/memberOf.db page 121 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 800001eb READ 1 HELD userRoot/memberOf.db page 120 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 1 READ 1 HELD userRoot/id2entry.db handle 0 800001eb READ 2 HELD userRoot/memberOf.db page 126 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 800001eb READ 1 HELD userRoot/memberOf.db page 97 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 800001eb READ 1 HELD userRoot/memberOf.db page 106 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 800001eb READ 1 HELD userRoot/memberOf.db page 148 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 800001eb READ 1 HELD userRoot/memberOf.db page 156 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 800001eb READ 1 HELD userRoot/memberOf.db page 141 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 800001eb READ 1 HELD userRoot/memberOf.db page 143 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 800001eb READ 1 HELD userRoot/memberOf.db page 142 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 800001eb READ 1 HELD userRoot/memberOf.db page 189 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 800001eb READ 1 HELD userRoot/memberOf.db page 211 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 800001eb READ 1 HELD userRoot/memberOf.db page 219 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 800001eb READ 1 HELD userRoot/memberOf.db page 218 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 800001eb READ 1 HELD userRoot/memberOf.db page 196 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 f READ 1 HELD ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 800001eb READ 1 HELD userRoot/memberOf.db page 207 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 800001eb READ 1 HELD userRoot/memberOf.db page 240 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 800001eb READ 1 HELD userRoot/memberOf.db page 245 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 78 READ 1 HELD userRoot/memberservice.db handle 0 800001eb READ 1 HELD userRoot/memberOf.db page 251 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 800001eb READ 1 HELD userRoot/memberOf.db page 253 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 800001eb READ 3 HELD userRoot/memberOf.db page 255 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 800001eb READ 1 HELD userRoot/memberOf.db page 228 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db page 1 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db handle 0 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db page 5 13 READ 1 HELD ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db handle 0 2a READ 1 HELD ipaca/vlv#carevocationpkitomcatindex.db handle 0 74 READ 1 HELD userRoot/secretary.db handle 0 5 READ 1 HELD ipaca/entryrdn.db handle 0 85 READ 1 HELD ipaca/requeststate.db handle 0 80000106 READ 1 HELD ipaca/requeststate.db page 1 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 3b READ 1 HELD userRoot/macAddress.db handle 0 6e READ 1 HELD userRoot/numsubordinates.db handle 0 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db page 1 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db handle 0 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db page 5 10 READ 1 HELD ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 2 READ 1 WAIT userRoot/id2entry.db page 2495 800000f6 READ 2 HELD userRoot/memberdenycmd.db page 1 7b READ 1 HELD userRoot/memberdenycmd.db handle 0 5e READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db handle 0 4e READ 1 HELD changelog/aci.db handle 0 67 READ 1 HELD changelog/targetuniqueid.db handle 0 800000f6 WRITE 1 HELD changelog/targetuniqueid.db page 47 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 2b READ 1 HELD changelog/id2entry.db handle 0 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db handle 0 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 2f READ 1 HELD userRoot/entryusn.db handle 0 31 READ 1 HELD ipaca/entryusn.db handle 0 80000106 READ 1 HELD ipaca/entryusn.db page 13 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 800000f6 READ 1 HELD userRoot/entryusn.db page 27 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 800001eb READ 1 HELD userRoot/entryusn.db page 27 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 800000f6 WRITE 1 HELD changelog/changenumber.db page 68 65 READ 1 WAIT changelog/changenumber.db page 68 64 READ 1 HELD changelog/changenumber.db handle 0 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 82 READ 1 HELD userRoot/krbPrincipalName.db handle 0 800000f6 READ 2 HELD userRoot/memberallowcmd.db page 44 33 READ 1 HELD userRoot/entryrdn.db handle 0 80000106 READ 1 HELD ipaca/requesttype.db page 1 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 86 READ 1 HELD ipaca/requesttype.db handle 0 7a READ 1 HELD userRoot/memberallowcmd.db handle 0 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 37 READ 1 HELD userRoot/objectclass.db handle 0 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 800000f6 READ 2 HELD userRoot/objectclass.db page 10 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 77 READ 1 HELD userRoot/sourcehost.db handle 0 800000f6 READ 2 HELD userRoot/objectclass.db page 50 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 48 READ 1 HELD changelog/objectclass.db handle 0 800000f6 WRITE 3 HELD changelog/objectclass.db page 1 6b READ 1 WAIT changelog/objectclass.db page 1 49 READ 1 WAIT changelog/objectclass.db page 1 88 READ 1 WAIT changelog/objectclass.db page 1 89 READ 1 WAIT changelog/objectclass.db page 1 8b READ 1 WAIT changelog/objectclass.db page 1 800000f6 READ 61 HELD userRoot/objectclass.db page 61 80000106 WRITE 4 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 5 20 READ 1 HELD ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 80000106 WRITE 2 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 1 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 6a READ 1 HELD changelog/numsubordinates.db handle 0 800000f6 WRITE 1 HELD changelog/numsubordinates.db page 1 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 54 READ 1 HELD userRoot/parentid.db handle 0 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 800000f6 WRITE 1 HELD changelog/ancestorid.db page 1 69 READ 1 HELD changelog/ancestorid.db handle 0 4b READ 1 HELD ipaca/objectclass.db handle 0 57 READ 1 HELD userRoot/nsuniqueid.db handle 0 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 5b READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db handle 0 6d READ 1 HELD userRoot/nscpEntryDN.db handle 0 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 3 READ 1 HELD ipaca/id2entry.db handle 0 6c READ 1 HELD userRoot/nsTombstoneCSN.db handle 0 800000f6 READ 5 HELD userRoot/memberHost.db page 87 800000f6 READ 3 HELD userRoot/memberHost.db page 96 800000f6 READ 1 HELD userRoot/memberHost.db page 28 76 READ 1 HELD userRoot/memberHost.db handle 0 71 READ 1 HELD userRoot/owner.db handle 0 800000f6 READ 3 HELD userRoot/memberHost.db page 209 800000f6 READ 35 HELD userRoot/memberHost.db page 195 15 READ 1 HELD ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 80000106 WRITE 4 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 1d READ 1 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 80000106 WRITE 2 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 79 READ 1 HELD userRoot/managedby.db handle 0 800000f6 READ 3 HELD changelog/entryrdn.db page 387 800000f6 READ 2 HELD changelog/entryrdn.db page 388 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 Lukasz Jaworski 'Ender' Wiadomo?? napisana przez thierry bordaz w dniu 6 maj 2015, o godz. 11:47: > This is looking like thread 13 prevents thread 12 run (and all the others). > Now thread 13 is likely waiting for db page? We may need output of db_stat (db_state -N -h /var/lib/dirsrv/slapd-xxx/db/ -CA) > > thanks > thierry > On 05/06/2015 11:31 AM, ?ukasz Jaworski wrote: >>>> ldapsearch hangs. Dirsrv is not responding now. >>> if the server is hanging, can you get a pstack >> Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): >> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >> #2 0x00007fc6a961f987 in deadlock_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): >> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >> #2 0x00007fc6a9623a4e in checkpoint_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): >> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >> #2 0x00007fc6a961fc0f in trickle_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): >> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >> #2 0x00007fc6a961a667 in perf_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >> #3 0x00007fc6abd455be in cos_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libcos-plugin.so >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): >> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >> #3 0x00007fc6a937be84 in _cl5TrimMain () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #3 0x00007fc6a93949e5 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #4 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #5 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #6 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #7 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): >> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >> #3 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #4 0x00007fc6a9395158 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #5 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #6 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #7 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #8 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 36 (Thread 0x7fc6a1203700 (LWP 1907)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 35 (Thread 0x7fc6a0a02700 (LWP 1908)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 34 (Thread 0x7fc693fff700 (LWP 1909)): >> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >> #3 0x00007fc6b593a773 in housecleaning () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 33 (Thread 0x7fc6937fe700 (LWP 1910)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6a939f76f in replica_write_ruv () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #7 0x00007fc6a939f9fe in replica_update_state () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >> #8 0x00007fc6b542965a in eq_loop () from /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #10 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #11 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 32 (Thread 0x7fc692924700 (LWP 1912)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 31 (Thread 0x7fc692123700 (LWP 1913)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 30 (Thread 0x7fc691922700 (LWP 1914)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >> #22 0x00007fc6b5943fc6 in do_search () >> #23 0x00007fc6b5932b4c in connection_threadmain () >> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 29 (Thread 0x7fc691121700 (LWP 1915)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >> #22 0x00007fc6b5943fc6 in do_search () >> #23 0x00007fc6b5932b4c in connection_threadmain () >> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 28 (Thread 0x7fc690920700 (LWP 1916)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >> #22 0x00007fc6b5943fc6 in do_search () >> #23 0x00007fc6b5932b4c in connection_threadmain () >> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 27 (Thread 0x7fc67ffff700 (LWP 1917)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #10 0x00007fc6add50ced in __db_get () from /lib64/libdb-5.3.so >> #11 0x00007fc6add5473b in __db_get_pp () from /lib64/libdb-5.3.so >> #12 0x00007fc6a962a9bb in id2entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #13 0x00007fc6a9626cbd in dn2entry_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #14 0x00007fc6a9629bb1 in find_entry_internal.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #15 0x00007fc6a9629e99 in find_entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6a9663b5b in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #17 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >> #18 0x00007fc6b546553e in search_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #19 0x00007fc6b54657c8 in search_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #20 0x00007fc6b5465b73 in slapi_search_internal_get_entry () from /usr/lib64/dirsrv/libslapd.so.0 >> #21 0x00007fc6aad02234 in ipalockout_preop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >> #22 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #23 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #24 0x00007fc6b592c3d8 in do_bind () >> #25 0x00007fc6b5932974 in connection_threadmain () >> #26 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #27 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #28 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 25 (Thread 0x7fc67effd700 (LWP 1919)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 24 (Thread 0x7fc67e7fc700 (LWP 1920)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 23 (Thread 0x7fc67dffb700 (LWP 1921)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 22 (Thread 0x7fc67d7fa700 (LWP 1922)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6b592c22d in do_bind () >> #10 0x00007fc6b5932974 in connection_threadmain () >> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 21 (Thread 0x7fc67cff9700 (LWP 1923)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6b592c22d in do_bind () >> #10 0x00007fc6b5932974 in connection_threadmain () >> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 20 (Thread 0x7fc67c7f8700 (LWP 1924)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 19 (Thread 0x7fc67bff7700 (LWP 1925)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6b592c22d in do_bind () >> #10 0x00007fc6b5932974 in connection_threadmain () >> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 18 (Thread 0x7fc67b7f6700 (LWP 1926)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 17 (Thread 0x7fc67aff5700 (LWP 1927)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 16 (Thread 0x7fc67a7f4700 (LWP 1928)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 15 (Thread 0x7fc679ff3700 (LWP 1929)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): >> #0 0x00007fc6b31eff1d in __lll_lock_wait () from /lib64/libpthread.so.0 >> #1 0x00007fc6b31ea9be in pthread_mutex_lock () from /lib64/libpthread.so.0 >> #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so >> #3 0x00007fc6a7ec99b0 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #4 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #7 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #8 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #12 0x00007fc6a8d3758d in memberof_postop_modify () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #13 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #14 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #15 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #17 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #18 0x00007fc6b5932925 in connection_threadmain () >> #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so >> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >> #11 0x00007fc6a9672b70 in ldbm_back_seq () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #13 0x00007fc6b54652a9 in slapi_seq_callback () from /usr/lib64/dirsrv/libslapd.so.0 >> #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #16 0x00007fc6a7ec99b5 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #17 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #18 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #19 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #20 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #21 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #22 0x00007fc6b5932925 in connection_threadmain () >> #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 12 (Thread 0x7fc6787f0700 (LWP 1932)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 11 (Thread 0x7fc677fef700 (LWP 1933)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 10 (Thread 0x7fc6777ee700 (LWP 1934)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6b592c22d in do_bind () >> #10 0x00007fc6b5932974 in connection_threadmain () >> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 9 (Thread 0x7fc676fed700 (LWP 1935)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6b592c22d in do_bind () >> #10 0x00007fc6b5932974 in connection_threadmain () >> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 8 (Thread 0x7fc6767ec700 (LWP 1936)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >> #22 0x00007fc6b5943fc6 in do_search () >> #23 0x00007fc6b5932b4c in connection_threadmain () >> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 6 (Thread 0x7fc6757ea700 (LWP 1938)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 5 (Thread 0x7fc674fe9700 (LWP 1939)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >> #22 0x00007fc6b5943fc6 in do_search () >> #23 0x00007fc6b5932b4c in connection_threadmain () >> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 3 (Thread 0x7fc673fe7700 (LWP 1941)): >> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >> #3 0x00007fc6b5931dc9 in connection_threadmain () >> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 2 (Thread 0x7fc6737e6700 (LWP 1942)): >> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >> #2 0x00007fc6b5933855 in time_thread () >> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> Thread 1 (Thread 0x7fc6b58fb800 (LWP 1863)): >> #0 0x00007fc6b2f18c8d in poll () from /lib64/libc.so.6 >> #1 0x00007fc6b3843da8 in _pr_poll_with_poll () from /lib64/libnspr4.so >> #2 0x00007fc6b5936b11 in slapd_daemon () >> #3 0x00007fc6b59294f4 in main () >> >> >>>> This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. >>> the messages indicate there could be many concurrent operations, because individual ops are not fast enough, could your VM have less/slower resources than the physical machines ? >> VMs have less rsources and slower than physical machines. >> VM: 4 cpu, hd via drbd on sas drives, >> >> physical: more cores, faster (ssd) drives >> >> Best regards, >> Lukasz Jaworski 'Ender' >> >> >> >>>> Lukasz Jaworski 'Ender' >>>> >>>> Wiadomo?? napisana przez Ludwig Krispenz w dniu 6 maj 2015, o godz. 10:52: >>>> >>>>> Hi, >>>>> >>>>> there seem to be different issues, >>>>> - I don't know what the ipactl status is looking for when it generates the error message about no matching master, >>>>> but I don't think it is related to the retro changelog. >>>>> >>>>> - the retro changelog errors for adding and deleting >>>>> -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. >>>>> the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases >>>>> -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. >>>>> Could you verify which changes are in the changelog, and if these are changing: >>>>> ldapsearch -b "cn=changelog" dn >>>>> >>>>> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>>>>> Hi, >>>>>> >>>>>> One of our replica hanged up morning. Error log after dirsrv restart: >>>>>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) >>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>>>>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) >>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. >>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. >>>>>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>>>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>>>>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) >>>>>> >>>>>> I did "re-initialize" from other replica. >>>>>> >>>>>> Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) >>>>>> >>>>>> # ipactl status >>>>>> Failed to get list of services to probe status! >>>>>> Configured hostname 'replica09.local' does not match any master server in LDAP: >>>>>> replica01.local >>>>>> replica02.local >>>>>> replica03.local >>>>>> replica04.local >>>>>> replica05.local >>>>>> replica06.local >>>>>> replica07.local >>>>>> replica08.local >>>>>> replica09.local >>>>>> replica10.local >>>>>> replica09.local >>>>>> >>>>>> After dirsrv stop/start: >>>>>> >>>>>> In error logs there are many: >>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) >>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) >>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) >>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) >>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) >>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) >>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) >>>>>> etc. >>>>>> >>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>>>>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) >>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. >>>>>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. >>>>>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>>>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>> >>>>>> Packages: >>>>>> freeipa-server-4.1.3-2.fc21.x86_64 >>>>>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>>>>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>>>>> >>>>>> Best regards, >>>>>> Ender >>>>>> >>>>> -- >>>>> 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 >> > From pspacek at redhat.com Wed May 6 11:22:38 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 May 2015 13:22:38 +0200 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves In-Reply-To: <628a95dd36f3507d9bb1c7bad00ea167.squirrel@webmail.nathanpeters.com> References: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> <01F17D22C8F4469CA6D3CD783379C48E@Azul> <5547314D.3020506@redhat.com> <628a95dd36f3507d9bb1c7bad00ea167.squirrel@webmail.nathanpeters.com> Message-ID: <5549F97E.4030708@redhat.com> Hello! On 5.5.2015 00:24, nathan at nathanpeters.com wrote: > bind.x86_64 32:9.9.4-20.el7.centos.pkcs11 > @mkosek-freeipa > bind-dyndb-ldap.x86_64 6.1-1.el7.centos This version works for me (tested on Fedora 21). > And for reference here are the relevant A and NS records from my domain > > @ NS dc1.mydomain.net. > @ NS dc2.mydomain.net. > @ NS dns1.mydomain.net. > dns1 A 10.21.0.14 I would recommend you to double check if commands $ dig @ dc1.mydomain.net. A $ dig @ dc2.mydomain.net. A $ dig @ dns1.mydomain.net. A actually return an IP addresses or not. Unfortunately BIND does not report an error if it is unable to resolve the name and silently ignores the name when notifications are sent. For testing purposes I use these commands (on server): $ tcpdump -i any 'port 53' $ rndc notify mydomain.net. Look for a line from tcpdump with note 'notify' in it. I can see the notify packet as soon as BIND prints 'sending notifies' message to the journal. I hope this helps. Petr^2 Spacek >> Hello! >> >> On 2.5.2015 17:12, Nathan Peters wrote: >>> The last 3 sentences of my original post refer to me adding the NS >>> records for >>> the slave. Is that what you mean? >>> >>> "I have also ensured that the slave hostname and IP are in FreeIPA DNS. >>> I >>> have also added an NS entry pointing to the slave." >> >> Which version of FreeIPA and bind-dyndb-ldap are you using? >> >> I will look into it. >> >> Petr^2 Spacek >> >> >>> -----Original Message----- From: Baird, Josh >>> Sent: Saturday, May 02, 2015 7:33 AM >>> To: 'nathan at nathanpeters.com' ; freeipa-users at redhat.com >>> Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being >>> sent to >>> slaves >>> >>> Is the PowerDNS slave in the NS RRSet for the IPA domain? >>> Unfortuantely, >>> bind-dyndb-ldap does not support 'also-notify' which would allow us to >>> send >>> notifies each time a zone update occurs to slave servers that are not in >>> the >>> RRSet [1]. To compensate for this in my environment, I had to lower the >>> 'refresh' timer on the IPA zone. >>> >>> [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 >>> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of >>> nathan at nathanpeters.com >>> Sent: Friday, May 1, 2015 8:20 PM >>> To: freeipa-users at redhat.com >>> Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent >>> to slaves >>> >>> I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. >>> >>> I also have another host running PowerDNS serving as a slave. >>> The FreeIPA servers are setup to allow transfers to the slave by IP. >>> When >>> adding the zone, the slave transfered it properly. >>> >>> However, when I update the zone in FreeIPA, although the serial number >>> changes, in the /var/log/messages I only see an attempt to transfer to >>> the >>> second IPA server, and not the slave. This is the only log entry : >>> >>> May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending >>> notifies >>> (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client >>> 10.178.0.99#29832: received notify for zone 'mydomain.net' >>> >>> I have restarted all services using ipactl restart several times. I >>> have also >>> ensured that the slave hostname and IP are in FreeIPA DNS. I have also >>> added >>> an NS entry pointing to the slave. >>> >>> According to the FreeIPA manual, once that NS entry is added, any zone >>> updates >>> should trigger a notify, but still the only notifications go out to >>> FreeIPA >>> servers and nothing else. >>> >>> Any idea how to fix this so FreeIPA notifies non IPA servers? I'm >>> pretty sure >>> I've followed all the instructions to the letter on this one... From tbordaz at redhat.com Wed May 6 11:29:03 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 06 May 2015 13:29:03 +0200 Subject: [Freeipa-users] Problem with replication In-Reply-To: References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> <5549DE08.1090502@redhat.com> <5549E31F.4040809@redhat.com> Message-ID: <5549FAFF.1080905@redhat.com> This is looking like a deadlock between thread 14 and thread 13 where both threads acquired lock in the opposite order. Thread 14 is processing a betxn_postop but thread 13 is doing a postop. I wonder if the problem is that the test/set of the changenumber is done outside of the backend lock. Thread 14 holds some db page locks and tries to acquire retrocl plugin lock (retrocl_internal_lock) 800000f6 dd= 6 locks held 108 write locks 57 pid/thread 1863/140490418628352 flags 0 priority 100 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 800000f6 WRITE 3 HELD changelog/objectclass.db page 1 800000f6 WRITE 1 HELD changelog/changenumber.db page 68 Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): #0 0x00007fc6b31eff1d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fc6b31ea9be in pthread_mutex_lock () from /lib64/libpthread.so.0 #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so #3 0x00007fc6a7ec99b0 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #4 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #7 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #12 0x00007fc6a8d3758d in memberof_postop_modify () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so #13 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #14 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #15 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #16 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #17 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 #18 0x00007fc6b5932925 in connection_threadmain () #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 While thread 13 which hold the retrocl plugin lock, tries to acquire a page lock (held by thread 14) Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): 65 READ 1 WAIT changelog/changenumber.db page 68 Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): #0 0x00007fc6b31ed590 inpthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so #11 0x00007fc6a9672b70 in ldbm_back_seq () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 #13 0x00007fc6b54652a9 in slapi_seq_callback () from /usr/lib64/dirsrv/libslapd.so.0 #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #16 0x00007fc6a7ec99b5 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so #17 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 #18 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #19 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #20 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 #21 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 #22 0x00007fc6b5932925 in connection_threadmain () #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 Many others threads are waiting for others pages held by thread 14: Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): Thread 30 (Thread 0x7fc691922700 (LWP 1914)): Thread 28 (Thread 0x7fc690920700 (LWP 1916)): Thread 29 (Thread 0x7fc691121700 (LWP 1915)): 49 READ 1 WAIT changelog/objectclass.db page 1 Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): 65 READ 1 WAIT changelog/changenumber.db page 68 Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): 2 READ 1 WAIT userRoot/id2entry.db page 2495 On 05/06/2015 12:01 PM, ?ukasz Jaworski wrote: > dbstat: > > MacBookPro-10DDB1EAF1CC-1522:~ ender$ cat FILE > Default locking region information: > 139 Last allocated locker ID > 0x7fffffff Current maximum unused locker ID > 9 Number of lock modes > 200 Initial number of locks allocated > 0 Initial number of lockers allocated > 200 Initial number of lock objects allocated > 10000 Maximum number of locks possible > 10000 Maximum number of lockers possible > 10000 Maximum number of lock objects possible > 312 Current number of locks allocated > 151 Current number of lockers allocated > 250 Current number of lock objects allocated > 40 Number of lock object partitions > 8191 Size of object hash table > 275 Number of current locks > 303 Maximum number of locks at any one time > 6 Maximum number of locks in any one bucket > 174 Maximum number of locks stolen by for an empty partition > 13 Maximum number of locks stolen for any one partition > 124 Number of current lockers > 124 Maximum number of lockers at any one time > 223 Number of current lock objects > 233 Maximum number of lock objects at any one time > 3 Maximum number of lock objects in any one bucket > 49 Maximum number of objects stolen by for an empty partition > 5 Maximum number of objects stolen for any one partition > 82905 Total number of locks requested > 82018 Total number of locks released > 0 Total number of locks upgraded > 68 Total number of locks downgraded > 8 Lock requests not available due to conflicts, for which we waited > 12 Lock requests not available due to conflicts, for which we did not wait > 0 Number of deadlocks > 0 Lock timeout value > 0 Number of locks that have timed out > 0 Transaction timeout value > 0 Number of transactions that have timed out > 2MB 304KB Region size > 0 The number of partition locks that required waiting (0%) > 0 The maximum number of times any partition lock was waited for (0%) > 0 The number of object queue operations that required waiting (0%) > 0 The number of locker allocations that required waiting (0%) > 4 The number of region locks that required waiting (0%) > 5 Maximum hash bucket length > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock REGINFO information: > Environment Region type > 1 Region ID > /var/lib/dirsrv/slapd-xxxx/db/__db.001 Region name > 0x7fd376ff3000 Region address > 0x7fd376ff30a0 Region allocation head > 0x7fd376ffb2b0 Region primary address > 0 Region maximum allocation > 0 Region allocated > Region allocations: 796 allocations, 0 failures, 539 frees, 3 longest > Allocations by power-of-two sizes: > 1KB 781 > 2KB 3 > 4KB 6 > 8KB 3 > 16KB 0 > 32KB 1 > 64KB 0 > 128KB 0 > 256KB 2 > 512KB 0 > 1024KB 1 > REGION_SHARED Region flags > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock region parameters: > 2 Lock region region mutex [4/3168 0% !Own] > 16381 locker table size > 8191 object table size > 34128 obj_off > 889656 locker_off > 0 need_dd > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock conflict matrix: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by lockers: > Locker Mode Count Status ----------------- Object --------------- > 1 dd=122 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 1 READ 1 HELD userRoot/id2entry.db handle 0 > 2 dd=121 locks held 0 write locks 0 pid/thread 1863/140490519340800 flags 0 priority 100 > 2 READ 1 WAIT userRoot/id2entry.db page 2495 > 3 dd=120 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 3 READ 1 HELD ipaca/id2entry.db handle 0 > 4 dd=119 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 5 dd=118 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 5 READ 1 HELD ipaca/entryrdn.db handle 0 > 6 dd=117 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 7 dd=116 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 8 dd=115 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 9 dd=114 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db handle 0 > d dd=113 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > d READ 1 HELD ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 > f dd=112 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > f READ 1 HELD ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 > 10 dd=111 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 10 READ 1 HELD ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 > 13 dd=110 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 13 READ 1 HELD ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db handle 0 > 14 dd=109 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 14 READ 1 HELD ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 > 15 dd=108 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 15 READ 1 HELD ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 > 16 dd=107 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 16 READ 1 HELD ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 > 17 dd=106 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db handle 0 > 1c dd=105 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db handle 0 > 1d dd=104 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 1d READ 1 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 > 1f dd=103 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 1f READ 1 HELD ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 > 20 dd=102 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 20 READ 1 HELD ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 > 25 dd=101 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db handle 0 > 26 dd=100 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 26 READ 1 HELD ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 > 2a dd=99 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 2a READ 1 HELD ipaca/vlv#carevocationpkitomcatindex.db handle 0 > 2b dd=98 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 2b READ 1 HELD changelog/id2entry.db handle 0 > 2c dd=97 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 > 2d dd=96 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 2d READ 1 HELD changelog/entryusn.db handle 0 > 2e dd=95 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 2f dd=94 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 2f READ 1 HELD userRoot/entryusn.db handle 0 > 30 dd=93 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 31 dd=92 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 31 READ 1 HELD ipaca/entryusn.db handle 0 > 32 dd=91 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 33 dd=90 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 33 READ 1 HELD userRoot/entryrdn.db handle 0 > 34 dd=89 locks held 0 write locks 0 pid/thread 1863/140490839312128 flags 0 priority 100 > 35 dd=88 locks held 0 write locks 0 pid/thread 1863/140490510948096 flags 0 priority 100 > 36 dd=87 locks held 0 write locks 0 pid/thread 1863/140490519340800 flags 0 priority 100 > 37 dd=86 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 37 READ 1 HELD userRoot/objectclass.db handle 0 > 38 dd=85 locks held 0 write locks 0 pid/thread 1863/140490351486720 flags 0 priority 100 > 39 dd=84 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 39 READ 1 HELD userRoot/ancestorid.db handle 0 > 3a dd=83 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 3b dd=82 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 3b READ 1 HELD userRoot/macAddress.db handle 0 > 3c dd=81 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 3d dd=80 locks held 0 write locks 0 pid/thread 1863/140490435413760 flags 0 priority 100 > 3e dd=79 locks held 0 write locks 0 pid/thread 1863/140490343094016 flags 0 priority 100 > 3f dd=78 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 40 dd=77 locks held 0 write locks 0 pid/thread 1863/140490839312128 flags 0 priority 100 > 41 dd=76 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 42 dd=75 locks held 0 write locks 0 pid/thread 1863/140490510948096 flags 0 priority 100 > 43 dd=74 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 44 dd=73 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 44 READ 1 HELD changelog/entryrdn.db handle 0 > 45 dd=72 locks held 0 write locks 0 pid/thread 1863/140490494162688 flags 0 priority 100 > 46 dd=71 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 > 47 dd=70 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 48 dd=69 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 48 READ 1 HELD changelog/objectclass.db handle 0 > 49 dd=68 locks held 0 write locks 0 pid/thread 1863/140490334701312 flags 0 priority 100 > 49 READ 1 WAIT changelog/objectclass.db page 1 > 4a dd=67 locks held 0 write locks 0 pid/thread 1863/140491066709760 flags 0 priority 100 > 4b dd=66 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 4b READ 1 HELD ipaca/objectclass.db handle 0 > 4c dd=65 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 > 4d dd=64 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 4e dd=63 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 4e READ 1 HELD changelog/aci.db handle 0 > 4f dd=62 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 50 dd=61 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 50 READ 1 HELD userRoot/aci.db handle 0 > 51 dd=60 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 52 dd=59 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 52 READ 1 HELD ipaca/aci.db handle 0 > 53 dd=58 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 54 dd=57 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 54 READ 1 HELD userRoot/parentid.db handle 0 > 55 dd=56 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 56 dd=55 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 > 57 dd=54 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 57 READ 1 HELD userRoot/nsuniqueid.db handle 0 > 58 dd=53 locks held 0 write locks 0 pid/thread 1863/140490494162688 flags 0 priority 100 > 59 dd=52 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 > 5a dd=51 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 5b dd=50 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 5b READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db handle 0 > 5c dd=49 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 5d dd=48 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 5e dd=47 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 5e READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db handle 0 > 5f dd=46 locks held 0 write locks 0 pid/thread 1863/140491104614144 flags 0 priority 100 > 60 dd=45 locks held 0 write locks 0 pid/thread 1863/140491104614144 flags 0 priority 100 > 61 dd=44 locks held 0 write locks 0 pid/thread 1863/140491426347008 flags 0 priority 100 > 62 dd=43 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 > 63 dd=42 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 63 READ 1 HELD changelog/nsuniqueid.db handle 0 > 64 dd=41 locks held 1 write locks 0 pid/thread 1863/140491426347008 flags 10 priority 100 > 64 READ 1 HELD changelog/changenumber.db handle 0 > 65 dd=40 locks held 0 write locks 0 pid/thread 1863/140490410235648 flags 0 priority 100 > 65 READ 1 WAIT changelog/changenumber.db page 68 > 66 dd=39 locks held 0 write locks 0 pid/thread 1863/140490854885120 flags 0 priority 100 > 67 dd=38 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 > 67 READ 1 HELD changelog/targetuniqueid.db handle 0 > 68 dd=37 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 > 68 READ 1 HELD changelog/parentid.db handle 0 > 69 dd=36 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 > 69 READ 1 HELD changelog/ancestorid.db handle 0 > 6a dd=35 locks held 1 write locks 0 pid/thread 1863/140491066709760 flags 10 priority 100 > 6a READ 1 HELD changelog/numsubordinates.db handle 0 > 6b dd=34 locks held 0 write locks 0 pid/thread 1863/140490359879424 flags 0 priority 100 > 6b READ 1 WAIT changelog/objectclass.db page 1 > 6c dd=33 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 6c READ 1 HELD userRoot/nsTombstoneCSN.db handle 0 > 6d dd=32 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 6d READ 1 HELD userRoot/nscpEntryDN.db handle 0 > 6e dd=31 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 6e READ 1 HELD userRoot/numsubordinates.db handle 0 > 6f dd=30 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 6f READ 1 HELD userRoot/member.db handle 0 > 70 dd=29 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 70 READ 1 HELD userRoot/uniquemember.db handle 0 > 71 dd=28 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 71 READ 1 HELD userRoot/owner.db handle 0 > 72 dd=27 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 72 READ 1 HELD userRoot/seeAlso.db handle 0 > 73 dd=26 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 73 READ 1 HELD userRoot/manager.db handle 0 > 74 dd=25 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 74 READ 1 HELD userRoot/secretary.db handle 0 > 75 dd=24 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 75 READ 1 HELD userRoot/memberUser.db handle 0 > 76 dd=23 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 76 READ 1 HELD userRoot/memberHost.db handle 0 > 77 dd=22 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 77 READ 1 HELD userRoot/sourcehost.db handle 0 > 78 dd=21 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 78 READ 1 HELD userRoot/memberservice.db handle 0 > 79 dd=20 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 79 READ 1 HELD userRoot/managedby.db handle 0 > 7a dd=19 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 7a READ 1 HELD userRoot/memberallowcmd.db handle 0 > 7b dd=18 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 7b READ 1 HELD userRoot/memberdenycmd.db handle 0 > 7c dd=17 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 7c READ 1 HELD userRoot/ipasudorunas.db handle 0 > 7d dd=16 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 7d READ 1 HELD userRoot/ipasudorunasgroup.db handle 0 > 7e dd=15 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db handle 0 > 7f dd=14 locks held 1 write locks 0 pid/thread 1863/140490854885120 flags 10 priority 100 > 7f READ 1 HELD userRoot/ipaassignedidview.db handle 0 > 80 dd=13 locks held 0 write locks 0 pid/thread 1863/140490494162688 flags 0 priority 100 > 81 dd=12 locks held 0 write locks 0 pid/thread 1863/140490468984576 flags 0 priority 100 > 82 dd=11 locks held 1 write locks 0 pid/thread 1863/140490510948096 flags 10 priority 100 > 82 READ 1 HELD userRoot/krbPrincipalName.db handle 0 > 83 dd=10 locks held 0 write locks 0 pid/thread 1863/140490435413760 flags 0 priority 100 > 84 dd= 9 locks held 0 write locks 0 pid/thread 1863/140490510948096 flags 0 priority 100 > 85 dd= 8 locks held 1 write locks 0 pid/thread 1863/140490452199168 flags 10 priority 100 > 85 READ 1 HELD ipaca/requeststate.db handle 0 > 86 dd= 7 locks held 1 write locks 0 pid/thread 1863/140490452199168 flags 10 priority 100 > 86 READ 1 HELD ipaca/requesttype.db handle 0 > 87 dd= 4 locks held 1 write locks 0 pid/thread 1863/140490418628352 flags 10 priority 100 > 87 READ 1 HELD userRoot/memberOf.db handle 0 > 88 dd= 3 locks held 0 write locks 0 pid/thread 1863/140490822526720 flags 0 priority 100 > 88 READ 1 WAIT changelog/objectclass.db page 1 > 89 dd= 2 locks held 0 write locks 0 pid/thread 1863/140490805741312 flags 0 priority 100 > 89 READ 1 WAIT changelog/objectclass.db page 1 > 8a dd= 1 locks held 0 write locks 0 pid/thread 1863/140490839312128 flags 0 priority 100 > 8b dd= 0 locks held 0 write locks 0 pid/thread 1863/140490814134016 flags 0 priority 100 > 8b READ 1 WAIT changelog/objectclass.db page 1 > 800000f6 dd= 6 locks held 108 write locks 57 pid/thread 1863/140490418628352 flags 0 priority 100 > 800000f6 READ 4 HELD userRoot/member.db page 356 > 800000f6 READ 4 HELD userRoot/member.db page 360 > 800000f6 READ 2 HELD userRoot/member.db page 403 > 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 > 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 > 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 > 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 > 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 > 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 > 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 > 800000f6 READ 4 HELD userRoot/member.db page 405 > 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 > 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 > 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 > 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 > 800000f6 READ 3 HELD userRoot/memberHost.db page 96 > 800000f6 READ 10 HELD userRoot/memberUser.db page 166 > 800000f6 READ 15 HELD userRoot/member.db page 70 > 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 > 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 > 800000f6 READ 3 HELD userRoot/memberHost.db page 209 > 800000f6 READ 6 HELD userRoot/memberUser.db page 14 > 800000f6 READ 3 HELD userRoot/member.db page 26 > 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 > 800000f6 READ 5 HELD userRoot/memberHost.db page 87 > 800000f6 READ 10 HELD userRoot/member.db page 50 > 800000f6 READ 1 HELD userRoot/memberHost.db page 28 > 800000f6 READ 1 HELD userRoot/memberUser.db page 92 > 800000f6 READ 1 HELD userRoot/member.db page 43 > 800000f6 READ 2 HELD userRoot/memberUser.db page 103 > 800000f6 READ 2 HELD userRoot/member.db page 337 > 800000f6 READ 2 HELD userRoot/memberallowcmd.db page 44 > 800000f6 READ 2 HELD userRoot/memberdenycmd.db page 1 > 800000f6 READ 2 HELD userRoot/ipasudorunas.db page 1 > 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db page 1 > 800000f6 READ 2 HELD userRoot/objectclass.db page 10 > 800000f6 READ 15 HELD userRoot/member.db page 406 > 800000f6 READ 61 HELD userRoot/objectclass.db page 61 > 800000f6 READ 36 HELD userRoot/memberUser.db page 81 > 800000f6 READ 35 HELD userRoot/memberHost.db page 195 > 800000f6 READ 2 HELD userRoot/objectclass.db page 50 > 800000f6 READ 1 HELD changelog/nsuniqueid.db page 191 > 800000f6 READ 3 HELD changelog/entryrdn.db page 387 > 800000f6 READ 2 HELD changelog/entryrdn.db page 388 > 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 > 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 > 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 > 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 > 800000f6 WRITE 3 HELD changelog/objectclass.db page 1 > 800000f6 WRITE 1 HELD changelog/targetuniqueid.db page 47 > 800000f6 WRITE 1 HELD changelog/changenumber.db page 68 > 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page 191 > 800000f6 WRITE 1 HELD changelog/parentid.db page 1 > 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 > 800000f6 WRITE 1 HELD changelog/ancestorid.db page 1 > 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 > 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 > 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 > 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 > 800000f6 WRITE 1 HELD changelog/numsubordinates.db page 1 > 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 > 800000f6 READ 1 HELD userRoot/entryusn.db page 27 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 > 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 > 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 > 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 > 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 > 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 > 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 > 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 > 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 > 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 > 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 > 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 > 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 > 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 > 80000106 dd= 5 locks held 17 write locks 13 pid/thread 1863/140490410235648 flags 0 priority 100 > 80000106 WRITE 2 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 1 > 80000106 WRITE 4 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 5 > 80000106 WRITE 2 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 > 80000106 WRITE 4 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 > 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db page 1 > 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db page 5 > 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db page 1 > 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db page 5 > 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 > 80000106 READ 1 HELD ipaca/entryusn.db page 13 > 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 > 80000106 READ 1 HELD ipaca/requesttype.db page 1 > 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 > 80000106 READ 1 HELD ipaca/requeststate.db page 1 > 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 > 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 > 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 > 800001eb dd=4294967295 locks held 75 write locks 39 pid/thread 1863/140490418628352 flags 0 priority 100 > 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 > 800001eb READ 1 HELD userRoot/entryusn.db page 27 > 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 > 800001eb READ 1 HELD userRoot/memberOf.db page 219 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 > 800001eb READ 1 HELD userRoot/memberOf.db page 259 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 > 800001eb READ 1 HELD userRoot/memberOf.db page 253 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 > 800001eb READ 1 HELD userRoot/memberOf.db page 207 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 > 800001eb READ 1 HELD userRoot/memberOf.db page 91 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 > 800001eb READ 1 HELD userRoot/memberOf.db page 10 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 > 800001eb READ 1 HELD userRoot/memberOf.db page 211 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 > 800001eb READ 1 HELD userRoot/memberOf.db page 143 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 > 800001eb READ 1 HELD userRoot/memberOf.db page 121 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 > 800001eb READ 1 HELD userRoot/memberOf.db page 228 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 > 800001eb READ 1 HELD userRoot/memberOf.db page 78 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 > 800001eb READ 1 HELD userRoot/memberOf.db page 272 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 > 800001eb READ 1 HELD userRoot/memberOf.db page 189 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 > 800001eb READ 1 HELD userRoot/memberOf.db page 156 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 > 800001eb READ 1 HELD userRoot/memberOf.db page 148 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 > 800001eb READ 1 HELD userRoot/memberOf.db page 142 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 > 800001eb READ 1 HELD userRoot/memberOf.db page 258 > 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 > 800001eb READ 3 HELD userRoot/memberOf.db page 260 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 > 800001eb READ 1 HELD userRoot/memberOf.db page 218 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 > 800001eb READ 1 HELD userRoot/memberOf.db page 106 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 > 800001eb READ 1 HELD userRoot/memberOf.db page 141 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 > 800001eb READ 1 HELD userRoot/memberOf.db page 120 > 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 > 800001eb READ 2 HELD userRoot/memberOf.db page 126 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 > 800001eb READ 1 HELD userRoot/memberOf.db page 97 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 > 800001eb READ 1 HELD userRoot/memberOf.db page 196 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 > 800001eb READ 1 HELD userRoot/memberOf.db page 240 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 > 800001eb READ 1 HELD userRoot/memberOf.db page 73 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 > 800001eb READ 1 HELD userRoot/memberOf.db page 42 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 > 800001eb READ 1 HELD userRoot/memberOf.db page 251 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 > 800001eb READ 1 HELD userRoot/memberOf.db page 75 > 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 > 800001eb READ 2 HELD userRoot/memberOf.db page 271 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 > 800001eb READ 1 HELD userRoot/memberOf.db page 262 > 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 > 800001eb READ 3 HELD userRoot/memberOf.db page 255 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 > 800001eb READ 1 HELD userRoot/memberOf.db page 245 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 > 800001eb READ 1 HELD userRoot/memberOf.db page 19 > 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 > 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by object: > Locker Mode Count Status ----------------- Object --------------- > 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 > > 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 > > 2d READ 1 HELD changelog/entryusn.db handle 0 > > 39 READ 1 HELD userRoot/ancestorid.db handle 0 > > 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 > > 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db handle 0 > > 44 READ 1 HELD changelog/entryrdn.db handle 0 > > 800000f6 READ 1 HELD changelog/nsuniqueid.db page 191 > 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page 191 > > 63 READ 1 HELD changelog/nsuniqueid.db handle 0 > > 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 > > 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 > > 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 > > 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 > > 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db handle 0 > > d READ 1 HELD ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 > > 75 READ 1 HELD userRoot/memberUser.db handle 0 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 > > 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 > > 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 > > 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 > > 800000f6 READ 6 HELD userRoot/memberUser.db page 14 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 > > 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 > > 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 > > 800000f6 READ 36 HELD userRoot/memberUser.db page 81 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 > > 800000f6 READ 1 HELD userRoot/memberUser.db page 92 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 > 800000f6 READ 2 HELD userRoot/memberUser.db page 103 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 > > 800000f6 READ 10 HELD userRoot/memberUser.db page 166 > > 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 > > 68 READ 1 HELD changelog/parentid.db handle 0 > > 800000f6 WRITE 1 HELD changelog/parentid.db page 1 > > 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 > > 14 READ 1 HELD ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 > > 50 READ 1 HELD userRoot/aci.db handle 0 > > 7f READ 1 HELD userRoot/ipaassignedidview.db handle 0 > > 72 READ 1 HELD userRoot/seeAlso.db handle 0 > > 70 READ 1 HELD userRoot/uniquemember.db handle 0 > > 800000f6 READ 15 HELD userRoot/member.db page 406 > > 800000f6 READ 4 HELD userRoot/member.db page 405 > > 800000f6 READ 2 HELD userRoot/member.db page 403 > > 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 > > 16 READ 1 HELD ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 > > 52 READ 1 HELD ipaca/aci.db handle 0 > > 800000f6 READ 2 HELD userRoot/member.db page 337 > > 800000f6 READ 4 HELD userRoot/member.db page 360 > > 800000f6 READ 4 HELD userRoot/member.db page 356 > > 73 READ 1 HELD userRoot/manager.db handle 0 > > 7c READ 1 HELD userRoot/ipasudorunas.db handle 0 > > 800000f6 READ 2 HELD userRoot/ipasudorunas.db page 1 > > 7d READ 1 HELD userRoot/ipasudorunasgroup.db handle 0 > > 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db page 1 > > 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 > > 800000f6 READ 3 HELD userRoot/member.db page 26 > > 6f READ 1 HELD userRoot/member.db handle 0 > > 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 > > 800000f6 READ 10 HELD userRoot/member.db page 50 > > 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 > > 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 > > 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 > > 800000f6 READ 1 HELD userRoot/member.db page 43 > > 800000f6 READ 15 HELD userRoot/member.db page 70 > > 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 > > 800001eb READ 1 HELD userRoot/memberOf.db page 272 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 > > 800001eb READ 1 HELD userRoot/memberOf.db page 259 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 > > 800001eb READ 1 HELD userRoot/memberOf.db page 258 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 > > 800001eb READ 3 HELD userRoot/memberOf.db page 260 > 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 > > 800001eb READ 1 HELD userRoot/memberOf.db page 262 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 > > 800001eb READ 2 HELD userRoot/memberOf.db page 271 > 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 > > 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 > > 26 READ 1 HELD ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 > > 1f READ 1 HELD ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 > > 800001eb READ 1 HELD userRoot/memberOf.db page 19 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 > > 87 READ 1 HELD userRoot/memberOf.db handle 0 > > 800001eb READ 1 HELD userRoot/memberOf.db page 10 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 > > 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 > > 800001eb READ 1 HELD userRoot/memberOf.db page 42 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 > > 800001eb READ 1 HELD userRoot/memberOf.db page 91 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 > > 800001eb READ 1 HELD userRoot/memberOf.db page 73 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 > > 800001eb READ 1 HELD userRoot/memberOf.db page 75 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 > > 800001eb READ 1 HELD userRoot/memberOf.db page 78 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 > > 800001eb READ 1 HELD userRoot/memberOf.db page 121 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 > > 800001eb READ 1 HELD userRoot/memberOf.db page 120 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 > > 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 > > 1 READ 1 HELD userRoot/id2entry.db handle 0 > > 800001eb READ 2 HELD userRoot/memberOf.db page 126 > 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 > > 800001eb READ 1 HELD userRoot/memberOf.db page 97 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 > > 800001eb READ 1 HELD userRoot/memberOf.db page 106 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 > > 800001eb READ 1 HELD userRoot/memberOf.db page 148 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 > > 800001eb READ 1 HELD userRoot/memberOf.db page 156 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 > > 800001eb READ 1 HELD userRoot/memberOf.db page 141 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 > > 800001eb READ 1 HELD userRoot/memberOf.db page 143 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 > > 800001eb READ 1 HELD userRoot/memberOf.db page 142 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 > > 800001eb READ 1 HELD userRoot/memberOf.db page 189 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 > > 800001eb READ 1 HELD userRoot/memberOf.db page 211 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 > > 800001eb READ 1 HELD userRoot/memberOf.db page 219 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 > > 800001eb READ 1 HELD userRoot/memberOf.db page 218 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 > > 800001eb READ 1 HELD userRoot/memberOf.db page 196 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 > > f READ 1 HELD ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 > > 800001eb READ 1 HELD userRoot/memberOf.db page 207 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 > > 800001eb READ 1 HELD userRoot/memberOf.db page 240 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 > > 800001eb READ 1 HELD userRoot/memberOf.db page 245 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 > > 78 READ 1 HELD userRoot/memberservice.db handle 0 > > 800001eb READ 1 HELD userRoot/memberOf.db page 251 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 > > 800001eb READ 1 HELD userRoot/memberOf.db page 253 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 > > 800001eb READ 3 HELD userRoot/memberOf.db page 255 > 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 > > 800001eb READ 1 HELD userRoot/memberOf.db page 228 > 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 > > 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db page 1 > > 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db handle 0 > > 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db page 5 > > 13 READ 1 HELD ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db handle 0 > > 2a READ 1 HELD ipaca/vlv#carevocationpkitomcatindex.db handle 0 > > 74 READ 1 HELD userRoot/secretary.db handle 0 > > 5 READ 1 HELD ipaca/entryrdn.db handle 0 > > 85 READ 1 HELD ipaca/requeststate.db handle 0 > > 80000106 READ 1 HELD ipaca/requeststate.db page 1 > 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 > > 3b READ 1 HELD userRoot/macAddress.db handle 0 > > 6e READ 1 HELD userRoot/numsubordinates.db handle 0 > > 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db page 1 > > 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db handle 0 > > 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db page 5 > > 10 READ 1 HELD ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 > > 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 > 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 > 2 READ 1 WAIT userRoot/id2entry.db page 2495 > > 800000f6 READ 2 HELD userRoot/memberdenycmd.db page 1 > > 7b READ 1 HELD userRoot/memberdenycmd.db handle 0 > > 5e READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db handle 0 > > 4e READ 1 HELD changelog/aci.db handle 0 > > 67 READ 1 HELD changelog/targetuniqueid.db handle 0 > > 800000f6 WRITE 1 HELD changelog/targetuniqueid.db page 47 > > 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 > > 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 > > 2b READ 1 HELD changelog/id2entry.db handle 0 > > 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db handle 0 > > 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 > > 2f READ 1 HELD userRoot/entryusn.db handle 0 > > 31 READ 1 HELD ipaca/entryusn.db handle 0 > > 80000106 READ 1 HELD ipaca/entryusn.db page 13 > 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 > > 800000f6 READ 1 HELD userRoot/entryusn.db page 27 > 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 > 800001eb READ 1 HELD userRoot/entryusn.db page 27 > 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 > > 800000f6 WRITE 1 HELD changelog/changenumber.db page 68 > 65 READ 1 WAIT changelog/changenumber.db page 68 > > 64 READ 1 HELD changelog/changenumber.db handle 0 > > 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 > > 82 READ 1 HELD userRoot/krbPrincipalName.db handle 0 > > 800000f6 READ 2 HELD userRoot/memberallowcmd.db page 44 > > 33 READ 1 HELD userRoot/entryrdn.db handle 0 > > 80000106 READ 1 HELD ipaca/requesttype.db page 1 > 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 > > 86 READ 1 HELD ipaca/requesttype.db handle 0 > > 7a READ 1 HELD userRoot/memberallowcmd.db handle 0 > > 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 > > 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 > > 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 > > 37 READ 1 HELD userRoot/objectclass.db handle 0 > > 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 > > 800000f6 READ 2 HELD userRoot/objectclass.db page 10 > > 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 > > 77 READ 1 HELD userRoot/sourcehost.db handle 0 > > 800000f6 READ 2 HELD userRoot/objectclass.db page 50 > > 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 > > 48 READ 1 HELD changelog/objectclass.db handle 0 > > 800000f6 WRITE 3 HELD changelog/objectclass.db page 1 > 6b READ 1 WAIT changelog/objectclass.db page 1 > 49 READ 1 WAIT changelog/objectclass.db page 1 > 88 READ 1 WAIT changelog/objectclass.db page 1 > 89 READ 1 WAIT changelog/objectclass.db page 1 > 8b READ 1 WAIT changelog/objectclass.db page 1 > > 800000f6 READ 61 HELD userRoot/objectclass.db page 61 > > 80000106 WRITE 4 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 5 > > 20 READ 1 HELD ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 > > 80000106 WRITE 2 HELD ipaca/vlv#caenrollmentpkitomcatindex.db page 1 > > 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 > > 6a READ 1 HELD changelog/numsubordinates.db handle 0 > > 800000f6 WRITE 1 HELD changelog/numsubordinates.db page 1 > > 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 > > 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 > > 54 READ 1 HELD userRoot/parentid.db handle 0 > > 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 > > 800000f6 WRITE 1 HELD changelog/ancestorid.db page 1 > > 69 READ 1 HELD changelog/ancestorid.db handle 0 > > 4b READ 1 HELD ipaca/objectclass.db handle 0 > > 57 READ 1 HELD userRoot/nsuniqueid.db handle 0 > > 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 > > 5b READ 1 HELD /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db handle 0 > > 6d READ 1 HELD userRoot/nscpEntryDN.db handle 0 > > 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 > > 3 READ 1 HELD ipaca/id2entry.db handle 0 > > 6c READ 1 HELD userRoot/nsTombstoneCSN.db handle 0 > > 800000f6 READ 5 HELD userRoot/memberHost.db page 87 > > 800000f6 READ 3 HELD userRoot/memberHost.db page 96 > > 800000f6 READ 1 HELD userRoot/memberHost.db page 28 > > 76 READ 1 HELD userRoot/memberHost.db handle 0 > > 71 READ 1 HELD userRoot/owner.db handle 0 > > 800000f6 READ 3 HELD userRoot/memberHost.db page 209 > > 800000f6 READ 35 HELD userRoot/memberHost.db page 195 > > 15 READ 1 HELD ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 > > 80000106 WRITE 4 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 > > 1d READ 1 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 > > 80000106 WRITE 2 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 > > 79 READ 1 HELD userRoot/managedby.db handle 0 > > 800000f6 READ 3 HELD changelog/entryrdn.db page 387 > > 800000f6 READ 2 HELD changelog/entryrdn.db page 388 > 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 > > 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 > > > Lukasz Jaworski 'Ender' > > > Wiadomo?? napisana przez thierry bordaz w dniu 6 maj 2015, o godz. 11:47: > >> This is looking like thread 13 prevents thread 12 run (and all the others). >> Now thread 13 is likely waiting for db page? We may need output of db_stat (db_state -N -h /var/lib/dirsrv/slapd-xxx/db/ -CA) >> >> thanks >> thierry >> On 05/06/2015 11:31 AM, ?ukasz Jaworski wrote: >>>>> ldapsearch hangs. Dirsrv is not responding now. >>>> if the server is hanging, can you get a pstack >>> Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): >>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >>> #2 0x00007fc6a961f987 in deadlock_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): >>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >>> #2 0x00007fc6a9623a4e in checkpoint_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): >>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >>> #2 0x00007fc6a961fc0f in trickle_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): >>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >>> #2 0x00007fc6a961a667 in perf_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >>> #3 0x00007fc6abd455be in cos_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libcos-plugin.so >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): >>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>> #3 0x00007fc6a937be84 in _cl5TrimMain () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #3 0x00007fc6a93949e5 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #4 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #5 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #6 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #7 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): >>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>> #3 0x00007fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #4 0x00007fc6a9395158 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #5 0x00007fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #6 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #7 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #8 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 36 (Thread 0x7fc6a1203700 (LWP 1907)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 35 (Thread 0x7fc6a0a02700 (LWP 1908)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 >>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 34 (Thread 0x7fc693fff700 (LWP 1909)): >>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>> #3 0x00007fc6b593a773 in housecleaning () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 33 (Thread 0x7fc6937fe700 (LWP 1910)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #6 0x00007fc6a939f76f in replica_write_ruv () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #7 0x00007fc6a939f9fe in replica_update_state () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>> #8 0x00007fc6b542965a in eq_loop () from /usr/lib64/dirsrv/libslapd.so.0 >>> #9 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #10 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #11 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 32 (Thread 0x7fc692924700 (LWP 1912)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 31 (Thread 0x7fc692123700 (LWP 1913)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 30 (Thread 0x7fc691922700 (LWP 1914)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >>> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >>> #22 0x00007fc6b5943fc6 in do_search () >>> #23 0x00007fc6b5932b4c in connection_threadmain () >>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 29 (Thread 0x7fc691121700 (LWP 1915)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >>> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >>> #22 0x00007fc6b5943fc6 in do_search () >>> #23 0x00007fc6b5932b4c in connection_threadmain () >>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 28 (Thread 0x7fc690920700 (LWP 1916)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >>> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >>> #22 0x00007fc6b5943fc6 in do_search () >>> #23 0x00007fc6b5932b4c in connection_threadmain () >>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 27 (Thread 0x7fc67ffff700 (LWP 1917)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >>> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >>> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>> #8 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>> #10 0x00007fc6add50ced in __db_get () from /lib64/libdb-5.3.so >>> #11 0x00007fc6add5473b in __db_get_pp () from /lib64/libdb-5.3.so >>> #12 0x00007fc6a962a9bb in id2entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #13 0x00007fc6a9626cbd in dn2entry_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #14 0x00007fc6a9629bb1 in find_entry_internal.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #15 0x00007fc6a9629e99 in find_entry () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #16 0x00007fc6a9663b5b in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #17 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >>> #18 0x00007fc6b546553e in search_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #19 0x00007fc6b54657c8 in search_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #20 0x00007fc6b5465b73 in slapi_search_internal_get_entry () from /usr/lib64/dirsrv/libslapd.so.0 >>> #21 0x00007fc6aad02234 in ipalockout_preop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >>> #22 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #23 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #24 0x00007fc6b592c3d8 in do_bind () >>> #25 0x00007fc6b5932974 in connection_threadmain () >>> #26 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #27 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #28 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 25 (Thread 0x7fc67effd700 (LWP 1919)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 24 (Thread 0x7fc67e7fc700 (LWP 1920)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 23 (Thread 0x7fc67dffb700 (LWP 1921)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 22 (Thread 0x7fc67d7fa700 (LWP 1922)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >>> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #9 0x00007fc6b592c22d in do_bind () >>> #10 0x00007fc6b5932974 in connection_threadmain () >>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 21 (Thread 0x7fc67cff9700 (LWP 1923)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >>> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #9 0x00007fc6b592c22d in do_bind () >>> #10 0x00007fc6b5932974 in connection_threadmain () >>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 20 (Thread 0x7fc67c7f8700 (LWP 1924)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 19 (Thread 0x7fc67bff7700 (LWP 1925)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >>> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #9 0x00007fc6b592c22d in do_bind () >>> #10 0x00007fc6b5932974 in connection_threadmain () >>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 18 (Thread 0x7fc67b7f6700 (LWP 1926)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 17 (Thread 0x7fc67aff5700 (LWP 1927)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 16 (Thread 0x7fc67a7f4700 (LWP 1928)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 15 (Thread 0x7fc679ff3700 (LWP 1929)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): >>> #0 0x00007fc6b31eff1d in __lll_lock_wait () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b31ea9be in pthread_mutex_lock () from /lib64/libpthread.so.0 >>> #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so >>> #3 0x00007fc6a7ec99b0 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>> #4 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #5 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #6 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #7 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #8 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>> #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>> #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>> #12 0x00007fc6a8d3758d in memberof_postop_modify () from /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>> #13 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #14 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #15 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #16 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #17 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #18 0x00007fc6b5932925 in connection_threadmain () >>> #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >>> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >>> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>> #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so >>> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>> #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>> #11 0x00007fc6a9672b70 in ldbm_back_seq () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #13 0x00007fc6b54652a9 in slapi_seq_callback () from /usr/lib64/dirsrv/libslapd.so.0 >>> #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>> #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>> #16 0x00007fc6a7ec99b5 in retrocl_postob () from /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>> #17 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #18 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #19 0x00007fc6a965d231 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #20 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #21 0x00007fc6b544fbe7 in do_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #22 0x00007fc6b5932925 in connection_threadmain () >>> #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 12 (Thread 0x7fc6787f0700 (LWP 1932)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 11 (Thread 0x7fc677fef700 (LWP 1933)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 10 (Thread 0x7fc6777ee700 (LWP 1934)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >>> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #9 0x00007fc6b592c22d in do_bind () >>> #10 0x00007fc6b5932974 in connection_threadmain () >>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 9 (Thread 0x7fc676fed700 (LWP 1935)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #3 0x00007fc6a965d615 in ldbm_back_modify () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #4 0x00007fc6b544e905 in op_shared_modify () from /usr/lib64/dirsrv/libslapd.so.0 >>> #5 0x00007fc6b544f387 in modify_internal_pb () from /usr/lib64/dirsrv/libslapd.so.0 >>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so >>> #7 0x00007fc6b546156f in plugin_call_func () from /usr/lib64/dirsrv/libslapd.so.0 >>> #8 0x00007fc6b5461893 in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 >>> #9 0x00007fc6b592c22d in do_bind () >>> #10 0x00007fc6b5932974 in connection_threadmain () >>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 8 (Thread 0x7fc6767ec700 (LWP 1936)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >>> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >>> #22 0x00007fc6b5943fc6 in do_search () >>> #23 0x00007fc6b5932b4c in connection_threadmain () >>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 6 (Thread 0x7fc6757ea700 (LWP 1938)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 5 (Thread 0x7fc674fe9700 (LWP 1939)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so >>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so >>> #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so >>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>> #12 0x00007fc6a962e6de in idl_new_fetch () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #14 0x00007fc6a96272ed in keys2idl () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #15 0x00007fc6a9627afe in ava_candidates.isra () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #16 0x00007fc6a96280fa in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #17 0x00007fc6a96290ce in list_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #18 0x00007fc6a9628062 in filter_candidates_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #19 0x00007fc6a96631a7 in subtree_candidates () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #20 0x00007fc6a9664811 in ldbm_back_search () from /usr/lib64/dirsrv/plugins/libback-ldbm.so >>> #21 0x00007fc6b5455410 in op_shared_search () from /usr/lib64/dirsrv/libslapd.so.0 >>> #22 0x00007fc6b5943fc6 in do_search () >>> #23 0x00007fc6b5932b4c in connection_threadmain () >>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 3 (Thread 0x7fc673fe7700 (LWP 1941)): >>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 2 (Thread 0x7fc6737e6700 (LWP 1942)): >>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>> #1 0x00007fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 >>> #2 0x00007fc6b5933855 in time_thread () >>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>> Thread 1 (Thread 0x7fc6b58fb800 (LWP 1863)): >>> #0 0x00007fc6b2f18c8d in poll () from /lib64/libc.so.6 >>> #1 0x00007fc6b3843da8 in _pr_poll_with_poll () from /lib64/libnspr4.so >>> #2 0x00007fc6b5936b11 in slapd_daemon () >>> #3 0x00007fc6b59294f4 in main () >>> >>> >>>>> This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. >>>> the messages indicate there could be many concurrent operations, because individual ops are not fast enough, could your VM have less/slower resources than the physical machines ? >>> VMs have less rsources and slower than physical machines. >>> VM: 4 cpu, hd via drbd on sas drives, >>> >>> physical: more cores, faster (ssd) drives >>> >>> Best regards, >>> Lukasz Jaworski 'Ender' >>> >>> >>> >>>>> Lukasz Jaworski 'Ender' >>>>> >>>>> Wiadomo?? napisana przez Ludwig Krispenz w dniu 6 maj 2015, o godz. 10:52: >>>>> >>>>>> Hi, >>>>>> >>>>>> there seem to be different issues, >>>>>> - I don't know what the ipactl status is looking for when it generates the error message about no matching master, >>>>>> but I don't think it is related to the retro changelog. >>>>>> >>>>>> - the retro changelog errors for adding and deleting >>>>>> -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. >>>>>> the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases >>>>>> -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. >>>>>> Could you verify which changes are in the changelog, and if these are changing: >>>>>> ldapsearch -b "cn=changelog" dn >>>>>> >>>>>> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>>>>>> Hi, >>>>>>> >>>>>>> One of our replica hanged up morning. Error log after dirsrv restart: >>>>>>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) >>>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>>>>>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) >>>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. >>>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. >>>>>>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>>>>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>>>>>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) >>>>>>> >>>>>>> I did "re-initialize" from other replica. >>>>>>> >>>>>>> Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) >>>>>>> >>>>>>> # ipactl status >>>>>>> Failed to get list of services to probe status! >>>>>>> Configured hostname 'replica09.local' does not match any master server in LDAP: >>>>>>> replica01.local >>>>>>> replica02.local >>>>>>> replica03.local >>>>>>> replica04.local >>>>>>> replica05.local >>>>>>> replica06.local >>>>>>> replica07.local >>>>>>> replica08.local >>>>>>> replica09.local >>>>>>> replica10.local >>>>>>> replica09.local >>>>>>> >>>>>>> After dirsrv stop/start: >>>>>>> >>>>>>> In error logs there are many: >>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) >>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) >>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) >>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) >>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) >>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) >>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) >>>>>>> etc. >>>>>>> >>>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>>>>>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) >>>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. >>>>>>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. >>>>>>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] >>>>>>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>>> >>>>>>> Packages: >>>>>>> freeipa-server-4.1.3-2.fc21.x86_64 >>>>>>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>>>>>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>>>>>> >>>>>>> Best regards, >>>>>>> Ender >>>>>>> >>>>>> -- >>>>>> 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 From devans01 at gmail.com Wed May 6 11:42:31 2015 From: devans01 at gmail.com (Dylan Evans) Date: Wed, 6 May 2015 12:42:31 +0100 Subject: [Freeipa-users] Logging into Samba shares from non-domain trust Win7 PCs using IPA for Samba password auth. Message-ID: Hi, The goal is to have a common password to give users access to a Linux system via PuTTY/SSH and Samba file-shares where currently for historical reasons we have 2 passwords, which is a real PITA. The PuTTY logins work great but I need to get the logins for the Samba4 shares working from Win7 PCs that aren't part of a domain trust. I know it sounds wrong but it needs to be done this way for system segregation. I followed the instructions at http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA to get Samba4 set up to talk to IPA and it works great for Linux boxes on the domain using "smbclient -k". However I'm stuck trying to get non-domain Win7 boxes access to the shares. I've tried different domain\username combinations but not struck the right one. I presume I need to get some sort of non-Kerberos login method worked out, but I'm stuck. The Samba4 box is running CentOS Linux release 7.1.1503 with samba 4.1.12-21, ipa 4.1.0-18 and sssd 1.12.2-58. smb.conf: [global] workgroup = UNIX realm = UNIX.EXAMPLE.COM dedicated keytab file = FILE:/etc/samba/samba.keytab kerberos method = dedicated keytab log level = 2 log file = /var/log/samba/log.%m security = ads [Test_Share] path = /export/Test_Share writeable = yes browsable = yes write list = @TestGroup force group = TestGroup If anyone's interested I can add logs. Thanks, Dylan. From rmeggins at redhat.com Wed May 6 13:38:18 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 06 May 2015 07:38:18 -0600 Subject: [Freeipa-users] Known issues with IPA on VM? In-Reply-To: <5549B3F4.5050204@redhat.com> References: <5549B3F4.5050204@redhat.com> Message-ID: <554A194A.8070401@redhat.com> On 05/06/2015 12:25 AM, Martin Kosek wrote: > On 05/06/2015 07:48 AM, Christoph Kaminski wrote: >> Hi >> >> we have some undefinably problems here with IPA inside a VM (rhev/kvm). We >> has often zombie processes (defunct) with certmonger and dirsrv and >> segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with >> same Install (rhel7.1). We see these problems only on the VM's. Is there >> something already known about such problems? >> >> (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) > I do not recall any specific VM problems in particular (maybe except that NTPD > does not work too well in VMs), so I would recommend checking for the real > reasons of crash. Maybe there are some useful errors in the DS/certmonger log > files. > > If not, seeing the stack trace of the crash would help us/dirsrv developers > identify the problem: > > http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes > For IPA, to get full stacktraces, you will also need to do this: # debuginfo-install ipa-server slapi-nis From acm at morone.net Mon May 4 21:22:47 2015 From: acm at morone.net (Andrew Morone) Date: Mon, 4 May 2015 17:22:47 -0400 Subject: [Freeipa-users] Credentials constantly revoked for admin user Message-ID: I'm having this issue. I discovered when I would randomly get locked out of the admin account with the usual: kinit: Clients credentials have been revoked while getting initial credentials The scenario would go as follows: Sometimes I would try to issue "kinit admin", with the correct credentials only to be met with the above results. Other times it would work fine, only to fail when running an 'ipa' command. Anyway, I discovered a bunch of failed auth entries for admin in the logs, coming from clients. This would be mixed with successful logins from the same machine. So what it looks like is happening is that these failed logins would lock me out, sometimes in the middle of a session. Just waiting 60 seconds for the lock out to time out would allow me to continue my work. Has anyone seen this issue before? I'm using ipa server 3.0 on a CentOS 6.6 server. Thanks, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 6 13:57:43 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 May 2015 09:57:43 -0400 Subject: [Freeipa-users] Revocation of Issuing CA certificates In-Reply-To: References: Message-ID: <554A1DD7.1070303@redhat.com> Kamal Perera wrote: > Dear All, > > > How is the revocation of issuing CA certificates are handled? We are > using OCSP responders for revocation checking of certificates issued by > the Issuing CAs. So do we have to setup another OCSP or CRL distribution > point to let the applications to query for the revocation of issuing CA > certificates? Both points are encoded in the certificates that IPA issues: [ SNIP ] Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://ipa-ca.example.com/ca/ocsp" Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: CRL Distribution Points Distribution point: URI: "http://ipa-ca.example.com/ipa/crl/MasterCRL.bin" CRL issuer: Directory Name: "CN=Certificate Authority,O=ipaca" rob From abokovoy at redhat.com Wed May 6 14:23:58 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 6 May 2015 17:23:58 +0300 Subject: [Freeipa-users] Credentials constantly revoked for admin user In-Reply-To: References: Message-ID: <20150506142358.GT11785@redhat.com> On Mon, 04 May 2015, Andrew Morone wrote: >I'm having this issue. I discovered when I would randomly get locked out of >the admin account with the usual: >kinit: Clients credentials have been revoked while getting initial >credentials > > >The scenario would go as follows: >Sometimes I would try to issue "kinit admin", with the correct credentials >only to be met with the above results. Other times it would work fine, only >to fail when running an 'ipa' command. > >Anyway, I discovered a bunch of failed auth entries for admin in the logs, >coming from clients. This would be mixed with successful logins from the >same machine. So what it looks like is happening is that these failed >logins would lock me out, sometimes in the middle of a session. Just >waiting 60 seconds for the lock out to time out would allow me to continue >my work. Has anyone seen this issue before? I'm using ipa server 3.0 on a >CentOS 6.6 server. Are you using admin credentials as a bind DN from some application? Or some application which authenticates against LDAP is DoSed by someone. In any case you would need to look at /var/log/dirsrv/slapd-/access and /var/log/krb5kdc.log. Both logs have enough information to identify from which hosts these authentication attempts come and narrow down exploration of what happens on those hosts. -- / Alexander Bokovoy From nathan at nathanpeters.com Wed May 6 18:15:15 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 6 May 2015 11:15:15 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <20150506061248.GY3267@p.redhat.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> <20150506061248.GY3267@p.redhat.com> Message-ID: <6de84ca0250ed83df9c6ba0bf051ac6f.squirrel@webmail.nathanpeters.com> Ok, I have attempted to set this up by adding the AD domain to my configuration and it still isn't working. I just want to confirm what I'm trying to accomplish here before I list what I've done to troubleshoot this. We have an AD domain called corp.addomain.net. We have UPNs set so AD users login to the AD domain as adusername at addomain.net when they login to windows machines. The linux clients in our network are currently just using straight up kerberos authentication against the domain and can currently login as 'username' without entering any suffix. Because this means we can't control sudo policies centrally by our current direct kerberos connection, we want to switch to logging in through FreeIPA. I need to be clear that we want to maintain the current logins of just 'username' on Linux servers. To accomplish this, I added the following line to the sssd.conf file: default_domain_suffix = corp.addomain.net I have tried 3 different combinations of kerberos config to try to get the logins to work, but am running into errors in each case. I have tried to follow the suggestions given earlier in this thread. Here are the 3 krb.conf configurations I tried and the errors given on each try. -------------- configuration 1 ------------------- [realms] IPADOMAIN.NET = { kdc = dc1.ipadomain.net:88 master_kdc = dc1.ipadomain.net:88 admin_server = dc1.ipadomain.net:749 default_domain = ipadomain.net pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ auth_to_local = DEFAULT } CORP.ADDOMAIN.NET = { kdc = dc3.corp.addomain.net:88 master_kdc = dc3.corp.addomain.net:88 } [domain_realm] .ipadomain.net = IPADOMAIN.NET ipadomain.net = IPADOMAIN.NET .corp.addomain.net = CORP.ADDOMAIN.NET corp.addomain.net = CORP.ADDOMAIN.NET May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot find KDC for realm "ADDOMAIN.NET" May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot find KDC for realm "ADDOMAIN.NET" May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=adusername May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): received for user adusername: 4 (System error) May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for adusername from 10.5.5.57 port 1832 ssh2 ----------- configuration 2 ---------------- Notes : since the above error seemed to imply that I needed to add the 'UPN realm' to the [realms] section I tried to add it. [realms] IPADOMAIN.NET = { kdc = dc1.ipadomain.net:88 master_kdc = dc1.ipadomain.net:88 admin_server = dc1.ipadomain.net:749 default_domain = ipadomain.net pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ auth_to_local = DEFAULT } ADDOMAIN.NET = { kdc = dc3.corp.addomain.net:88 master_kdc = dc3.corp.addomain.net:88 } [domain_realm] .ipadomain.net = IPADOMAIN.NET ipadomain.net = IPADOMAIN.NET addomain.net = ADDOMAIN.NET .addomain.net = ADDOMAIN.NET May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm not local to KDC May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm not local to KDC May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=adusername May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): received for user adusername: 4 (System error) May 06 16:48:34 dc1.ipadomain.net sshd[7542]: Failed password for adusername from 10.5.5.57 port 1870 ssh2 ---- configuration 3 ----- Notes : Since the eror message given in the second try indicated that the realm wasn't local, I thought it might need both variations to recognize it as local. [realms] IPADOMAIN.NET = { kdc = dc1.ipadomain.net:88 master_kdc = dc1.ipadomain.net:88 admin_server = dc1.ipadomain.net:749 default_domain = ipadomain.net pkinit_anchors = FILE:/etc/ipa/ca.crt } ADDOMAIN.NET = { kdc = dc3.corp.addomain.net:88 master_kdc = dc3.corp.addomain.net:88 } CORP.ADDOMAIN.NET = { kdc = dc3.corp.addomain.net:88 master_kdc = dc3.corp.addomain.net:88 } [domain_realm] .ipadomain.net = IPADOMAIN.NET ipadomain.net = IPADOMAIN.NET addomain.net = ADDOMAIN.NET .addomain.net = ADDOMAIN.NET corp.addomain.net = CORP.ADDOMAIN.NET .corp.addomain.net = CORP.ADDOMAIN.NET May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm not local to KDC May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm not local to KDC May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=adusername May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): received for user adusername: 4 (System error) May 06 16:56:28 dc1.ipadomain.net sshd[7660]: Failed password for adusername from 10.5.5.57 port 1964 ssh2 > If you want to look up user data like e.g. the UID or the home > directory the IPA client will talk to the IPA server exclusively, if the > server does not know about the requested AD user it will try to get this > information from a AD DC. > > For authentication this is different, because only the AD DC should know > the password of the user. Hence authentication ans password changes as > well are done directly with the AD DC. > >> >> Also this page here : >> https://www.freeipa.org/page/Active_Directory_trust_setup >> >> does not list having to add the AD domain in the krb5.conf. Is that not >> necessary in the example because they are not using a different UPN for >> their users like we are? > > yes, it is because of the UPN in your case. As I said before this > special entry in krb5.conf would not be needed anymore if the IPA KDC > supports the Kerberos client referrals for the trusted domains. Adding > the entry to krb5.conf in only a work-around here. > > bye, > Sumit From nathan at nathanpeters.com Wed May 6 18:26:08 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 6 May 2015 11:26:08 -0700 Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves In-Reply-To: <5549F97E.4030708@redhat.com> References: <60ef069bdd1f65fa83f7905d7410e522.squirrel@webmail.nathanpeters.com> <01F17D22C8F4469CA6D3CD783379C48E@Azul> <5547314D.3020506@redhat.com> <628a95dd36f3507d9bb1c7bad00ea167.squirrel@webmail.nathanpeters.com> <5549F97E.4030708@redhat.com> Message-ID: Oh I feel silly now. I had the wrong IP in DNS for the server, so although forward and reverse lookups were working, it was sending the update to a server that was not a DNS server. Strangely enough, the logs did not show this attempt to notify the wrong server, they just ignored it completely. I fixed the IP and this is working now. Thanks! > Hello! > > On 5.5.2015 00:24, nathan at nathanpeters.com wrote: >> bind.x86_64 32:9.9.4-20.el7.centos.pkcs11 >> @mkosek-freeipa >> bind-dyndb-ldap.x86_64 6.1-1.el7.centos > > This version works for me (tested on Fedora 21). > >> And for reference here are the relevant A and NS records from my domain >> >> @ NS dc1.mydomain.net. >> @ NS dc2.mydomain.net. >> @ NS dns1.mydomain.net. >> dns1 A 10.21.0.14 > > I would recommend you to double check if commands > > $ dig @ dc1.mydomain.net. A > $ dig @ dc2.mydomain.net. A > $ dig @ dns1.mydomain.net. A > > actually return an IP addresses or not. Unfortunately BIND does not report > an > error if it is unable to resolve the name and silently ignores the name > when > notifications are sent. > > For testing purposes I use these commands (on server): > $ tcpdump -i any 'port 53' > $ rndc notify mydomain.net. > > Look for a line from tcpdump with note 'notify' in it. I can see the > notify > packet as soon as BIND prints 'sending notifies' message to the journal. > > I hope this helps. > > Petr^2 Spacek > >>> Hello! >>> >>> On 2.5.2015 17:12, Nathan Peters wrote: >>>> The last 3 sentences of my original post refer to me adding the NS >>>> records for >>>> the slave. Is that what you mean? >>>> >>>> "I have also ensured that the slave hostname and IP are in FreeIPA >>>> DNS. >>>> I >>>> have also added an NS entry pointing to the slave." >>> >>> Which version of FreeIPA and bind-dyndb-ldap are you using? >>> >>> I will look into it. >>> >>> Petr^2 Spacek >>> >>> >>>> -----Original Message----- From: Baird, Josh >>>> Sent: Saturday, May 02, 2015 7:33 AM >>>> To: 'nathan at nathanpeters.com' ; freeipa-users at redhat.com >>>> Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being >>>> sent to >>>> slaves >>>> >>>> Is the PowerDNS slave in the NS RRSet for the IPA domain? >>>> Unfortuantely, >>>> bind-dyndb-ldap does not support 'also-notify' which would allow us to >>>> send >>>> notifies each time a zone update occurs to slave servers that are not >>>> in >>>> the >>>> RRSet [1]. To compensate for this in my environment, I had to lower >>>> the >>>> 'refresh' timer on the IPA zone. >>>> >>>> [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 >>>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of >>>> nathan at nathanpeters.com >>>> Sent: Friday, May 1, 2015 8:20 PM >>>> To: freeipa-users at redhat.com >>>> Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being >>>> sent >>>> to slaves >>>> >>>> I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. >>>> >>>> I also have another host running PowerDNS serving as a slave. >>>> The FreeIPA servers are setup to allow transfers to the slave by IP. >>>> When >>>> adding the zone, the slave transfered it properly. >>>> >>>> However, when I update the zone in FreeIPA, although the serial number >>>> changes, in the /var/log/messages I only see an attempt to transfer to >>>> the >>>> second IPA server, and not the slave. This is the only log entry : >>>> >>>> May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending >>>> notifies >>>> (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client >>>> 10.178.0.99#29832: received notify for zone 'mydomain.net' >>>> >>>> I have restarted all services using ipactl restart several times. I >>>> have also >>>> ensured that the slave hostname and IP are in FreeIPA DNS. I have >>>> also >>>> added >>>> an NS entry pointing to the slave. >>>> >>>> According to the FreeIPA manual, once that NS entry is added, any zone >>>> updates >>>> should trigger a notify, but still the only notifications go out to >>>> FreeIPA >>>> servers and nothing else. >>>> >>>> Any idea how to fix this so FreeIPA notifies non IPA servers? I'm >>>> pretty sure >>>> I've followed all the instructions to the letter on this one... > From stacy.redmond at blueshieldca.com Wed May 6 18:53:49 2015 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Wed, 6 May 2015 18:53:49 +0000 Subject: [Freeipa-users] Removing REALM requirement and home directory location In-Reply-To: <55487FCC.2090106@redhat.com> References: <5434D6A65FEF2B428D5CC8D77FA7DA7106A41CD8@wexc201p.bsc.bscal.com> <55487FCC.2090106@redhat.com> Message-ID: <5434D6A65FEF2B428D5CC8D77FA7DA7106A46824@wexc201p.bsc.bscal.com> That's great, I got it all working, perhaps you can answer one last question, although not sure this is going to be fixable or not. Anyway to get rid of the realm when using id, as you can see below, kinda messy. [root at linuxtest1 home]# su - aduser1 -sh-4.1$ id uid=1989603105(aduser1 at sbx.local) gid=1989603105(aduser1 at sbx.local) groups=1989603105(aduser1 at sbx.local) -sh-4.1$ pwd /home/aduser1 -sh-4.1$ ls -l /home/ total 4 drwxr-xr-x 2 aduser1 at sbx.local aduser1 at sbx.local 4096 May 5 09:38 aduser1 -sh-4.1$ From: Tomas Babej [mailto:tbabej at redhat.com] Sent: Tuesday, May 05, 2015 1:31 AM To: Redmond, Stacy; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Removing REALM requirement and home directory location On 05/04/2015 08:50 PM, Redmond, Stacy wrote: I am running a RHEL7 IPA Server ipa-server 3.3.3-28 RHEL6 clients running IPA Client 3.0.0-42 I have setup an AD trust which works great, however I want to make it so the users don't have to use @realm to login and that their home directory does not default to /home/realm/username Also note that you can override the home directory location using the override_homedir directive. See man sssd.conf for more details. AD sbx.local IPA unix.sbx.local Works great User login: ssh username at realm@hostname $ ssh aduser1 at sbx@linuxtest1.sbx.local aduser1 at sbx@linuxtest1.sbx.local's password: Last login: Fri May 1 09:36:53 2015 from xxx.xxx.xxx.xxx Could not chdir to home directory /home/sbx.local/aduser1: No such file or directory $ Any and all help is appreciated. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From APtashnik at cccis.com Wed May 6 20:28:06 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Wed, 6 May 2015 20:28:06 +0000 Subject: [Freeipa-users] Using CNAME to point to different domain name Message-ID: Hello Team, We are hosting a few servers at Amazon and using their Elastic Load Balancing service that gives us a link to a load balancer in the following format: webserver-1234567890.us-east-1.elb.amazonaws.com I was looking for a ways to implement a shorter alias using CNAME like: webserver.mydomain.com pointing to longer link from the load balancer webserver-1234567890.us-west-2.elb.amazonaws.com Is there a way to do it in RHEL 7.1 with IPA server 4.1.0 using different domain names? Regards, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From APtashnik at cccis.com Wed May 6 20:28:06 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Wed, 6 May 2015 20:28:06 +0000 Subject: [Freeipa-users] Using CNAME to point to different domain name Message-ID: Hello Team, We are hosting a few servers at Amazon and using their Elastic Load Balancing service that gives us a link to a load balancer in the following format: webserver-1234567890.us-east-1.elb.amazonaws.com I was looking for a ways to implement a shorter alias using CNAME like: webserver.mydomain.com pointing to longer link from the load balancer webserver-1234567890.us-west-2.elb.amazonaws.com Is there a way to do it in RHEL 7.1 with IPA server 4.1.0 using different domain names? Regards, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From box31978 at gmail.com Wed May 6 21:11:11 2015 From: box31978 at gmail.com (box 31978) Date: Wed, 6 May 2015 23:11:11 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients Message-ID: Hello everyone, These days I'm testing integration between FreeIPA4 and Samba4 at file sharing level. Everything seems to work fine except share access from a standalone Windows client. This is the setup (everything is up-to-date): - ipa-server: CentOS 7.1, ipa-server 4.1, ipa-server-trust-ad plugin - file-server: CentOS 7.1, ipa-client 4.1, samba 4.1 (sharing home dirs, not a DC) - win-client: Windows 7 Home Premium Config is done following the FreeIPA's Samba integration guide, and testing with samba-client from ipa-server (or any other ipa-joined machine) to file-server using kerberos after calling kinit is successful (file manipulation included). Attempts to connect to the same share from win-client ends up with a log in error. Analyzing logs: Samba can't find the user because it can't find any DC, and that's because Samba can't resolve workgroup name (note that's not a question of SSO: win-client asks to type username and password). It seems that maybe Samba is not handling new kerberos ticket requests. By now, my questions are: - Can this setup work or it is absolutely necessary that any Windows client expecting to access Samba shares have to be already joined to a trusted domain? - If this setup can't be done, I'll go for an LDAP config in file-server against ipa-server, but then, can I maintain the file-server joined with ipa-client? Will it work? Feel free to ask whatever you want, any suggestions will be welcome. Thanks! Regards, A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu May 7 00:05:10 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 May 2015 20:05:10 -0400 Subject: [Freeipa-users] Problem with replication In-Reply-To: <5549FAFF.1080905@redhat.com> References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> <5549DE08.1090502@redhat.com> <5549E31F.4040809@redhat.com> <5549FAFF.1080905@redhat.com> Message-ID: <554AAC36.5050409@redhat.com> On 05/06/2015 07:29 AM, thierry bordaz wrote: > This is looking like a deadlock between thread 14 and thread 13 where > both threads acquired lock in the opposite order. > Thread 14 is processing a betxn_postop but thread 13 is doing a > postop. I wonder if the problem is that the test/set of the > changenumber is done outside of the backend lock. Is this enough info to open a ticket? > > > Thread 14 holds some db page locks and tries to acquire retrocl plugin > lock (retrocl_internal_lock) > 800000f6 dd= 6 locks held 108 write locks 57 pid/thread > 1863/140490418628352 flags 0 priority 100 > 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 > 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 > 800000f6 WRITE 3 HELD changelog/objectclass.db page 1 > 800000f6 WRITE 1 HELD changelog/changenumber.db > page 68 > > Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): > #0 0x00007fc6b31eff1d in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007fc6b31ea9be in pthread_mutex_lock () from > /lib64/libpthread.so.0 > #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so > #3 0x00007fc6a7ec99b0 in retrocl_postob () from > /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #4 0x00007fc6b546156f in plugin_call_func () from > /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007fc6b5461893 in plugin_call_plugins () from > /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007fc6a965d231 in ldbm_back_modify () from > /usr/lib64/dirsrv/plugins/libback-ldbm.so > #7 0x00007fc6b544e905 in op_shared_modify () from > /usr/lib64/dirsrv/libslapd.so.0 > #8 0x00007fc6b544f387 in modify_internal_pb () from > /usr/lib64/dirsrv/libslapd.so.0 > #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from > /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from > /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from > /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #12 0x00007fc6a8d3758d in memberof_postop_modify () from > /usr/lib64/dirsrv/plugins/libmemberof-plugin.so > #13 0x00007fc6b546156f in plugin_call_func () from > /usr/lib64/dirsrv/libslapd.so.0 > #14 0x00007fc6b5461893 in plugin_call_plugins () from > /usr/lib64/dirsrv/libslapd.so.0 > #15 0x00007fc6a965d231 in ldbm_back_modify () from > /usr/lib64/dirsrv/plugins/libback-ldbm.so > #16 0x00007fc6b544e905 in op_shared_modify () from > /usr/lib64/dirsrv/libslapd.so.0 > #17 0x00007fc6b544fbe7 in do_modify () from > /usr/lib64/dirsrv/libslapd.so.0 > #18 0x00007fc6b5932925 in connection_threadmain () > #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > > While thread 13 which hold the retrocl plugin lock, tries to acquire > a page lock (held by thread 14) > > Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): > 65 READ 1 WAIT changelog/changenumber.db page 68 > > Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): > #0 0x00007fc6b31ed590 inpthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from > /lib64/libdb-5.3.so > #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from /lib64/libdb-5.3.so > #3 0x00007fc6add2aa91 in __lock_get_internal () from /lib64/libdb-5.3.so > #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so > #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so > #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so > #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so > #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so > #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so > #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so > #11 0x00007fc6a9672b70 in ldbm_back_seq () from > /usr/lib64/dirsrv/plugins/libback-ldbm.so > #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from > /usr/lib64/dirsrv/libslapd.so.0 > #13 0x00007fc6b54652a9 in slapi_seq_callback () from > /usr/lib64/dirsrv/libslapd.so.0 > #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from > /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from > /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #16 0x00007fc6a7ec99b5 in retrocl_postob () from > /usr/lib64/dirsrv/plugins/libretrocl-plugin.so > #17 0x00007fc6b546156f in plugin_call_func () from > /usr/lib64/dirsrv/libslapd.so.0 > #18 0x00007fc6b5461893 in plugin_call_plugins () from > /usr/lib64/dirsrv/libslapd.so.0 > #19 0x00007fc6a965d231 in ldbm_back_modify () from > /usr/lib64/dirsrv/plugins/libback-ldbm.so > #20 0x00007fc6b544e905 in op_shared_modify () from > /usr/lib64/dirsrv/libslapd.so.0 > #21 0x00007fc6b544fbe7 in do_modify () from > /usr/lib64/dirsrv/libslapd.so.0 > #22 0x00007fc6b5932925 in connection_threadmain () > #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so > #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 > #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 > > Many others threads are waiting for others pages held by thread 14: > > > Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): > Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): > Thread 30 (Thread 0x7fc691922700 (LWP 1914)): > Thread 28 (Thread 0x7fc690920700 (LWP 1916)): > Thread 29 (Thread 0x7fc691121700 (LWP 1915)): > 49 READ 1 WAIT changelog/objectclass.db page 1 > > Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): > 65 READ 1 WAIT changelog/changenumber.db page 68 > > Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): > 2 READ 1 WAIT userRoot/id2entry.db page 2495 > > > > On 05/06/2015 12:01 PM, ?ukasz Jaworski wrote: >> dbstat: >> >> MacBookPro-10DDB1EAF1CC-1522:~ ender$ cat FILE >> Default locking region information: >> 139 Last allocated locker ID >> 0x7fffffff Current maximum unused locker ID >> 9 Number of lock modes >> 200 Initial number of locks allocated >> 0 Initial number of lockers allocated >> 200 Initial number of lock objects allocated >> 10000 Maximum number of locks possible >> 10000 Maximum number of lockers possible >> 10000 Maximum number of lock objects possible >> 312 Current number of locks allocated >> 151 Current number of lockers allocated >> 250 Current number of lock objects allocated >> 40 Number of lock object partitions >> 8191 Size of object hash table >> 275 Number of current locks >> 303 Maximum number of locks at any one time >> 6 Maximum number of locks in any one bucket >> 174 Maximum number of locks stolen by for an empty partition >> 13 Maximum number of locks stolen for any one partition >> 124 Number of current lockers >> 124 Maximum number of lockers at any one time >> 223 Number of current lock objects >> 233 Maximum number of lock objects at any one time >> 3 Maximum number of lock objects in any one bucket >> 49 Maximum number of objects stolen by for an empty partition >> 5 Maximum number of objects stolen for any one partition >> 82905 Total number of locks requested >> 82018 Total number of locks released >> 0 Total number of locks upgraded >> 68 Total number of locks downgraded >> 8 Lock requests not available due to conflicts, for which we waited >> 12 Lock requests not available due to conflicts, for which we did >> not wait >> 0 Number of deadlocks >> 0 Lock timeout value >> 0 Number of locks that have timed out >> 0 Transaction timeout value >> 0 Number of transactions that have timed out >> 2MB 304KB Region size >> 0 The number of partition locks that required waiting (0%) >> 0 The maximum number of times any partition lock was waited for (0%) >> 0 The number of object queue operations that required waiting (0%) >> 0 The number of locker allocations that required waiting (0%) >> 4 The number of region locks that required waiting (0%) >> 5 Maximum hash bucket length >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Lock REGINFO information: >> Environment Region type >> 1 Region ID >> /var/lib/dirsrv/slapd-xxxx/db/__db.001 Region name >> 0x7fd376ff3000 Region address >> 0x7fd376ff30a0 Region allocation head >> 0x7fd376ffb2b0 Region primary address >> 0 Region maximum allocation >> 0 Region allocated >> Region allocations: 796 allocations, 0 failures, 539 frees, 3 longest >> Allocations by power-of-two sizes: >> 1KB 781 >> 2KB 3 >> 4KB 6 >> 8KB 3 >> 16KB 0 >> 32KB 1 >> 64KB 0 >> 128KB 0 >> 256KB 2 >> 512KB 0 >> 1024KB 1 >> REGION_SHARED Region flags >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Lock region parameters: >> 2 Lock region region mutex [4/3168 0% !Own] >> 16381 locker table size >> 8191 object table size >> 34128 obj_off >> 889656 locker_off >> 0 need_dd >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Lock conflict matrix: >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Locks grouped by lockers: >> Locker Mode Count Status ----------------- Object >> --------------- >> 1 dd=122 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 1 READ 1 HELD userRoot/id2entry.db handle 0 >> 2 dd=121 locks held 0 write locks 0 pid/thread >> 1863/140490519340800 flags 0 priority 100 >> 2 READ 1 WAIT userRoot/id2entry.db page 2495 >> 3 dd=120 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 3 READ 1 HELD ipaca/id2entry.db handle 0 >> 4 dd=119 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 5 dd=118 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 5 READ 1 HELD ipaca/entryrdn.db handle 0 >> 6 dd=117 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 7 dd=116 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 8 dd=115 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 9 dd=114 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db >> handle 0 >> d dd=113 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> d READ 1 HELD >> ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 >> f dd=112 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> f READ 1 HELD >> ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 >> 10 dd=111 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 10 READ 1 HELD >> ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 >> 13 dd=110 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 13 READ 1 HELD >> ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db >> handle 0 >> 14 dd=109 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 14 READ 1 HELD >> ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 >> 15 dd=108 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 15 READ 1 HELD >> ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 >> 16 dd=107 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 16 READ 1 HELD >> ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 >> 17 dd=106 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db >> handle 0 >> 1c dd=105 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db >> handle 0 >> 1d dd=104 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 1d READ 1 HELD >> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 >> 1f dd=103 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 1f READ 1 HELD >> ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 >> 20 dd=102 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 20 READ 1 HELD >> ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 >> 25 dd=101 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db >> handle 0 >> 26 dd=100 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 26 READ 1 HELD >> ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 >> 2a dd=99 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 2a READ 1 HELD >> ipaca/vlv#carevocationpkitomcatindex.db handle 0 >> 2b dd=98 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 2b READ 1 HELD changelog/id2entry.db handle 0 >> 2c dd=97 locks held 0 write locks 0 pid/thread >> 1863/140490468984576 flags 0 priority 100 >> 2d dd=96 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 2d READ 1 HELD changelog/entryusn.db handle 0 >> 2e dd=95 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 2f dd=94 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 2f READ 1 HELD userRoot/entryusn.db handle 0 >> 30 dd=93 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 31 dd=92 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 31 READ 1 HELD ipaca/entryusn.db handle 0 >> 32 dd=91 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 33 dd=90 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 33 READ 1 HELD userRoot/entryrdn.db handle 0 >> 34 dd=89 locks held 0 write locks 0 pid/thread >> 1863/140490839312128 flags 0 priority 100 >> 35 dd=88 locks held 0 write locks 0 pid/thread >> 1863/140490510948096 flags 0 priority 100 >> 36 dd=87 locks held 0 write locks 0 pid/thread >> 1863/140490519340800 flags 0 priority 100 >> 37 dd=86 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 37 READ 1 HELD userRoot/objectclass.db >> handle 0 >> 38 dd=85 locks held 0 write locks 0 pid/thread >> 1863/140490351486720 flags 0 priority 100 >> 39 dd=84 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 39 READ 1 HELD userRoot/ancestorid.db handle 0 >> 3a dd=83 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 3b dd=82 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 3b READ 1 HELD userRoot/macAddress.db handle 0 >> 3c dd=81 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 3d dd=80 locks held 0 write locks 0 pid/thread >> 1863/140490435413760 flags 0 priority 100 >> 3e dd=79 locks held 0 write locks 0 pid/thread >> 1863/140490343094016 flags 0 priority 100 >> 3f dd=78 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 40 dd=77 locks held 0 write locks 0 pid/thread >> 1863/140490839312128 flags 0 priority 100 >> 41 dd=76 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 42 dd=75 locks held 0 write locks 0 pid/thread >> 1863/140490510948096 flags 0 priority 100 >> 43 dd=74 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 44 dd=73 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 44 READ 1 HELD changelog/entryrdn.db handle 0 >> 45 dd=72 locks held 0 write locks 0 pid/thread >> 1863/140490494162688 flags 0 priority 100 >> 46 dd=71 locks held 0 write locks 0 pid/thread >> 1863/140490468984576 flags 0 priority 100 >> 47 dd=70 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 48 dd=69 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 48 READ 1 HELD changelog/objectclass.db >> handle 0 >> 49 dd=68 locks held 0 write locks 0 pid/thread >> 1863/140490334701312 flags 0 priority 100 >> 49 READ 1 WAIT changelog/objectclass.db >> page 1 >> 4a dd=67 locks held 0 write locks 0 pid/thread >> 1863/140491066709760 flags 0 priority 100 >> 4b dd=66 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 4b READ 1 HELD ipaca/objectclass.db handle 0 >> 4c dd=65 locks held 0 write locks 0 pid/thread >> 1863/140490468984576 flags 0 priority 100 >> 4d dd=64 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 4e dd=63 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 4e READ 1 HELD changelog/aci.db handle 0 >> 4f dd=62 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 50 dd=61 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 50 READ 1 HELD userRoot/aci.db handle 0 >> 51 dd=60 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 52 dd=59 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 52 READ 1 HELD ipaca/aci.db handle 0 >> 53 dd=58 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 54 dd=57 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 54 READ 1 HELD userRoot/parentid.db handle 0 >> 55 dd=56 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 56 dd=55 locks held 0 write locks 0 pid/thread >> 1863/140490468984576 flags 0 priority 100 >> 57 dd=54 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 57 READ 1 HELD userRoot/nsuniqueid.db handle 0 >> 58 dd=53 locks held 0 write locks 0 pid/thread >> 1863/140490494162688 flags 0 priority 100 >> 59 dd=52 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 >> 5a dd=51 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 5b dd=50 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 5b READ 1 HELD >> /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db >> handle 0 >> 5c dd=49 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 5d dd=48 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 5e dd=47 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 5e READ 1 HELD >> /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db >> handle 0 >> 5f dd=46 locks held 0 write locks 0 pid/thread >> 1863/140491104614144 flags 0 priority 100 >> 60 dd=45 locks held 0 write locks 0 pid/thread >> 1863/140491104614144 flags 0 priority 100 >> 61 dd=44 locks held 0 write locks 0 pid/thread >> 1863/140491426347008 flags 0 priority 100 >> 62 dd=43 locks held 0 write locks 0 pid/thread >> 1863/140490468984576 flags 0 priority 100 >> 63 dd=42 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 63 READ 1 HELD changelog/nsuniqueid.db >> handle 0 >> 64 dd=41 locks held 1 write locks 0 pid/thread >> 1863/140491426347008 flags 10 priority 100 >> 64 READ 1 HELD changelog/changenumber.db >> handle 0 >> 65 dd=40 locks held 0 write locks 0 pid/thread >> 1863/140490410235648 flags 0 priority 100 >> 65 READ 1 WAIT changelog/changenumber.db >> page 68 >> 66 dd=39 locks held 0 write locks 0 pid/thread >> 1863/140490854885120 flags 0 priority 100 >> 67 dd=38 locks held 1 write locks 0 pid/thread >> 1863/140491066709760 flags 10 priority 100 >> 67 READ 1 HELD changelog/targetuniqueid.db >> handle 0 >> 68 dd=37 locks held 1 write locks 0 pid/thread >> 1863/140491066709760 flags 10 priority 100 >> 68 READ 1 HELD changelog/parentid.db handle 0 >> 69 dd=36 locks held 1 write locks 0 pid/thread >> 1863/140491066709760 flags 10 priority 100 >> 69 READ 1 HELD changelog/ancestorid.db >> handle 0 >> 6a dd=35 locks held 1 write locks 0 pid/thread >> 1863/140491066709760 flags 10 priority 100 >> 6a READ 1 HELD changelog/numsubordinates.db >> handle 0 >> 6b dd=34 locks held 0 write locks 0 pid/thread >> 1863/140490359879424 flags 0 priority 100 >> 6b READ 1 WAIT changelog/objectclass.db >> page 1 >> 6c dd=33 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 6c READ 1 HELD userRoot/nsTombstoneCSN.db >> handle 0 >> 6d dd=32 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 6d READ 1 HELD userRoot/nscpEntryDN.db >> handle 0 >> 6e dd=31 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 6e READ 1 HELD userRoot/numsubordinates.db >> handle 0 >> 6f dd=30 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 6f READ 1 HELD userRoot/member.db handle 0 >> 70 dd=29 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 70 READ 1 HELD userRoot/uniquemember.db >> handle 0 >> 71 dd=28 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 71 READ 1 HELD userRoot/owner.db handle 0 >> 72 dd=27 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 72 READ 1 HELD userRoot/seeAlso.db handle 0 >> 73 dd=26 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 73 READ 1 HELD userRoot/manager.db handle 0 >> 74 dd=25 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 74 READ 1 HELD userRoot/secretary.db handle 0 >> 75 dd=24 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 75 READ 1 HELD userRoot/memberUser.db handle 0 >> 76 dd=23 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 76 READ 1 HELD userRoot/memberHost.db handle 0 >> 77 dd=22 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 77 READ 1 HELD userRoot/sourcehost.db handle 0 >> 78 dd=21 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 78 READ 1 HELD userRoot/memberservice.db >> handle 0 >> 79 dd=20 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 79 READ 1 HELD userRoot/managedby.db handle 0 >> 7a dd=19 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 7a READ 1 HELD userRoot/memberallowcmd.db >> handle 0 >> 7b dd=18 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 7b READ 1 HELD userRoot/memberdenycmd.db >> handle 0 >> 7c dd=17 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 7c READ 1 HELD userRoot/ipasudorunas.db >> handle 0 >> 7d dd=16 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 7d READ 1 HELD userRoot/ipasudorunasgroup.db >> handle 0 >> 7e dd=15 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db >> handle 0 >> 7f dd=14 locks held 1 write locks 0 pid/thread >> 1863/140490854885120 flags 10 priority 100 >> 7f READ 1 HELD userRoot/ipaassignedidview.db >> handle 0 >> 80 dd=13 locks held 0 write locks 0 pid/thread >> 1863/140490494162688 flags 0 priority 100 >> 81 dd=12 locks held 0 write locks 0 pid/thread >> 1863/140490468984576 flags 0 priority 100 >> 82 dd=11 locks held 1 write locks 0 pid/thread >> 1863/140490510948096 flags 10 priority 100 >> 82 READ 1 HELD userRoot/krbPrincipalName.db >> handle 0 >> 83 dd=10 locks held 0 write locks 0 pid/thread >> 1863/140490435413760 flags 0 priority 100 >> 84 dd= 9 locks held 0 write locks 0 pid/thread >> 1863/140490510948096 flags 0 priority 100 >> 85 dd= 8 locks held 1 write locks 0 pid/thread >> 1863/140490452199168 flags 10 priority 100 >> 85 READ 1 HELD ipaca/requeststate.db handle 0 >> 86 dd= 7 locks held 1 write locks 0 pid/thread >> 1863/140490452199168 flags 10 priority 100 >> 86 READ 1 HELD ipaca/requesttype.db handle 0 >> 87 dd= 4 locks held 1 write locks 0 pid/thread >> 1863/140490418628352 flags 10 priority 100 >> 87 READ 1 HELD userRoot/memberOf.db handle 0 >> 88 dd= 3 locks held 0 write locks 0 pid/thread >> 1863/140490822526720 flags 0 priority 100 >> 88 READ 1 WAIT changelog/objectclass.db >> page 1 >> 89 dd= 2 locks held 0 write locks 0 pid/thread >> 1863/140490805741312 flags 0 priority 100 >> 89 READ 1 WAIT changelog/objectclass.db >> page 1 >> 8a dd= 1 locks held 0 write locks 0 pid/thread >> 1863/140490839312128 flags 0 priority 100 >> 8b dd= 0 locks held 0 write locks 0 pid/thread >> 1863/140490814134016 flags 0 priority 100 >> 8b READ 1 WAIT changelog/objectclass.db >> page 1 >> 800000f6 dd= 6 locks held 108 write locks 57 pid/thread >> 1863/140490418628352 flags 0 priority 100 >> 800000f6 READ 4 HELD userRoot/member.db page 356 >> 800000f6 READ 4 HELD userRoot/member.db page 360 >> 800000f6 READ 2 HELD userRoot/member.db page 403 >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 >> 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 >> 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 >> 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 >> 800000f6 READ 4 HELD userRoot/member.db page 405 >> 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 >> 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 >> 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 >> 800000f6 READ 3 HELD userRoot/memberHost.db page 96 >> 800000f6 READ 10 HELD userRoot/memberUser.db page 166 >> 800000f6 READ 15 HELD userRoot/member.db page 70 >> 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 >> 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 >> 800000f6 READ 3 HELD userRoot/memberHost.db page 209 >> 800000f6 READ 6 HELD userRoot/memberUser.db page 14 >> 800000f6 READ 3 HELD userRoot/member.db page 26 >> 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 >> 800000f6 READ 5 HELD userRoot/memberHost.db page 87 >> 800000f6 READ 10 HELD userRoot/member.db page 50 >> 800000f6 READ 1 HELD userRoot/memberHost.db page 28 >> 800000f6 READ 1 HELD userRoot/memberUser.db page 92 >> 800000f6 READ 1 HELD userRoot/member.db page 43 >> 800000f6 READ 2 HELD userRoot/memberUser.db page 103 >> 800000f6 READ 2 HELD userRoot/member.db page 337 >> 800000f6 READ 2 HELD userRoot/memberallowcmd.db >> page 44 >> 800000f6 READ 2 HELD userRoot/memberdenycmd.db >> page 1 >> 800000f6 READ 2 HELD userRoot/ipasudorunas.db >> page 1 >> 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db >> page 1 >> 800000f6 READ 2 HELD userRoot/objectclass.db page 10 >> 800000f6 READ 15 HELD userRoot/member.db page 406 >> 800000f6 READ 61 HELD userRoot/objectclass.db page 61 >> 800000f6 READ 36 HELD userRoot/memberUser.db page 81 >> 800000f6 READ 35 HELD userRoot/memberHost.db page 195 >> 800000f6 READ 2 HELD userRoot/objectclass.db page 50 >> 800000f6 READ 1 HELD changelog/nsuniqueid.db page 191 >> 800000f6 READ 3 HELD changelog/entryrdn.db page 387 >> 800000f6 READ 2 HELD changelog/entryrdn.db page 388 >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 >> 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 >> 800000f6 WRITE 3 HELD changelog/objectclass.db >> page 1 >> 800000f6 WRITE 1 HELD changelog/targetuniqueid.db >> page 47 >> 800000f6 WRITE 1 HELD changelog/changenumber.db >> page 68 >> 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page 191 >> 800000f6 WRITE 1 HELD changelog/parentid.db page 1 >> 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 >> 800000f6 WRITE 1 HELD changelog/ancestorid.db page 1 >> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 >> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 >> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 >> 800000f6 WRITE 1 HELD changelog/numsubordinates.db >> page 1 >> 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 >> 800000f6 READ 1 HELD userRoot/entryusn.db page 27 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 >> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 >> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 >> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 >> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 >> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 >> 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 >> 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 >> 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 >> 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 >> 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 >> 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 >> 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 >> 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 >> 80000106 dd= 5 locks held 17 write locks 13 pid/thread >> 1863/140490410235648 flags 0 priority 100 >> 80000106 WRITE 2 HELD ipaca/vlv#caenrollmentpkitomcatindex.db >> page 1 >> 80000106 WRITE 4 HELD ipaca/vlv#caenrollmentpkitomcatindex.db >> page 5 >> 80000106 WRITE 2 HELD >> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 >> 80000106 WRITE 4 HELD >> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 >> 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db >> page 1 >> 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db >> page 5 >> 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db >> page 1 >> 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db >> page 5 >> 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 >> 80000106 READ 1 HELD ipaca/entryusn.db page 13 >> 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 >> 80000106 READ 1 HELD ipaca/requesttype.db page 1 >> 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 >> 80000106 READ 1 HELD ipaca/requeststate.db page 1 >> 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 >> 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 >> 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 >> 800001eb dd=4294967295 locks held 75 write locks 39 pid/thread >> 1863/140490418628352 flags 0 priority 100 >> 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 >> 800001eb READ 1 HELD userRoot/entryusn.db page 27 >> 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 >> 800001eb READ 1 HELD userRoot/memberOf.db page 219 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 >> 800001eb READ 1 HELD userRoot/memberOf.db page 259 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 >> 800001eb READ 1 HELD userRoot/memberOf.db page 253 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 >> 800001eb READ 1 HELD userRoot/memberOf.db page 207 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 >> 800001eb READ 1 HELD userRoot/memberOf.db page 91 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 >> 800001eb READ 1 HELD userRoot/memberOf.db page 10 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 >> 800001eb READ 1 HELD userRoot/memberOf.db page 211 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 >> 800001eb READ 1 HELD userRoot/memberOf.db page 143 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 >> 800001eb READ 1 HELD userRoot/memberOf.db page 121 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 >> 800001eb READ 1 HELD userRoot/memberOf.db page 228 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 >> 800001eb READ 1 HELD userRoot/memberOf.db page 78 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 >> 800001eb READ 1 HELD userRoot/memberOf.db page 272 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 >> 800001eb READ 1 HELD userRoot/memberOf.db page 189 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 >> 800001eb READ 1 HELD userRoot/memberOf.db page 156 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 >> 800001eb READ 1 HELD userRoot/memberOf.db page 148 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 >> 800001eb READ 1 HELD userRoot/memberOf.db page 142 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 >> 800001eb READ 1 HELD userRoot/memberOf.db page 258 >> 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 >> 800001eb READ 3 HELD userRoot/memberOf.db page 260 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 >> 800001eb READ 1 HELD userRoot/memberOf.db page 218 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 >> 800001eb READ 1 HELD userRoot/memberOf.db page 106 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 >> 800001eb READ 1 HELD userRoot/memberOf.db page 141 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 >> 800001eb READ 1 HELD userRoot/memberOf.db page 120 >> 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 >> 800001eb READ 2 HELD userRoot/memberOf.db page 126 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 >> 800001eb READ 1 HELD userRoot/memberOf.db page 97 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 >> 800001eb READ 1 HELD userRoot/memberOf.db page 196 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 >> 800001eb READ 1 HELD userRoot/memberOf.db page 240 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 >> 800001eb READ 1 HELD userRoot/memberOf.db page 73 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 >> 800001eb READ 1 HELD userRoot/memberOf.db page 42 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 >> 800001eb READ 1 HELD userRoot/memberOf.db page 251 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 >> 800001eb READ 1 HELD userRoot/memberOf.db page 75 >> 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 >> 800001eb READ 2 HELD userRoot/memberOf.db page 271 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 >> 800001eb READ 1 HELD userRoot/memberOf.db page 262 >> 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 >> 800001eb READ 3 HELD userRoot/memberOf.db page 255 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 >> 800001eb READ 1 HELD userRoot/memberOf.db page 245 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 >> 800001eb READ 1 HELD userRoot/memberOf.db page 19 >> 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 >> 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Locks grouped by object: >> Locker Mode Count Status ----------------- Object >> --------------- >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 >> >> 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 >> >> 2d READ 1 HELD changelog/entryusn.db handle 0 >> >> 39 READ 1 HELD userRoot/ancestorid.db handle 0 >> >> 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 >> >> 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db >> handle 0 >> >> 44 READ 1 HELD changelog/entryrdn.db handle 0 >> >> 800000f6 READ 1 HELD changelog/nsuniqueid.db page 191 >> 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page 191 >> >> 63 READ 1 HELD changelog/nsuniqueid.db >> handle 0 >> >> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 >> >> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 >> >> 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 >> >> 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 >> >> 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db >> handle 0 >> >> d READ 1 HELD >> ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 >> >> 75 READ 1 HELD userRoot/memberUser.db handle 0 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 >> >> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 >> >> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 >> >> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 >> >> 800000f6 READ 6 HELD userRoot/memberUser.db page 14 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 >> >> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 >> >> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 >> >> 800000f6 READ 36 HELD userRoot/memberUser.db page 81 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 >> >> 800000f6 READ 1 HELD userRoot/memberUser.db page 92 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 >> 800000f6 READ 2 HELD userRoot/memberUser.db page 103 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 >> >> 800000f6 READ 10 HELD userRoot/memberUser.db page 166 >> >> 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 >> >> 68 READ 1 HELD changelog/parentid.db handle 0 >> >> 800000f6 WRITE 1 HELD changelog/parentid.db page 1 >> >> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 >> >> 14 READ 1 HELD >> ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 >> >> 50 READ 1 HELD userRoot/aci.db handle 0 >> >> 7f READ 1 HELD userRoot/ipaassignedidview.db >> handle 0 >> >> 72 READ 1 HELD userRoot/seeAlso.db handle 0 >> >> 70 READ 1 HELD userRoot/uniquemember.db >> handle 0 >> >> 800000f6 READ 15 HELD userRoot/member.db page 406 >> >> 800000f6 READ 4 HELD userRoot/member.db page 405 >> >> 800000f6 READ 2 HELD userRoot/member.db page 403 >> >> 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 >> >> 16 READ 1 HELD >> ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 >> >> 52 READ 1 HELD ipaca/aci.db handle 0 >> >> 800000f6 READ 2 HELD userRoot/member.db page 337 >> >> 800000f6 READ 4 HELD userRoot/member.db page 360 >> >> 800000f6 READ 4 HELD userRoot/member.db page 356 >> >> 73 READ 1 HELD userRoot/manager.db handle 0 >> >> 7c READ 1 HELD userRoot/ipasudorunas.db >> handle 0 >> >> 800000f6 READ 2 HELD userRoot/ipasudorunas.db >> page 1 >> >> 7d READ 1 HELD userRoot/ipasudorunasgroup.db >> handle 0 >> >> 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db >> page 1 >> >> 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 >> >> 800000f6 READ 3 HELD userRoot/member.db page 26 >> >> 6f READ 1 HELD userRoot/member.db handle 0 >> >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 >> >> 800000f6 READ 10 HELD userRoot/member.db page 50 >> >> 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 >> >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 >> >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 >> >> 800000f6 READ 1 HELD userRoot/member.db page 43 >> >> 800000f6 READ 15 HELD userRoot/member.db page 70 >> >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 272 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 259 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 258 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 >> >> 800001eb READ 3 HELD userRoot/memberOf.db page 260 >> 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 262 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 >> >> 800001eb READ 2 HELD userRoot/memberOf.db page 271 >> 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 >> >> 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 >> >> 26 READ 1 HELD >> ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 >> >> 1f READ 1 HELD >> ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 19 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 >> >> 87 READ 1 HELD userRoot/memberOf.db handle 0 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 10 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 >> >> 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 42 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 91 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 73 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 75 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 78 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 121 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 120 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 >> >> 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 >> >> 1 READ 1 HELD userRoot/id2entry.db handle 0 >> >> 800001eb READ 2 HELD userRoot/memberOf.db page 126 >> 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 97 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 106 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 148 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 156 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 141 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 143 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 142 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 189 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 211 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 219 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 218 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 196 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 >> >> f READ 1 HELD >> ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 207 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 240 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 245 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 >> >> 78 READ 1 HELD userRoot/memberservice.db >> handle 0 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 251 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 253 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 >> >> 800001eb READ 3 HELD userRoot/memberOf.db page 255 >> 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 >> >> 800001eb READ 1 HELD userRoot/memberOf.db page 228 >> 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 >> >> 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db >> page 1 >> >> 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db >> handle 0 >> >> 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db >> page 5 >> >> 13 READ 1 HELD >> ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db >> handle 0 >> >> 2a READ 1 HELD >> ipaca/vlv#carevocationpkitomcatindex.db handle 0 >> >> 74 READ 1 HELD userRoot/secretary.db handle 0 >> >> 5 READ 1 HELD ipaca/entryrdn.db handle 0 >> >> 85 READ 1 HELD ipaca/requeststate.db handle 0 >> >> 80000106 READ 1 HELD ipaca/requeststate.db page 1 >> 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 >> >> 3b READ 1 HELD userRoot/macAddress.db handle 0 >> >> 6e READ 1 HELD userRoot/numsubordinates.db >> handle 0 >> >> 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db >> page 1 >> >> 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db >> handle 0 >> >> 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db >> page 5 >> >> 10 READ 1 HELD >> ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 >> >> 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 >> 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 >> 2 READ 1 WAIT userRoot/id2entry.db page 2495 >> >> 800000f6 READ 2 HELD userRoot/memberdenycmd.db >> page 1 >> >> 7b READ 1 HELD userRoot/memberdenycmd.db >> handle 0 >> >> 5e READ 1 HELD >> /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db >> handle 0 >> >> 4e READ 1 HELD changelog/aci.db handle 0 >> >> 67 READ 1 HELD changelog/targetuniqueid.db >> handle 0 >> >> 800000f6 WRITE 1 HELD changelog/targetuniqueid.db >> page 47 >> >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 >> >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 >> >> 2b READ 1 HELD changelog/id2entry.db handle 0 >> >> 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db >> handle 0 >> >> 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 >> >> 2f READ 1 HELD userRoot/entryusn.db handle 0 >> >> 31 READ 1 HELD ipaca/entryusn.db handle 0 >> >> 80000106 READ 1 HELD ipaca/entryusn.db page 13 >> 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 >> >> 800000f6 READ 1 HELD userRoot/entryusn.db page 27 >> 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 >> 800001eb READ 1 HELD userRoot/entryusn.db page 27 >> 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 >> >> 800000f6 WRITE 1 HELD changelog/changenumber.db >> page 68 >> 65 READ 1 WAIT changelog/changenumber.db >> page 68 >> >> 64 READ 1 HELD changelog/changenumber.db >> handle 0 >> >> 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 >> >> 82 READ 1 HELD userRoot/krbPrincipalName.db >> handle 0 >> >> 800000f6 READ 2 HELD userRoot/memberallowcmd.db >> page 44 >> >> 33 READ 1 HELD userRoot/entryrdn.db handle 0 >> >> 80000106 READ 1 HELD ipaca/requesttype.db page 1 >> 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 >> >> 86 READ 1 HELD ipaca/requesttype.db handle 0 >> >> 7a READ 1 HELD userRoot/memberallowcmd.db >> handle 0 >> >> 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 >> >> 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 >> >> 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 >> >> 37 READ 1 HELD userRoot/objectclass.db >> handle 0 >> >> 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 >> >> 800000f6 READ 2 HELD userRoot/objectclass.db page 10 >> >> 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 >> >> 77 READ 1 HELD userRoot/sourcehost.db handle 0 >> >> 800000f6 READ 2 HELD userRoot/objectclass.db page 50 >> >> 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 >> >> 48 READ 1 HELD changelog/objectclass.db >> handle 0 >> >> 800000f6 WRITE 3 HELD changelog/objectclass.db >> page 1 >> 6b READ 1 WAIT changelog/objectclass.db >> page 1 >> 49 READ 1 WAIT changelog/objectclass.db >> page 1 >> 88 READ 1 WAIT changelog/objectclass.db >> page 1 >> 89 READ 1 WAIT changelog/objectclass.db >> page 1 >> 8b READ 1 WAIT changelog/objectclass.db >> page 1 >> >> 800000f6 READ 61 HELD userRoot/objectclass.db page 61 >> >> 80000106 WRITE 4 HELD ipaca/vlv#caenrollmentpkitomcatindex.db >> page 5 >> >> 20 READ 1 HELD >> ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 >> >> 80000106 WRITE 2 HELD ipaca/vlv#caenrollmentpkitomcatindex.db >> page 1 >> >> 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 >> >> 6a READ 1 HELD changelog/numsubordinates.db >> handle 0 >> >> 800000f6 WRITE 1 HELD changelog/numsubordinates.db >> page 1 >> >> 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 >> >> 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 >> >> 54 READ 1 HELD userRoot/parentid.db handle 0 >> >> 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 >> >> 800000f6 WRITE 1 HELD changelog/ancestorid.db page 1 >> >> 69 READ 1 HELD changelog/ancestorid.db >> handle 0 >> >> 4b READ 1 HELD ipaca/objectclass.db handle 0 >> >> 57 READ 1 HELD userRoot/nsuniqueid.db handle 0 >> >> 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 >> >> 5b READ 1 HELD >> /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db >> handle 0 >> >> 6d READ 1 HELD userRoot/nscpEntryDN.db >> handle 0 >> >> 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 >> >> 3 READ 1 HELD ipaca/id2entry.db handle 0 >> >> 6c READ 1 HELD userRoot/nsTombstoneCSN.db >> handle 0 >> >> 800000f6 READ 5 HELD userRoot/memberHost.db page 87 >> >> 800000f6 READ 3 HELD userRoot/memberHost.db page 96 >> >> 800000f6 READ 1 HELD userRoot/memberHost.db page 28 >> >> 76 READ 1 HELD userRoot/memberHost.db handle 0 >> >> 71 READ 1 HELD userRoot/owner.db handle 0 >> >> 800000f6 READ 3 HELD userRoot/memberHost.db page 209 >> >> 800000f6 READ 35 HELD userRoot/memberHost.db page 195 >> >> 15 READ 1 HELD >> ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 >> >> 80000106 WRITE 4 HELD >> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 >> >> 1d READ 1 HELD >> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 >> >> 80000106 WRITE 2 HELD >> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 >> >> 79 READ 1 HELD userRoot/managedby.db handle 0 >> >> 800000f6 READ 3 HELD changelog/entryrdn.db page 387 >> >> 800000f6 READ 2 HELD changelog/entryrdn.db page 388 >> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 >> >> 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 >> >> >> Lukasz Jaworski 'Ender' >> >> >> Wiadomo?? napisana przez thierry bordaz w dniu 6 >> maj 2015, o godz. 11:47: >> >>> This is looking like thread 13 prevents thread 12 run (and all the >>> others). >>> Now thread 13 is likely waiting for db page? We may need output of >>> db_stat (db_state -N -h /var/lib/dirsrv/slapd-xxx/db/ -CA) >>> >>> thanks >>> thierry >>> On 05/06/2015 11:31 AM, ?ukasz Jaworski wrote: >>>>>> ldapsearch hangs. Dirsrv is not responding now. >>>>> if the server is hanging, can you get a pstack >>>> Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): >>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #2 0x00007fc6a961f987 in deadlock_threadmain () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): >>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #2 0x00007fc6a9623a4e in checkpoint_threadmain () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): >>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #2 0x00007fc6a961fc0f in trickle_threadmain () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): >>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #2 0x00007fc6a961a667 in perf_threadmain () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #3 0x00007fc6abd455be in cos_cache_wait_on_change () from >>>> /usr/lib64/dirsrv/plugins/libcos-plugin.so >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): >>>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () >>>> from /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #3 0x00007fc6a937be84 in _cl5TrimMain () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6a93928d4 in protocol_sleep () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #3 0x00007fc6a93949e5 in repl5_inc_run () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #4 0x00007fc6a9399421 in prot_thread_main () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #5 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #6 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #7 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): >>>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () >>>> from /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #3 0x00007fc6a93928d4 in protocol_sleep () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #4 0x00007fc6a9395158 in repl5_inc_run () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #5 0x00007fc6a9399421 in prot_thread_main () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #6 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #7 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #8 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from >>>> /usr/lib64/dirsrv/plugins/libroles-plugin.so >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 36 (Thread 0x7fc6a1203700 (LWP 1907)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from >>>> /usr/lib64/dirsrv/plugins/libroles-plugin.so >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 35 (Thread 0x7fc6a0a02700 (LWP 1908)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from >>>> /usr/lib64/dirsrv/plugins/libroles-plugin.so >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 34 (Thread 0x7fc693fff700 (LWP 1909)): >>>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () >>>> from /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #3 0x00007fc6b593a773 in housecleaning () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 33 (Thread 0x7fc6937fe700 (LWP 1910)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #6 0x00007fc6a939f76f in replica_write_ruv () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #7 0x00007fc6a939f9fe in replica_update_state () from >>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>> #8 0x00007fc6b542965a in eq_loop () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #9 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #10 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #11 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 32 (Thread 0x7fc692924700 (LWP 1912)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 31 (Thread 0x7fc692123700 (LWP 1913)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 30 (Thread 0x7fc691922700 (LWP 1914)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>> /lib64/libdb-5.3.so >>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>> /lib64/libdb-5.3.so >>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>> /lib64/libdb-5.3.so >>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #14 0x00007fc6a96272ed in keys2idl () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #17 0x00007fc6a96290ce in list_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #22 0x00007fc6b5943fc6 in do_search () >>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 29 (Thread 0x7fc691121700 (LWP 1915)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>> /lib64/libdb-5.3.so >>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>> /lib64/libdb-5.3.so >>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>> /lib64/libdb-5.3.so >>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #14 0x00007fc6a96272ed in keys2idl () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #17 0x00007fc6a96290ce in list_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #22 0x00007fc6b5943fc6 in do_search () >>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 28 (Thread 0x7fc690920700 (LWP 1916)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>> /lib64/libdb-5.3.so >>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>> /lib64/libdb-5.3.so >>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>> /lib64/libdb-5.3.so >>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #14 0x00007fc6a96272ed in keys2idl () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #17 0x00007fc6a96290ce in list_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #22 0x00007fc6b5943fc6 in do_search () >>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 27 (Thread 0x7fc67ffff700 (LWP 1917)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>> /lib64/libdb-5.3.so >>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>> /lib64/libdb-5.3.so >>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>> /lib64/libdb-5.3.so >>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >>>> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>> #8 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>> #10 0x00007fc6add50ced in __db_get () from /lib64/libdb-5.3.so >>>> #11 0x00007fc6add5473b in __db_get_pp () from /lib64/libdb-5.3.so >>>> #12 0x00007fc6a962a9bb in id2entry () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #13 0x00007fc6a9626cbd in dn2entry_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #14 0x00007fc6a9629bb1 in find_entry_internal.isra () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #15 0x00007fc6a9629e99 in find_entry () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #16 0x00007fc6a9663b5b in ldbm_back_search () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #17 0x00007fc6b5455410 in op_shared_search () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #18 0x00007fc6b546553e in search_internal_callback_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #19 0x00007fc6b54657c8 in search_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #20 0x00007fc6b5465b73 in slapi_search_internal_get_entry () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #21 0x00007fc6aad02234 in ipalockout_preop () from >>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>> #22 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #23 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #24 0x00007fc6b592c3d8 in do_bind () >>>> #25 0x00007fc6b5932974 in connection_threadmain () >>>> #26 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #27 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #28 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 25 (Thread 0x7fc67effd700 (LWP 1919)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 24 (Thread 0x7fc67e7fc700 (LWP 1920)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 23 (Thread 0x7fc67dffb700 (LWP 1921)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 22 (Thread 0x7fc67d7fa700 (LWP 1922)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #9 0x00007fc6b592c22d in do_bind () >>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 21 (Thread 0x7fc67cff9700 (LWP 1923)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #9 0x00007fc6b592c22d in do_bind () >>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 20 (Thread 0x7fc67c7f8700 (LWP 1924)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 19 (Thread 0x7fc67bff7700 (LWP 1925)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #9 0x00007fc6b592c22d in do_bind () >>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 18 (Thread 0x7fc67b7f6700 (LWP 1926)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 17 (Thread 0x7fc67aff5700 (LWP 1927)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 16 (Thread 0x7fc67a7f4700 (LWP 1928)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 15 (Thread 0x7fc679ff3700 (LWP 1929)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): >>>> #0 0x00007fc6b31eff1d in __lll_lock_wait () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b31ea9be in pthread_mutex_lock () from >>>> /lib64/libpthread.so.0 >>>> #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so >>>> #3 0x00007fc6a7ec99b0 in retrocl_postob () from >>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>> #4 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #5 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #6 0x00007fc6a965d231 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #7 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #8 0x00007fc6b544f387 in modify_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from >>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>> #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from >>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>> #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from >>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>> #12 0x00007fc6a8d3758d in memberof_postop_modify () from >>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>> #13 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #14 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #15 0x00007fc6a965d231 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #16 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #17 0x00007fc6b544fbe7 in do_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #18 0x00007fc6b5932925 in connection_threadmain () >>>> #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>> /lib64/libdb-5.3.so >>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>> /lib64/libdb-5.3.so >>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>> /lib64/libdb-5.3.so >>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >>>> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>> #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so >>>> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>> #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>> #11 0x00007fc6a9672b70 in ldbm_back_seq () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #13 0x00007fc6b54652a9 in slapi_seq_callback () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from >>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>> #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from >>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>> #16 0x00007fc6a7ec99b5 in retrocl_postob () from >>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>> #17 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #18 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #19 0x00007fc6a965d231 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #20 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #21 0x00007fc6b544fbe7 in do_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #22 0x00007fc6b5932925 in connection_threadmain () >>>> #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 12 (Thread 0x7fc6787f0700 (LWP 1932)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 11 (Thread 0x7fc677fef700 (LWP 1933)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 10 (Thread 0x7fc6777ee700 (LWP 1934)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #9 0x00007fc6b592c22d in do_bind () >>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 9 (Thread 0x7fc676fed700 (LWP 1935)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #9 0x00007fc6b592c22d in do_bind () >>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 8 (Thread 0x7fc6767ec700 (LWP 1936)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>> /lib64/libdb-5.3.so >>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>> /lib64/libdb-5.3.so >>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>> /lib64/libdb-5.3.so >>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #14 0x00007fc6a96272ed in keys2idl () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #17 0x00007fc6a96290ce in list_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #22 0x00007fc6b5943fc6 in do_search () >>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 6 (Thread 0x7fc6757ea700 (LWP 1938)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 5 (Thread 0x7fc674fe9700 (LWP 1939)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>> /lib64/libdb-5.3.so >>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>> /lib64/libdb-5.3.so >>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>> /lib64/libdb-5.3.so >>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #14 0x00007fc6a96272ed in keys2idl () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #17 0x00007fc6a96290ce in list_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #22 0x00007fc6b5943fc6 in do_search () >>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 3 (Thread 0x7fc673fe7700 (LWP 1941)): >>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 2 (Thread 0x7fc6737e6700 (LWP 1942)): >>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>> /usr/lib64/dirsrv/libslapd.so.0 >>>> #2 0x00007fc6b5933855 in time_thread () >>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>> Thread 1 (Thread 0x7fc6b58fb800 (LWP 1863)): >>>> #0 0x00007fc6b2f18c8d in poll () from /lib64/libc.so.6 >>>> #1 0x00007fc6b3843da8 in _pr_poll_with_poll () from >>>> /lib64/libnspr4.so >>>> #2 0x00007fc6b5936b11 in slapd_daemon () >>>> #3 0x00007fc6b59294f4 in main () >>>> >>>> >>>>>> This replica is on virtual machine (ganeti). We had problems with >>>>>> replication to vm, but after force-sync all was fine. On physical >>>>>> servers all works fine. >>>>> the messages indicate there could be many concurrent operations, >>>>> because individual ops are not fast enough, could your VM have >>>>> less/slower resources than the physical machines ? >>>> VMs have less rsources and slower than physical machines. >>>> VM: 4 cpu, hd via drbd on sas drives, >>>> >>>> physical: more cores, faster (ssd) drives >>>> >>>> Best regards, >>>> Lukasz Jaworski 'Ender' >>>> >>>> >>>> >>>>>> Lukasz Jaworski 'Ender' >>>>>> >>>>>> Wiadomo?? napisana przez Ludwig Krispenz w >>>>>> dniu 6 maj 2015, o godz. 10:52: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> there seem to be different issues, >>>>>>> - I don't know what the ipactl status is looking for when it >>>>>>> generates the error message about no matching master, >>>>>>> but I don't think it is related to the retro changelog. >>>>>>> >>>>>>> - the retro changelog errors for adding and deleting >>>>>>> -- the add failures are about aborted transactions because a >>>>>>> page cannot be accessed, this maybe caused by concurrent mods on >>>>>>> different backends, which want to update teh shared retro cl >>>>>>> database. >>>>>>> the changenumber reprted seems to be increasing, one error is >>>>>>> about changenumber 44975, the next about 45577, so it looks like >>>>>>> changes into the changelog are written and teh changenumber >>>>>>> increases >>>>>>> -- i'm not sure about the delete errors, but normally trimming >>>>>>> would go on after such an error message, the changenumber >>>>>>> attempted to delete are increasing. >>>>>>> Could you verify which changes are in the changelog, and if >>>>>>> these are changing: >>>>>>> ldapsearch -b "cn=changelog" dn >>>>>>> >>>>>>> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> One of our replica hanged up morning. Error log after dirsrv >>>>>>>> restart: >>>>>>>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>>>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 38376 (rc: 51) >>>>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN >>>>>>>> (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>>>>>>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id >>>>>>>> for changenumber=44975,cn=changelog from entryrdn index (-30993) >>>>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching >>>>>>>> changenumber=44975,cn=changelog (null), error -30993. >>>>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error >>>>>>>> occured while adding change number 44975, dn = >>>>>>>> changenumber=44975,cn=changelog: Operations error. >>>>>>>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: >>>>>>>> operation failure [1] >>>>>>>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD >>>>>>>> 1601, err=0 BDB0062 Successful return: 0 >>>>>>>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD >>>>>>>> 1601, err=0 BDB0062 Successful return: 0 >>>>>>>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>>>>>>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39297 (rc: 51) >>>>>>>> >>>>>>>> I did "re-initialize" from other replica. >>>>>>>> >>>>>>>> Now ipactl doesn't work. Shows: Configured hostname >>>>>>>> 'replica09.local' does not match any master server in LDAP. On >>>>>>>> lists replica09 is exists (twice) >>>>>>>> >>>>>>>> # ipactl status >>>>>>>> Failed to get list of services to probe status! >>>>>>>> Configured hostname 'replica09.local' does not match any master >>>>>>>> server in LDAP: >>>>>>>> replica01.local >>>>>>>> replica02.local >>>>>>>> replica03.local >>>>>>>> replica04.local >>>>>>>> replica05.local >>>>>>>> replica06.local >>>>>>>> replica07.local >>>>>>>> replica08.local >>>>>>>> replica09.local >>>>>>>> replica10.local >>>>>>>> replica09.local >>>>>>>> >>>>>>>> After dirsrv stop/start: >>>>>>>> >>>>>>>> In error logs there are many: >>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39290 (rc: 32) >>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39291 (rc: 32) >>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39292 (rc: 32) >>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39293 (rc: 32) >>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39294 (rc: 32) >>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39295 (rc: 32) >>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>> delete_changerecord: could not delete change record 39296 (rc: 32) >>>>>>>> etc. >>>>>>>> >>>>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN >>>>>>>> (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>>>>>>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id >>>>>>>> for changenumber=45577,cn=changelog from entryrdn index (-30993) >>>>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching >>>>>>>> changenumber=45577,cn=changelog (null), error -30993. >>>>>>>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error >>>>>>>> occured while adding change number 45577, dn = >>>>>>>> changenumber=45577,cn=changelog: Operations error. >>>>>>>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: >>>>>>>> operation failure [1] >>>>>>>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD >>>>>>>> 1601, err=0 BDB0062 Successful return: 0 >>>>>>>> >>>>>>>> Packages: >>>>>>>> freeipa-server-4.1.3-2.fc21.x86_64 >>>>>>>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>>>>>>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Ender >>>>>>>> >>>>>>> -- >>>>>>> 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 > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From rmeggins at redhat.com Thu May 7 00:13:24 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 06 May 2015 18:13:24 -0600 Subject: [Freeipa-users] Problem with replication In-Reply-To: <554AAC36.5050409@redhat.com> References: <4EF2ED88-FC86-4021-AFDE-D86821695D8B@kofeina.net> <5549D645.3090001@redhat.com> <5549DE08.1090502@redhat.com> <5549E31F.4040809@redhat.com> <5549FAFF.1080905@redhat.com> <554AAC36.5050409@redhat.com> Message-ID: <554AAE24.2080406@redhat.com> On 05/06/2015 06:05 PM, Dmitri Pal wrote: > On 05/06/2015 07:29 AM, thierry bordaz wrote: >> This is looking like a deadlock between thread 14 and thread 13 where >> both threads acquired lock in the opposite order. >> Thread 14 is processing a betxn_postop but thread 13 is doing a >> postop. I wonder if the problem is that the test/set of the >> changenumber is done outside of the backend lock. > > > Is this enough info to open a ticket? Yes https://fedorahosted.org/389/ticket/48181 > >> >> >> Thread 14 holds some db page locks and tries to acquire retrocl >> plugin lock (retrocl_internal_lock) >> 800000f6 dd= 6 locks held 108 write locks 57 pid/thread >> 1863/140490418628352 flags 0 priority 100 >> 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 >> 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 >> 800000f6 WRITE 3 HELD changelog/objectclass.db >> page 1 >> 800000f6 WRITE 1 HELD changelog/changenumber.db >> page 68 >> >> Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): >> #0 0x00007fc6b31eff1d in __lll_lock_wait () from /lib64/libpthread.so.0 >> #1 0x00007fc6b31ea9be in pthread_mutex_lock () from >> /lib64/libpthread.so.0 >> #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so >> #3 0x00007fc6a7ec99b0 in retrocl_postob () from >> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #4 0x00007fc6b546156f in plugin_call_func () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #5 0x00007fc6b5461893 in plugin_call_plugins () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #6 0x00007fc6a965d231 in ldbm_back_modify () from >> /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #7 0x00007fc6b544e905 in op_shared_modify () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #8 0x00007fc6b544f387 in modify_internal_pb () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from >> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from >> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from >> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #12 0x00007fc6a8d3758d in memberof_postop_modify () from >> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >> #13 0x00007fc6b546156f in plugin_call_func () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #14 0x00007fc6b5461893 in plugin_call_plugins () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #15 0x00007fc6a965d231 in ldbm_back_modify () from >> /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #16 0x00007fc6b544e905 in op_shared_modify () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #17 0x00007fc6b544fbe7 in do_modify () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #18 0x00007fc6b5932925 in connection_threadmain () >> #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> >> While thread 13 which hold the retrocl plugin lock, tries to acquire >> a page lock (held by thread 14) >> >> Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): >> 65 READ 1 WAIT changelog/changenumber.db page 68 >> >> Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): >> #0 0x00007fc6b31ed590 inpthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >> /lib64/libdb-5.3.so >> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >> /lib64/libdb-5.3.so >> #3 0x00007fc6add2aa91 in __lock_get_internal () from >> /lib64/libdb-5.3.so >> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >> #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so >> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >> #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >> #11 0x00007fc6a9672b70 in ldbm_back_seq () from >> /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #13 0x00007fc6b54652a9 in slapi_seq_callback () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from >> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from >> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #16 0x00007fc6a7ec99b5 in retrocl_postob () from >> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >> #17 0x00007fc6b546156f in plugin_call_func () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #18 0x00007fc6b5461893 in plugin_call_plugins () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #19 0x00007fc6a965d231 in ldbm_back_modify () from >> /usr/lib64/dirsrv/plugins/libback-ldbm.so >> #20 0x00007fc6b544e905 in op_shared_modify () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #21 0x00007fc6b544fbe7 in do_modify () from >> /usr/lib64/dirsrv/libslapd.so.0 >> #22 0x00007fc6b5932925 in connection_threadmain () >> #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >> #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >> #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >> >> Many others threads are waiting for others pages held by thread 14: >> >> >> Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): >> Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): >> Thread 30 (Thread 0x7fc691922700 (LWP 1914)): >> Thread 28 (Thread 0x7fc690920700 (LWP 1916)): >> Thread 29 (Thread 0x7fc691121700 (LWP 1915)): >> 49 READ 1 WAIT changelog/objectclass.db page 1 >> >> Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): >> 65 READ 1 WAIT changelog/changenumber.db page 68 >> >> Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): >> 2 READ 1 WAIT userRoot/id2entry.db page 2495 >> >> >> >> On 05/06/2015 12:01 PM, ?ukasz Jaworski wrote: >>> dbstat: >>> >>> MacBookPro-10DDB1EAF1CC-1522:~ ender$ cat FILE >>> Default locking region information: >>> 139 Last allocated locker ID >>> 0x7fffffff Current maximum unused locker ID >>> 9 Number of lock modes >>> 200 Initial number of locks allocated >>> 0 Initial number of lockers allocated >>> 200 Initial number of lock objects allocated >>> 10000 Maximum number of locks possible >>> 10000 Maximum number of lockers possible >>> 10000 Maximum number of lock objects possible >>> 312 Current number of locks allocated >>> 151 Current number of lockers allocated >>> 250 Current number of lock objects allocated >>> 40 Number of lock object partitions >>> 8191 Size of object hash table >>> 275 Number of current locks >>> 303 Maximum number of locks at any one time >>> 6 Maximum number of locks in any one bucket >>> 174 Maximum number of locks stolen by for an empty partition >>> 13 Maximum number of locks stolen for any one partition >>> 124 Number of current lockers >>> 124 Maximum number of lockers at any one time >>> 223 Number of current lock objects >>> 233 Maximum number of lock objects at any one time >>> 3 Maximum number of lock objects in any one bucket >>> 49 Maximum number of objects stolen by for an empty partition >>> 5 Maximum number of objects stolen for any one partition >>> 82905 Total number of locks requested >>> 82018 Total number of locks released >>> 0 Total number of locks upgraded >>> 68 Total number of locks downgraded >>> 8 Lock requests not available due to conflicts, for which we waited >>> 12 Lock requests not available due to conflicts, for which we did >>> not wait >>> 0 Number of deadlocks >>> 0 Lock timeout value >>> 0 Number of locks that have timed out >>> 0 Transaction timeout value >>> 0 Number of transactions that have timed out >>> 2MB 304KB Region size >>> 0 The number of partition locks that required waiting (0%) >>> 0 The maximum number of times any partition lock was waited for (0%) >>> 0 The number of object queue operations that required waiting (0%) >>> 0 The number of locker allocations that required waiting (0%) >>> 4 The number of region locks that required waiting (0%) >>> 5 Maximum hash bucket length >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Lock REGINFO information: >>> Environment Region type >>> 1 Region ID >>> /var/lib/dirsrv/slapd-xxxx/db/__db.001 Region name >>> 0x7fd376ff3000 Region address >>> 0x7fd376ff30a0 Region allocation head >>> 0x7fd376ffb2b0 Region primary address >>> 0 Region maximum allocation >>> 0 Region allocated >>> Region allocations: 796 allocations, 0 failures, 539 frees, 3 longest >>> Allocations by power-of-two sizes: >>> 1KB 781 >>> 2KB 3 >>> 4KB 6 >>> 8KB 3 >>> 16KB 0 >>> 32KB 1 >>> 64KB 0 >>> 128KB 0 >>> 256KB 2 >>> 512KB 0 >>> 1024KB 1 >>> REGION_SHARED Region flags >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Lock region parameters: >>> 2 Lock region region mutex [4/3168 0% !Own] >>> 16381 locker table size >>> 8191 object table size >>> 34128 obj_off >>> 889656 locker_off >>> 0 need_dd >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Lock conflict matrix: >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Locks grouped by lockers: >>> Locker Mode Count Status ----------------- Object >>> --------------- >>> 1 dd=122 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 1 READ 1 HELD userRoot/id2entry.db handle 0 >>> 2 dd=121 locks held 0 write locks 0 pid/thread >>> 1863/140490519340800 flags 0 priority 100 >>> 2 READ 1 WAIT userRoot/id2entry.db page 2495 >>> 3 dd=120 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 3 READ 1 HELD ipaca/id2entry.db handle 0 >>> 4 dd=119 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 5 dd=118 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 5 READ 1 HELD ipaca/entryrdn.db handle 0 >>> 6 dd=117 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 7 dd=116 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 8 dd=115 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 9 dd=114 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db >>> handle 0 >>> d dd=113 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> d READ 1 HELD >>> ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 >>> f dd=112 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> f READ 1 HELD >>> ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 >>> 10 dd=111 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 10 READ 1 HELD >>> ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 >>> 13 dd=110 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 13 READ 1 HELD >>> ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db >>> handle 0 >>> 14 dd=109 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 14 READ 1 HELD >>> ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 >>> 15 dd=108 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 15 READ 1 HELD >>> ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 >>> 16 dd=107 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 16 READ 1 HELD >>> ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 >>> 17 dd=106 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db >>> handle 0 >>> 1c dd=105 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db >>> handle 0 >>> 1d dd=104 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 1d READ 1 HELD >>> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 >>> 1f dd=103 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 1f READ 1 HELD >>> ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 >>> 20 dd=102 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 20 READ 1 HELD >>> ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 >>> 25 dd=101 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db >>> handle 0 >>> 26 dd=100 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 26 READ 1 HELD >>> ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 >>> 2a dd=99 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 2a READ 1 HELD >>> ipaca/vlv#carevocationpkitomcatindex.db handle 0 >>> 2b dd=98 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 2b READ 1 HELD changelog/id2entry.db handle 0 >>> 2c dd=97 locks held 0 write locks 0 pid/thread >>> 1863/140490468984576 flags 0 priority 100 >>> 2d dd=96 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 2d READ 1 HELD changelog/entryusn.db handle 0 >>> 2e dd=95 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 2f dd=94 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 2f READ 1 HELD userRoot/entryusn.db handle 0 >>> 30 dd=93 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 31 dd=92 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 31 READ 1 HELD ipaca/entryusn.db handle 0 >>> 32 dd=91 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 33 dd=90 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 33 READ 1 HELD userRoot/entryrdn.db handle 0 >>> 34 dd=89 locks held 0 write locks 0 pid/thread >>> 1863/140490839312128 flags 0 priority 100 >>> 35 dd=88 locks held 0 write locks 0 pid/thread >>> 1863/140490510948096 flags 0 priority 100 >>> 36 dd=87 locks held 0 write locks 0 pid/thread >>> 1863/140490519340800 flags 0 priority 100 >>> 37 dd=86 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 37 READ 1 HELD userRoot/objectclass.db >>> handle 0 >>> 38 dd=85 locks held 0 write locks 0 pid/thread >>> 1863/140490351486720 flags 0 priority 100 >>> 39 dd=84 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 39 READ 1 HELD userRoot/ancestorid.db >>> handle 0 >>> 3a dd=83 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 3b dd=82 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 3b READ 1 HELD userRoot/macAddress.db >>> handle 0 >>> 3c dd=81 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 3d dd=80 locks held 0 write locks 0 pid/thread >>> 1863/140490435413760 flags 0 priority 100 >>> 3e dd=79 locks held 0 write locks 0 pid/thread >>> 1863/140490343094016 flags 0 priority 100 >>> 3f dd=78 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 40 dd=77 locks held 0 write locks 0 pid/thread >>> 1863/140490839312128 flags 0 priority 100 >>> 41 dd=76 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 42 dd=75 locks held 0 write locks 0 pid/thread >>> 1863/140490510948096 flags 0 priority 100 >>> 43 dd=74 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 44 dd=73 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 44 READ 1 HELD changelog/entryrdn.db handle 0 >>> 45 dd=72 locks held 0 write locks 0 pid/thread >>> 1863/140490494162688 flags 0 priority 100 >>> 46 dd=71 locks held 0 write locks 0 pid/thread >>> 1863/140490468984576 flags 0 priority 100 >>> 47 dd=70 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 48 dd=69 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 48 READ 1 HELD changelog/objectclass.db >>> handle 0 >>> 49 dd=68 locks held 0 write locks 0 pid/thread >>> 1863/140490334701312 flags 0 priority 100 >>> 49 READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 4a dd=67 locks held 0 write locks 0 pid/thread >>> 1863/140491066709760 flags 0 priority 100 >>> 4b dd=66 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 4b READ 1 HELD ipaca/objectclass.db handle 0 >>> 4c dd=65 locks held 0 write locks 0 pid/thread >>> 1863/140490468984576 flags 0 priority 100 >>> 4d dd=64 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 4e dd=63 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 4e READ 1 HELD changelog/aci.db handle 0 >>> 4f dd=62 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 50 dd=61 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 50 READ 1 HELD userRoot/aci.db handle 0 >>> 51 dd=60 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 52 dd=59 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 52 READ 1 HELD ipaca/aci.db handle 0 >>> 53 dd=58 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 54 dd=57 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 54 READ 1 HELD userRoot/parentid.db handle 0 >>> 55 dd=56 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 56 dd=55 locks held 0 write locks 0 pid/thread >>> 1863/140490468984576 flags 0 priority 100 >>> 57 dd=54 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 57 READ 1 HELD userRoot/nsuniqueid.db >>> handle 0 >>> 58 dd=53 locks held 0 write locks 0 pid/thread >>> 1863/140490494162688 flags 0 priority 100 >>> 59 dd=52 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 >>> 5a dd=51 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 5b dd=50 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 5b READ 1 HELD >>> /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db >>> handle 0 >>> 5c dd=49 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 5d dd=48 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 5e dd=47 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 5e READ 1 HELD >>> /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db >>> handle 0 >>> 5f dd=46 locks held 0 write locks 0 pid/thread >>> 1863/140491104614144 flags 0 priority 100 >>> 60 dd=45 locks held 0 write locks 0 pid/thread >>> 1863/140491104614144 flags 0 priority 100 >>> 61 dd=44 locks held 0 write locks 0 pid/thread >>> 1863/140491426347008 flags 0 priority 100 >>> 62 dd=43 locks held 0 write locks 0 pid/thread >>> 1863/140490468984576 flags 0 priority 100 >>> 63 dd=42 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 63 READ 1 HELD changelog/nsuniqueid.db >>> handle 0 >>> 64 dd=41 locks held 1 write locks 0 pid/thread >>> 1863/140491426347008 flags 10 priority 100 >>> 64 READ 1 HELD changelog/changenumber.db >>> handle 0 >>> 65 dd=40 locks held 0 write locks 0 pid/thread >>> 1863/140490410235648 flags 0 priority 100 >>> 65 READ 1 WAIT changelog/changenumber.db >>> page 68 >>> 66 dd=39 locks held 0 write locks 0 pid/thread >>> 1863/140490854885120 flags 0 priority 100 >>> 67 dd=38 locks held 1 write locks 0 pid/thread >>> 1863/140491066709760 flags 10 priority 100 >>> 67 READ 1 HELD changelog/targetuniqueid.db >>> handle 0 >>> 68 dd=37 locks held 1 write locks 0 pid/thread >>> 1863/140491066709760 flags 10 priority 100 >>> 68 READ 1 HELD changelog/parentid.db handle 0 >>> 69 dd=36 locks held 1 write locks 0 pid/thread >>> 1863/140491066709760 flags 10 priority 100 >>> 69 READ 1 HELD changelog/ancestorid.db >>> handle 0 >>> 6a dd=35 locks held 1 write locks 0 pid/thread >>> 1863/140491066709760 flags 10 priority 100 >>> 6a READ 1 HELD changelog/numsubordinates.db >>> handle 0 >>> 6b dd=34 locks held 0 write locks 0 pid/thread >>> 1863/140490359879424 flags 0 priority 100 >>> 6b READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 6c dd=33 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 6c READ 1 HELD userRoot/nsTombstoneCSN.db >>> handle 0 >>> 6d dd=32 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 6d READ 1 HELD userRoot/nscpEntryDN.db >>> handle 0 >>> 6e dd=31 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 6e READ 1 HELD userRoot/numsubordinates.db >>> handle 0 >>> 6f dd=30 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 6f READ 1 HELD userRoot/member.db handle 0 >>> 70 dd=29 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 70 READ 1 HELD userRoot/uniquemember.db >>> handle 0 >>> 71 dd=28 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 71 READ 1 HELD userRoot/owner.db handle 0 >>> 72 dd=27 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 72 READ 1 HELD userRoot/seeAlso.db handle 0 >>> 73 dd=26 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 73 READ 1 HELD userRoot/manager.db handle 0 >>> 74 dd=25 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 74 READ 1 HELD userRoot/secretary.db handle 0 >>> 75 dd=24 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 75 READ 1 HELD userRoot/memberUser.db >>> handle 0 >>> 76 dd=23 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 76 READ 1 HELD userRoot/memberHost.db >>> handle 0 >>> 77 dd=22 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 77 READ 1 HELD userRoot/sourcehost.db >>> handle 0 >>> 78 dd=21 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 78 READ 1 HELD userRoot/memberservice.db >>> handle 0 >>> 79 dd=20 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 79 READ 1 HELD userRoot/managedby.db handle 0 >>> 7a dd=19 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 7a READ 1 HELD userRoot/memberallowcmd.db >>> handle 0 >>> 7b dd=18 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 7b READ 1 HELD userRoot/memberdenycmd.db >>> handle 0 >>> 7c dd=17 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 7c READ 1 HELD userRoot/ipasudorunas.db >>> handle 0 >>> 7d dd=16 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 7d READ 1 HELD userRoot/ipasudorunasgroup.db >>> handle 0 >>> 7e dd=15 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db >>> handle 0 >>> 7f dd=14 locks held 1 write locks 0 pid/thread >>> 1863/140490854885120 flags 10 priority 100 >>> 7f READ 1 HELD userRoot/ipaassignedidview.db >>> handle 0 >>> 80 dd=13 locks held 0 write locks 0 pid/thread >>> 1863/140490494162688 flags 0 priority 100 >>> 81 dd=12 locks held 0 write locks 0 pid/thread >>> 1863/140490468984576 flags 0 priority 100 >>> 82 dd=11 locks held 1 write locks 0 pid/thread >>> 1863/140490510948096 flags 10 priority 100 >>> 82 READ 1 HELD userRoot/krbPrincipalName.db >>> handle 0 >>> 83 dd=10 locks held 0 write locks 0 pid/thread >>> 1863/140490435413760 flags 0 priority 100 >>> 84 dd= 9 locks held 0 write locks 0 pid/thread >>> 1863/140490510948096 flags 0 priority 100 >>> 85 dd= 8 locks held 1 write locks 0 pid/thread >>> 1863/140490452199168 flags 10 priority 100 >>> 85 READ 1 HELD ipaca/requeststate.db handle 0 >>> 86 dd= 7 locks held 1 write locks 0 pid/thread >>> 1863/140490452199168 flags 10 priority 100 >>> 86 READ 1 HELD ipaca/requesttype.db handle 0 >>> 87 dd= 4 locks held 1 write locks 0 pid/thread >>> 1863/140490418628352 flags 10 priority 100 >>> 87 READ 1 HELD userRoot/memberOf.db handle 0 >>> 88 dd= 3 locks held 0 write locks 0 pid/thread >>> 1863/140490822526720 flags 0 priority 100 >>> 88 READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 89 dd= 2 locks held 0 write locks 0 pid/thread >>> 1863/140490805741312 flags 0 priority 100 >>> 89 READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 8a dd= 1 locks held 0 write locks 0 pid/thread >>> 1863/140490839312128 flags 0 priority 100 >>> 8b dd= 0 locks held 0 write locks 0 pid/thread >>> 1863/140490814134016 flags 0 priority 100 >>> 8b READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 800000f6 dd= 6 locks held 108 write locks 57 pid/thread >>> 1863/140490418628352 flags 0 priority 100 >>> 800000f6 READ 4 HELD userRoot/member.db page 356 >>> 800000f6 READ 4 HELD userRoot/member.db page 360 >>> 800000f6 READ 2 HELD userRoot/member.db page 403 >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 >>> 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 >>> 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 >>> 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 >>> 800000f6 READ 4 HELD userRoot/member.db page 405 >>> 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 >>> 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 >>> 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 >>> 800000f6 READ 3 HELD userRoot/memberHost.db page 96 >>> 800000f6 READ 10 HELD userRoot/memberUser.db page 166 >>> 800000f6 READ 15 HELD userRoot/member.db page 70 >>> 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 >>> 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 >>> 800000f6 READ 3 HELD userRoot/memberHost.db page 209 >>> 800000f6 READ 6 HELD userRoot/memberUser.db page 14 >>> 800000f6 READ 3 HELD userRoot/member.db page 26 >>> 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 >>> 800000f6 READ 5 HELD userRoot/memberHost.db page 87 >>> 800000f6 READ 10 HELD userRoot/member.db page 50 >>> 800000f6 READ 1 HELD userRoot/memberHost.db page 28 >>> 800000f6 READ 1 HELD userRoot/memberUser.db page 92 >>> 800000f6 READ 1 HELD userRoot/member.db page 43 >>> 800000f6 READ 2 HELD userRoot/memberUser.db page 103 >>> 800000f6 READ 2 HELD userRoot/member.db page 337 >>> 800000f6 READ 2 HELD userRoot/memberallowcmd.db >>> page 44 >>> 800000f6 READ 2 HELD userRoot/memberdenycmd.db >>> page 1 >>> 800000f6 READ 2 HELD userRoot/ipasudorunas.db >>> page 1 >>> 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db >>> page 1 >>> 800000f6 READ 2 HELD userRoot/objectclass.db >>> page 10 >>> 800000f6 READ 15 HELD userRoot/member.db page 406 >>> 800000f6 READ 61 HELD userRoot/objectclass.db >>> page 61 >>> 800000f6 READ 36 HELD userRoot/memberUser.db page 81 >>> 800000f6 READ 35 HELD userRoot/memberHost.db page 195 >>> 800000f6 READ 2 HELD userRoot/objectclass.db >>> page 50 >>> 800000f6 READ 1 HELD changelog/nsuniqueid.db page >>> 191 >>> 800000f6 READ 3 HELD changelog/entryrdn.db page 387 >>> 800000f6 READ 2 HELD changelog/entryrdn.db page 388 >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 >>> 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 >>> 800000f6 WRITE 3 HELD changelog/objectclass.db >>> page 1 >>> 800000f6 WRITE 1 HELD changelog/targetuniqueid.db >>> page 47 >>> 800000f6 WRITE 1 HELD changelog/changenumber.db >>> page 68 >>> 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page >>> 191 >>> 800000f6 WRITE 1 HELD changelog/parentid.db page 1 >>> 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 >>> 800000f6 WRITE 1 HELD changelog/ancestorid.db >>> page 1 >>> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 >>> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 >>> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 >>> 800000f6 WRITE 1 HELD changelog/numsubordinates.db >>> page 1 >>> 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 >>> 800000f6 READ 1 HELD userRoot/entryusn.db page 27 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 >>> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 >>> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 >>> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 >>> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 >>> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 >>> 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 >>> 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 >>> 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 >>> 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 >>> 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 >>> 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 >>> 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 >>> 80000106 dd= 5 locks held 17 write locks 13 pid/thread >>> 1863/140490410235648 flags 0 priority 100 >>> 80000106 WRITE 2 HELD >>> ipaca/vlv#caenrollmentpkitomcatindex.db page 1 >>> 80000106 WRITE 4 HELD >>> ipaca/vlv#caenrollmentpkitomcatindex.db page 5 >>> 80000106 WRITE 2 HELD >>> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 >>> 80000106 WRITE 4 HELD >>> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 >>> 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db >>> page 1 >>> 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db >>> page 5 >>> 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db >>> page 1 >>> 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db >>> page 5 >>> 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 >>> 80000106 READ 1 HELD ipaca/entryusn.db page 13 >>> 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 >>> 80000106 READ 1 HELD ipaca/requesttype.db page 1 >>> 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 >>> 80000106 READ 1 HELD ipaca/requeststate.db page 1 >>> 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 >>> 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 >>> 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 >>> 800001eb dd=4294967295 locks held 75 write locks 39 pid/thread >>> 1863/140490418628352 flags 0 priority 100 >>> 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 >>> 800001eb READ 1 HELD userRoot/entryusn.db page 27 >>> 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 219 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 259 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 253 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 207 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 91 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 10 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 211 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 143 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 121 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 228 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 78 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 272 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 189 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 156 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 148 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 142 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 258 >>> 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 >>> 800001eb READ 3 HELD userRoot/memberOf.db page 260 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 218 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 106 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 141 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 120 >>> 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 >>> 800001eb READ 2 HELD userRoot/memberOf.db page 126 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 97 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 196 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 240 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 73 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 42 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 251 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 75 >>> 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 >>> 800001eb READ 2 HELD userRoot/memberOf.db page 271 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 262 >>> 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 >>> 800001eb READ 3 HELD userRoot/memberOf.db page 255 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 245 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 >>> 800001eb READ 1 HELD userRoot/memberOf.db page 19 >>> 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 >>> 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Locks grouped by object: >>> Locker Mode Count Status ----------------- Object >>> --------------- >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 5573 >>> >>> 800000f6 WRITE 2 HELD changelog/id2entry.db page 5564 >>> >>> 2d READ 1 HELD changelog/entryusn.db handle 0 >>> >>> 39 READ 1 HELD userRoot/ancestorid.db >>> handle 0 >>> >>> 800000f6 READ 1 HELD userRoot/ancestorid.db page 2 >>> >>> 9 READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db >>> handle 0 >>> >>> 44 READ 1 HELD changelog/entryrdn.db handle 0 >>> >>> 800000f6 READ 1 HELD changelog/nsuniqueid.db page >>> 191 >>> 800000f6 WRITE 1 HELD changelog/nsuniqueid.db page >>> 191 >>> >>> 63 READ 1 HELD changelog/nsuniqueid.db >>> handle 0 >>> >>> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 917 >>> >>> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 919 >>> >>> 59 READ 1 HELD ipaca/nsuniqueid.db handle 0 >>> >>> 80000106 READ 2 HELD ipaca/nsuniqueid.db page 21 >>> >>> 7e READ 1 HELD userRoot/ipatokenradiusconfiglink.db >>> handle 0 >>> >>> d READ 1 HELD >>> ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 >>> >>> 75 READ 1 HELD userRoot/memberUser.db >>> handle 0 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 3 >>> >>> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 2 >>> >>> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 5 >>> >>> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 6 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 9 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 8 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 11 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 10 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 13 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 12 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 15 >>> >>> 800000f6 READ 6 HELD userRoot/memberUser.db page 14 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 19 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 20 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 23 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 22 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 25 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 24 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 27 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 26 >>> >>> 800000f6 WRITE 3 HELD userRoot/memberUser.db page 28 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 35 >>> >>> 800000f6 WRITE 2 HELD userRoot/memberUser.db page 34 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 74 >>> >>> 800000f6 READ 36 HELD userRoot/memberUser.db page 81 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 82 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 84 >>> >>> 800000f6 READ 1 HELD userRoot/memberUser.db page 92 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 97 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 103 >>> 800000f6 READ 2 HELD userRoot/memberUser.db page 103 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 104 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 109 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 163 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 164 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 167 >>> >>> 800000f6 READ 10 HELD userRoot/memberUser.db page 166 >>> >>> 800000f6 WRITE 4 HELD userRoot/memberUser.db page 168 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 189 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 191 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 190 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 193 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 192 >>> >>> 68 READ 1 HELD changelog/parentid.db handle 0 >>> >>> 800000f6 WRITE 1 HELD changelog/parentid.db page 1 >>> >>> 800000f6 WRITE 1 HELD userRoot/memberUser.db page 205 >>> >>> 14 READ 1 HELD >>> ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 >>> >>> 50 READ 1 HELD userRoot/aci.db handle 0 >>> >>> 7f READ 1 HELD userRoot/ipaassignedidview.db >>> handle 0 >>> >>> 72 READ 1 HELD userRoot/seeAlso.db handle 0 >>> >>> 70 READ 1 HELD userRoot/uniquemember.db >>> handle 0 >>> >>> 800000f6 READ 15 HELD userRoot/member.db page 406 >>> >>> 800000f6 READ 4 HELD userRoot/member.db page 405 >>> >>> 800000f6 READ 2 HELD userRoot/member.db page 403 >>> >>> 800001eb WRITE 1 HELD userRoot/id2entry.db page 1224 >>> >>> 16 READ 1 HELD >>> ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 >>> >>> 52 READ 1 HELD ipaca/aci.db handle 0 >>> >>> 800000f6 READ 2 HELD userRoot/member.db page 337 >>> >>> 800000f6 READ 4 HELD userRoot/member.db page 360 >>> >>> 800000f6 READ 4 HELD userRoot/member.db page 356 >>> >>> 73 READ 1 HELD userRoot/manager.db handle 0 >>> >>> 7c READ 1 HELD userRoot/ipasudorunas.db >>> handle 0 >>> >>> 800000f6 READ 2 HELD userRoot/ipasudorunas.db >>> page 1 >>> >>> 7d READ 1 HELD userRoot/ipasudorunasgroup.db >>> handle 0 >>> >>> 800000f6 READ 2 HELD userRoot/ipasudorunasgroup.db >>> page 1 >>> >>> 800000f6 READ 4 HELD userRoot/id2entry.db page 1663 >>> >>> 800000f6 READ 3 HELD userRoot/member.db page 26 >>> >>> 6f READ 1 HELD userRoot/member.db handle 0 >>> >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1714 >>> >>> 800000f6 READ 10 HELD userRoot/member.db page 50 >>> >>> 800000f6 READ 4 HELD userRoot/id2entry.db page 1712 >>> >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1726 >>> >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1722 >>> >>> 800000f6 READ 1 HELD userRoot/member.db page 43 >>> >>> 800000f6 READ 15 HELD userRoot/member.db page 70 >>> >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1679 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 272 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 272 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 259 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 259 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 258 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 258 >>> >>> 800001eb READ 3 HELD userRoot/memberOf.db page 260 >>> 800001eb WRITE 9 HELD userRoot/memberOf.db page 260 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 262 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 262 >>> >>> 800001eb READ 2 HELD userRoot/memberOf.db page 271 >>> 800001eb WRITE 6 HELD userRoot/memberOf.db page 271 >>> >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 1730 >>> >>> 26 READ 1 HELD >>> ipaca/vlv#carejectedenrollmentpkitomcatindex.db handle 0 >>> >>> 1f READ 1 HELD >>> ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 19 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 19 >>> >>> 87 READ 1 HELD userRoot/memberOf.db handle 0 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 10 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 10 >>> >>> 800001eb WRITE 1 HELD userRoot/memberOf.db page 37 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 42 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 42 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 91 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 91 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 73 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 73 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 75 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 75 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 78 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 78 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 121 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 121 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 120 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 120 >>> >>> 800001eb WRITE 2 HELD userRoot/id2entry.db page 0 >>> >>> 1 READ 1 HELD userRoot/id2entry.db handle 0 >>> >>> 800001eb READ 2 HELD userRoot/memberOf.db page 126 >>> 800001eb WRITE 6 HELD userRoot/memberOf.db page 126 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 97 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 97 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 106 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 106 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 148 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 148 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 156 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 156 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 141 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 141 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 143 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 143 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 142 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 142 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 189 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 189 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 211 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 211 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 219 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 219 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 218 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 218 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 196 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 196 >>> >>> f READ 1 HELD >>> ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 207 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 207 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 240 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 240 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 245 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 245 >>> >>> 78 READ 1 HELD userRoot/memberservice.db >>> handle 0 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 251 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 251 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 253 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 253 >>> >>> 800001eb READ 3 HELD userRoot/memberOf.db page 255 >>> 800001eb WRITE 9 HELD userRoot/memberOf.db page 255 >>> >>> 800001eb READ 1 HELD userRoot/memberOf.db page 228 >>> 800001eb WRITE 3 HELD userRoot/memberOf.db page 228 >>> >>> 80000106 WRITE 2 HELD ipaca/vlv#cacompletepkitomcatindex.db >>> page 1 >>> >>> 1c READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db >>> handle 0 >>> >>> 80000106 WRITE 4 HELD ipaca/vlv#cacompletepkitomcatindex.db >>> page 5 >>> >>> 13 READ 1 HELD >>> ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db >>> handle 0 >>> >>> 2a READ 1 HELD >>> ipaca/vlv#carevocationpkitomcatindex.db handle 0 >>> >>> 74 READ 1 HELD userRoot/secretary.db handle 0 >>> >>> 5 READ 1 HELD ipaca/entryrdn.db handle 0 >>> >>> 85 READ 1 HELD ipaca/requeststate.db handle 0 >>> >>> 80000106 READ 1 HELD ipaca/requeststate.db page 1 >>> 80000106 WRITE 4 HELD ipaca/requeststate.db page 1 >>> >>> 3b READ 1 HELD userRoot/macAddress.db >>> handle 0 >>> >>> 6e READ 1 HELD userRoot/numsubordinates.db >>> handle 0 >>> >>> 80000106 WRITE 2 HELD ipaca/vlv#caallpkitomcatindex.db >>> page 1 >>> >>> 17 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db >>> handle 0 >>> >>> 80000106 WRITE 4 HELD ipaca/vlv#caallpkitomcatindex.db >>> page 5 >>> >>> 10 READ 1 HELD >>> ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 >>> >>> 800000f6 READ 1 HELD userRoot/id2entry.db page 2495 >>> 800000f6 WRITE 1 HELD userRoot/id2entry.db page 2495 >>> 2 READ 1 WAIT userRoot/id2entry.db page 2495 >>> >>> 800000f6 READ 2 HELD userRoot/memberdenycmd.db >>> page 1 >>> >>> 7b READ 1 HELD userRoot/memberdenycmd.db >>> handle 0 >>> >>> 5e READ 1 HELD >>> /var/lib/dirsrv/slapd-xxxx/cldb/f3c29b1e-d15511e4-8d35ce39-9b469c1f_550feb15000000600000.db >>> handle 0 >>> >>> 4e READ 1 HELD changelog/aci.db handle 0 >>> >>> 67 READ 1 HELD changelog/targetuniqueid.db >>> handle 0 >>> >>> 800000f6 WRITE 1 HELD changelog/targetuniqueid.db >>> page 47 >>> >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 2 >>> >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 0 >>> >>> 2b READ 1 HELD changelog/id2entry.db handle 0 >>> >>> 25 READ 1 HELD ipaca/vlv#carejectedpkitomcatindex.db >>> handle 0 >>> >>> 800000f6 READ 4 HELD userRoot/id2entry.db page 2905 >>> >>> 2f READ 1 HELD userRoot/entryusn.db handle 0 >>> >>> 31 READ 1 HELD ipaca/entryusn.db handle 0 >>> >>> 80000106 READ 1 HELD ipaca/entryusn.db page 13 >>> 80000106 WRITE 3 HELD ipaca/entryusn.db page 13 >>> >>> 800000f6 READ 1 HELD userRoot/entryusn.db page 27 >>> 800000f6 WRITE 3 HELD userRoot/entryusn.db page 27 >>> 800001eb READ 1 HELD userRoot/entryusn.db page 27 >>> 800001eb WRITE 3 HELD userRoot/entryusn.db page 27 >>> >>> 800000f6 WRITE 1 HELD changelog/changenumber.db >>> page 68 >>> 65 READ 1 WAIT changelog/changenumber.db >>> page 68 >>> >>> 64 READ 1 HELD changelog/changenumber.db >>> handle 0 >>> >>> 800000f6 READ 1 HELD userRoot/entryrdn.db page 35 >>> >>> 82 READ 1 HELD userRoot/krbPrincipalName.db >>> handle 0 >>> >>> 800000f6 READ 2 HELD userRoot/memberallowcmd.db >>> page 44 >>> >>> 33 READ 1 HELD userRoot/entryrdn.db handle 0 >>> >>> 80000106 READ 1 HELD ipaca/requesttype.db page 1 >>> 80000106 WRITE 4 HELD ipaca/requesttype.db page 1 >>> >>> 86 READ 1 HELD ipaca/requesttype.db handle 0 >>> >>> 7a READ 1 HELD userRoot/memberallowcmd.db >>> handle 0 >>> >>> 800000f6 READ 18 HELD userRoot/entryrdn.db page 93 >>> >>> 800000f6 READ 18 HELD userRoot/entryrdn.db page 83 >>> >>> 800000f6 READ 4 HELD userRoot/entryrdn.db page 249 >>> >>> 37 READ 1 HELD userRoot/objectclass.db >>> handle 0 >>> >>> 800000f6 READ 5 HELD userRoot/entryrdn.db page 255 >>> >>> 800000f6 READ 2 HELD userRoot/objectclass.db >>> page 10 >>> >>> 800000f6 READ 4 HELD userRoot/entryrdn.db page 229 >>> >>> 77 READ 1 HELD userRoot/sourcehost.db >>> handle 0 >>> >>> 800000f6 READ 2 HELD userRoot/objectclass.db >>> page 50 >>> >>> 800000f6 WRITE 1 HELD changelog/id2entry.db page 7353 >>> >>> 48 READ 1 HELD changelog/objectclass.db >>> handle 0 >>> >>> 800000f6 WRITE 3 HELD changelog/objectclass.db >>> page 1 >>> 6b READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 49 READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 88 READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 89 READ 1 WAIT changelog/objectclass.db >>> page 1 >>> 8b READ 1 WAIT changelog/objectclass.db >>> page 1 >>> >>> 800000f6 READ 61 HELD userRoot/objectclass.db >>> page 61 >>> >>> 80000106 WRITE 4 HELD >>> ipaca/vlv#caenrollmentpkitomcatindex.db page 5 >>> >>> 20 READ 1 HELD >>> ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 >>> >>> 80000106 WRITE 2 HELD >>> ipaca/vlv#caenrollmentpkitomcatindex.db page 1 >>> >>> 800000f6 READ 3 HELD userRoot/entryrdn.db page 262 >>> >>> 6a READ 1 HELD changelog/numsubordinates.db >>> handle 0 >>> >>> 800000f6 WRITE 1 HELD changelog/numsubordinates.db >>> page 1 >>> >>> 800000f6 READ 1 HELD userRoot/entryrdn.db page 495 >>> >>> 800000f6 READ 18 HELD userRoot/entryrdn.db page 466 >>> >>> 54 READ 1 HELD userRoot/parentid.db handle 0 >>> >>> 80000106 WRITE 1 HELD ipaca/id2entry.db page 301 >>> >>> 800000f6 WRITE 1 HELD changelog/ancestorid.db >>> page 1 >>> >>> 69 READ 1 HELD changelog/ancestorid.db >>> handle 0 >>> >>> 4b READ 1 HELD ipaca/objectclass.db handle 0 >>> >>> 57 READ 1 HELD userRoot/nsuniqueid.db >>> handle 0 >>> >>> 800000f6 READ 2 HELD userRoot/nsuniqueid.db page 29 >>> >>> 5b READ 1 HELD >>> /var/lib/dirsrv/slapd-xxxx/cldb/9890a88b-d15511e4-8d35ce39-9b469c1f_550feacc000000040000.db >>> handle 0 >>> >>> 6d READ 1 HELD userRoot/nscpEntryDN.db >>> handle 0 >>> >>> 80000106 WRITE 4 HELD ipaca/id2entry.db page 0 >>> >>> 3 READ 1 HELD ipaca/id2entry.db handle 0 >>> >>> 6c READ 1 HELD userRoot/nsTombstoneCSN.db >>> handle 0 >>> >>> 800000f6 READ 5 HELD userRoot/memberHost.db page 87 >>> >>> 800000f6 READ 3 HELD userRoot/memberHost.db page 96 >>> >>> 800000f6 READ 1 HELD userRoot/memberHost.db page 28 >>> >>> 76 READ 1 HELD userRoot/memberHost.db >>> handle 0 >>> >>> 71 READ 1 HELD userRoot/owner.db handle 0 >>> >>> 800000f6 READ 3 HELD userRoot/memberHost.db page 209 >>> >>> 800000f6 READ 35 HELD userRoot/memberHost.db page 195 >>> >>> 15 READ 1 HELD >>> ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 >>> >>> 80000106 WRITE 4 HELD >>> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 5 >>> >>> 1d READ 1 HELD >>> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 >>> >>> 80000106 WRITE 2 HELD >>> ipaca/vlv#cacompleteenrollmentpkitomcatindex.db page 1 >>> >>> 79 READ 1 HELD userRoot/managedby.db handle 0 >>> >>> 800000f6 READ 3 HELD changelog/entryrdn.db page 387 >>> >>> 800000f6 READ 2 HELD changelog/entryrdn.db page 388 >>> 800000f6 WRITE 1 HELD changelog/entryrdn.db page 388 >>> >>> 800000f6 WRITE 1 HELD changelog/entryusn.db page 68 >>> >>> >>> Lukasz Jaworski 'Ender' >>> >>> >>> Wiadomo?? napisana przez thierry bordaz w dniu >>> 6 maj 2015, o godz. 11:47: >>> >>>> This is looking like thread 13 prevents thread 12 run (and all the >>>> others). >>>> Now thread 13 is likely waiting for db page? We may need output of >>>> db_stat (db_state -N -h /var/lib/dirsrv/slapd-xxx/db/ -CA) >>>> >>>> thanks >>>> thierry >>>> On 05/06/2015 11:31 AM, ?ukasz Jaworski wrote: >>>>>>> ldapsearch hangs. Dirsrv is not responding now. >>>>>> if the server is hanging, can you get a pstack >>>>> Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): >>>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #2 0x00007fc6a961f987 in deadlock_threadmain () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): >>>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #2 0x00007fc6a9623a4e in checkpoint_threadmain () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): >>>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #2 0x00007fc6a961fc0f in trickle_threadmain () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): >>>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #2 0x00007fc6a961a667 in perf_threadmain () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #3 0x00007fc6abd455be in cos_cache_wait_on_change () from >>>>> /usr/lib64/dirsrv/plugins/libcos-plugin.so >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): >>>>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () >>>>> from /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #3 0x00007fc6a937be84 in _cl5TrimMain () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6a93928d4 in protocol_sleep () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #3 0x00007fc6a93949e5 in repl5_inc_run () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #4 0x00007fc6a9399421 in prot_thread_main () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #5 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #6 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #7 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): >>>>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () >>>>> from /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #3 0x00007fc6a93928d4 in protocol_sleep () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #4 0x00007fc6a9395158 in repl5_inc_run () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #5 0x00007fc6a9399421 in prot_thread_main () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #6 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #7 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #8 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from >>>>> /usr/lib64/dirsrv/plugins/libroles-plugin.so >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 36 (Thread 0x7fc6a1203700 (LWP 1907)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from >>>>> /usr/lib64/dirsrv/plugins/libroles-plugin.so >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 35 (Thread 0x7fc6a0a02700 (LWP 1908)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5482c68 in slapi_wait_condvar () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #3 0x00007fc6a7cbef5d in roles_cache_wait_on_change () from >>>>> /usr/lib64/dirsrv/plugins/libroles-plugin.so >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 34 (Thread 0x7fc693fff700 (LWP 1909)): >>>>> #0 0x00007fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () >>>>> from /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #3 0x00007fc6b593a773 in housecleaning () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 33 (Thread 0x7fc6937fe700 (LWP 1910)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #6 0x00007fc6a939f76f in replica_write_ruv () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #7 0x00007fc6a939f9fe in replica_update_state () from >>>>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so >>>>> #8 0x00007fc6b542965a in eq_loop () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #9 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #10 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #11 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 32 (Thread 0x7fc692924700 (LWP 1912)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 31 (Thread 0x7fc692123700 (LWP 1913)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 30 (Thread 0x7fc691922700 (LWP 1914)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>>> /lib64/libdb-5.3.so >>>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>>> /lib64/libdb-5.3.so >>>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>>> /lib64/libdb-5.3.so >>>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #14 0x00007fc6a96272ed in keys2idl () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #17 0x00007fc6a96290ce in list_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #22 0x00007fc6b5943fc6 in do_search () >>>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 29 (Thread 0x7fc691121700 (LWP 1915)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>>> /lib64/libdb-5.3.so >>>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>>> /lib64/libdb-5.3.so >>>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>>> /lib64/libdb-5.3.so >>>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #14 0x00007fc6a96272ed in keys2idl () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #17 0x00007fc6a96290ce in list_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #22 0x00007fc6b5943fc6 in do_search () >>>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 28 (Thread 0x7fc690920700 (LWP 1916)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>>> /lib64/libdb-5.3.so >>>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>>> /lib64/libdb-5.3.so >>>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>>> /lib64/libdb-5.3.so >>>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #14 0x00007fc6a96272ed in keys2idl () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #17 0x00007fc6a96290ce in list_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #22 0x00007fc6b5943fc6 in do_search () >>>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 27 (Thread 0x7fc67ffff700 (LWP 1917)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 26 (Thread 0x7fc67f7fe700 (LWP 1918)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>>> /lib64/libdb-5.3.so >>>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>>> /lib64/libdb-5.3.so >>>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>>> /lib64/libdb-5.3.so >>>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>>> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >>>>> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>>> #8 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>>> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>>> #10 0x00007fc6add50ced in __db_get () from /lib64/libdb-5.3.so >>>>> #11 0x00007fc6add5473b in __db_get_pp () from /lib64/libdb-5.3.so >>>>> #12 0x00007fc6a962a9bb in id2entry () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #13 0x00007fc6a9626cbd in dn2entry_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #14 0x00007fc6a9629bb1 in find_entry_internal.isra () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #15 0x00007fc6a9629e99 in find_entry () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #16 0x00007fc6a9663b5b in ldbm_back_search () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #17 0x00007fc6b5455410 in op_shared_search () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #18 0x00007fc6b546553e in search_internal_callback_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #19 0x00007fc6b54657c8 in search_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #20 0x00007fc6b5465b73 in slapi_search_internal_get_entry () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #21 0x00007fc6aad02234 in ipalockout_preop () from >>>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>>> #22 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #23 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #24 0x00007fc6b592c3d8 in do_bind () >>>>> #25 0x00007fc6b5932974 in connection_threadmain () >>>>> #26 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #27 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #28 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 25 (Thread 0x7fc67effd700 (LWP 1919)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 24 (Thread 0x7fc67e7fc700 (LWP 1920)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 23 (Thread 0x7fc67dffb700 (LWP 1921)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 22 (Thread 0x7fc67d7fa700 (LWP 1922)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #9 0x00007fc6b592c22d in do_bind () >>>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 21 (Thread 0x7fc67cff9700 (LWP 1923)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #9 0x00007fc6b592c22d in do_bind () >>>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 20 (Thread 0x7fc67c7f8700 (LWP 1924)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 19 (Thread 0x7fc67bff7700 (LWP 1925)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #9 0x00007fc6b592c22d in do_bind () >>>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 18 (Thread 0x7fc67b7f6700 (LWP 1926)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 17 (Thread 0x7fc67aff5700 (LWP 1927)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 16 (Thread 0x7fc67a7f4700 (LWP 1928)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 15 (Thread 0x7fc679ff3700 (LWP 1929)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 14 (Thread 0x7fc6797f2700 (LWP 1930)): >>>>> #0 0x00007fc6b31eff1d in __lll_lock_wait () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b31ea9be in pthread_mutex_lock () from >>>>> /lib64/libpthread.so.0 >>>>> #2 0x00007fc6b38420b9 in PR_Lock () from /lib64/libnspr4.so >>>>> #3 0x00007fc6a7ec99b0 in retrocl_postob () from >>>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>>> #4 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #5 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #6 0x00007fc6a965d231 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #7 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #8 0x00007fc6b544f387 in modify_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #9 0x00007fc6a8d354a2 in memberof_fix_memberof_callback () from >>>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>>> #10 0x00007fc6a8d35f65 in memberof_modop_one_replace_r () from >>>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>>> #11 0x00007fc6a8d362a6 in memberof_mod_smod_list () from >>>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>>> #12 0x00007fc6a8d3758d in memberof_postop_modify () from >>>>> /usr/lib64/dirsrv/plugins/libmemberof-plugin.so >>>>> #13 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #14 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #15 0x00007fc6a965d231 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #16 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #17 0x00007fc6b544fbe7 in do_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #18 0x00007fc6b5932925 in connection_threadmain () >>>>> #19 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #20 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #21 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 13 (Thread 0x7fc678ff1700 (LWP 1931)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>>> /lib64/libdb-5.3.so >>>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>>> /lib64/libdb-5.3.so >>>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>>> /lib64/libdb-5.3.so >>>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>>> #6 0x00007fc6adc9e4f0 in __bam_search () from /lib64/libdb-5.3.so >>>>> #7 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>>> #8 0x00007fc6adc8b074 in __bamc_get () from /lib64/libdb-5.3.so >>>>> #9 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>>> #10 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>>> #11 0x00007fc6a9672b70 in ldbm_back_seq () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #12 0x00007fc6b54650f9 in seq_internal_callback_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #13 0x00007fc6b54652a9 in slapi_seq_callback () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #14 0x00007fc6a7ec8919 in retrocl_update_lastchangenumber () from >>>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>>> #15 0x00007fc6a7ec89bb in retrocl_assign_changenumber () from >>>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>>> #16 0x00007fc6a7ec99b5 in retrocl_postob () from >>>>> /usr/lib64/dirsrv/plugins/libretrocl-plugin.so >>>>> #17 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #18 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #19 0x00007fc6a965d231 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #20 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #21 0x00007fc6b544fbe7 in do_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #22 0x00007fc6b5932925 in connection_threadmain () >>>>> #23 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #24 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #25 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 12 (Thread 0x7fc6787f0700 (LWP 1932)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 11 (Thread 0x7fc677fef700 (LWP 1933)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 10 (Thread 0x7fc6777ee700 (LWP 1934)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #9 0x00007fc6b592c22d in do_bind () >>>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 9 (Thread 0x7fc676fed700 (LWP 1935)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b38426b3 in PR_EnterMonitor () from /lib64/libnspr4.so >>>>> #2 0x00007fc6a9622456 in dblayer_txn_begin () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #3 0x00007fc6a965d615 in ldbm_back_modify () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #4 0x00007fc6b544e905 in op_shared_modify () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #5 0x00007fc6b544f387 in modify_internal_pb () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #6 0x00007fc6aad02bd3 in ipalockout_postop () from >>>>> /usr/lib64/dirsrv/plugins/libipa_lockout.so >>>>> #7 0x00007fc6b546156f in plugin_call_func () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #8 0x00007fc6b5461893 in plugin_call_plugins () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #9 0x00007fc6b592c22d in do_bind () >>>>> #10 0x00007fc6b5932974 in connection_threadmain () >>>>> #11 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #12 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #13 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 8 (Thread 0x7fc6767ec700 (LWP 1936)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 7 (Thread 0x7fc675feb700 (LWP 1937)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>>> /lib64/libdb-5.3.so >>>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>>> /lib64/libdb-5.3.so >>>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>>> /lib64/libdb-5.3.so >>>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #14 0x00007fc6a96272ed in keys2idl () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #17 0x00007fc6a96290ce in list_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #22 0x00007fc6b5943fc6 in do_search () >>>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 6 (Thread 0x7fc6757ea700 (LWP 1938)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 5 (Thread 0x7fc674fe9700 (LWP 1939)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 4 (Thread 0x7fc6747e8700 (LWP 1940)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6adc811fb in __db_hybrid_mutex_suspend () from >>>>> /lib64/libdb-5.3.so >>>>> #2 0x00007fc6adc8059b in __db_tas_mutex_lock () from >>>>> /lib64/libdb-5.3.so >>>>> #3 0x00007fc6add2aa91 in __lock_get_internal () from >>>>> /lib64/libdb-5.3.so >>>>> #4 0x00007fc6add2b657 in __lock_get () from /lib64/libdb-5.3.so >>>>> #5 0x00007fc6add576af in __db_lget () from /lib64/libdb-5.3.so >>>>> #6 0x00007fc6adc9d5d9 in __bam_get_root () from /lib64/libdb-5.3.so >>>>> #7 0x00007fc6adc9d91b in __bam_search () from /lib64/libdb-5.3.so >>>>> #8 0x00007fc6adc89144 in __bamc_search () from /lib64/libdb-5.3.so >>>>> #9 0x00007fc6adc8adff in __bamc_get () from /lib64/libdb-5.3.so >>>>> #10 0x00007fc6add43ba3 in __dbc_iget () from /lib64/libdb-5.3.so >>>>> #11 0x00007fc6add53092 in __dbc_get_pp () from /lib64/libdb-5.3.so >>>>> #12 0x00007fc6a962e6de in idl_new_fetch () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #13 0x00007fc6a963cc2b in index_read_ext_allids () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #14 0x00007fc6a96272ed in keys2idl () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #15 0x00007fc6a9627afe in ava_candidates.isra () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #16 0x00007fc6a96280fa in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #17 0x00007fc6a96290ce in list_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #18 0x00007fc6a9628062 in filter_candidates_ext () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #19 0x00007fc6a96631a7 in subtree_candidates () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #20 0x00007fc6a9664811 in ldbm_back_search () from >>>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so >>>>> #21 0x00007fc6b5455410 in op_shared_search () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #22 0x00007fc6b5943fc6 in do_search () >>>>> #23 0x00007fc6b5932b4c in connection_threadmain () >>>>> #24 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #25 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #26 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 3 (Thread 0x7fc673fe7700 (LWP 1941)): >>>>> #0 0x00007fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so >>>>> #2 0x00007fc6b5930b9e in connection_wait_for_new_work () >>>>> #3 0x00007fc6b5931dc9 in connection_threadmain () >>>>> #4 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #5 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #6 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 2 (Thread 0x7fc6737e6700 (LWP 1942)): >>>>> #0 0x00007fc6b2f1aae3 in select () from /lib64/libc.so.6 >>>>> #1 0x00007fc6b5492a99 in DS_Sleep () from >>>>> /usr/lib64/dirsrv/libslapd.so.0 >>>>> #2 0x00007fc6b5933855 in time_thread () >>>>> #3 0x00007fc6b3847cab in _pt_root () from /lib64/libnspr4.so >>>>> #4 0x00007fc6b31e852a in start_thread () from /lib64/libpthread.so.0 >>>>> #5 0x00007fc6b2f2422d in clone () from /lib64/libc.so.6 >>>>> Thread 1 (Thread 0x7fc6b58fb800 (LWP 1863)): >>>>> #0 0x00007fc6b2f18c8d in poll () from /lib64/libc.so.6 >>>>> #1 0x00007fc6b3843da8 in _pr_poll_with_poll () from >>>>> /lib64/libnspr4.so >>>>> #2 0x00007fc6b5936b11 in slapd_daemon () >>>>> #3 0x00007fc6b59294f4 in main () >>>>> >>>>> >>>>>>> This replica is on virtual machine (ganeti). We had problems >>>>>>> with replication to vm, but after force-sync all was fine. On >>>>>>> physical servers all works fine. >>>>>> the messages indicate there could be many concurrent operations, >>>>>> because individual ops are not fast enough, could your VM have >>>>>> less/slower resources than the physical machines ? >>>>> VMs have less rsources and slower than physical machines. >>>>> VM: 4 cpu, hd via drbd on sas drives, >>>>> >>>>> physical: more cores, faster (ssd) drives >>>>> >>>>> Best regards, >>>>> Lukasz Jaworski 'Ender' >>>>> >>>>> >>>>> >>>>>>> Lukasz Jaworski 'Ender' >>>>>>> >>>>>>> Wiadomo?? napisana przez Ludwig Krispenz w >>>>>>> dniu 6 maj 2015, o godz. 10:52: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> there seem to be different issues, >>>>>>>> - I don't know what the ipactl status is looking for when it >>>>>>>> generates the error message about no matching master, >>>>>>>> but I don't think it is related to the retro changelog. >>>>>>>> >>>>>>>> - the retro changelog errors for adding and deleting >>>>>>>> -- the add failures are about aborted transactions because a >>>>>>>> page cannot be accessed, this maybe caused by concurrent mods >>>>>>>> on different backends, which want to update teh shared retro cl >>>>>>>> database. >>>>>>>> the changenumber reprted seems to be increasing, one error is >>>>>>>> about changenumber 44975, the next about 45577, so it looks >>>>>>>> like changes into the changelog are written and teh >>>>>>>> changenumber increases >>>>>>>> -- i'm not sure about the delete errors, but normally trimming >>>>>>>> would go on after such an error message, the changenumber >>>>>>>> attempted to delete are increasing. >>>>>>>> Could you verify which changes are in the changelog, and if >>>>>>>> these are changing: >>>>>>>> ldapsearch -b "cn=changelog" dn >>>>>>>> >>>>>>>> On 05/06/2015 09:52 AM, ?ukasz Jaworski wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> One of our replica hanged up morning. Error log after dirsrv >>>>>>>>> restart: >>>>>>>>> [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete >>>>>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 38376 (rc: >>>>>>>>> 51) >>>>>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching Null >>>>>>>>> DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. >>>>>>>>> [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id >>>>>>>>> for changenumber=44975,cn=changelog from entryrdn index (-30993) >>>>>>>>> [06/May/2015:09:28:15 +0200] - Operation error fetching >>>>>>>>> changenumber=44975,cn=changelog (null), error -30993. >>>>>>>>> [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an >>>>>>>>> error occured while adding change number 44975, dn = >>>>>>>>> changenumber=44975,cn=changelog: Operations error. >>>>>>>>> [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: >>>>>>>>> operation failure [1] >>>>>>>>> [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry >>>>>>>>> BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>>>>> [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry >>>>>>>>> BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>>>>> [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete >>>>>>>>> [06/May/2015:09:30:06 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39297 (rc: >>>>>>>>> 51) >>>>>>>>> >>>>>>>>> I did "re-initialize" from other replica. >>>>>>>>> >>>>>>>>> Now ipactl doesn't work. Shows: Configured hostname >>>>>>>>> 'replica09.local' does not match any master server in LDAP. On >>>>>>>>> lists replica09 is exists (twice) >>>>>>>>> >>>>>>>>> # ipactl status >>>>>>>>> Failed to get list of services to probe status! >>>>>>>>> Configured hostname 'replica09.local' does not match any >>>>>>>>> master server in LDAP: >>>>>>>>> replica01.local >>>>>>>>> replica02.local >>>>>>>>> replica03.local >>>>>>>>> replica04.local >>>>>>>>> replica05.local >>>>>>>>> replica06.local >>>>>>>>> replica07.local >>>>>>>>> replica08.local >>>>>>>>> replica09.local >>>>>>>>> replica10.local >>>>>>>>> replica09.local >>>>>>>>> >>>>>>>>> After dirsrv stop/start: >>>>>>>>> >>>>>>>>> In error logs there are many: >>>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39290 (rc: >>>>>>>>> 32) >>>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39291 (rc: >>>>>>>>> 32) >>>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39292 (rc: >>>>>>>>> 32) >>>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39293 (rc: >>>>>>>>> 32) >>>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39294 (rc: >>>>>>>>> 32) >>>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39295 (rc: >>>>>>>>> 32) >>>>>>>>> [06/May/2015:09:50:30 +0200] DSRetroclPlugin - >>>>>>>>> delete_changerecord: could not delete change record 39296 (rc: >>>>>>>>> 32) >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching Null >>>>>>>>> DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. >>>>>>>>> [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id >>>>>>>>> for changenumber=45577,cn=changelog from entryrdn index (-30993) >>>>>>>>> [06/May/2015:09:51:08 +0200] - Operation error fetching >>>>>>>>> changenumber=45577,cn=changelog (null), error -30993. >>>>>>>>> [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an >>>>>>>>> error occured while adding change number 45577, dn = >>>>>>>>> changenumber=45577,cn=changelog: Operations error. >>>>>>>>> [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: >>>>>>>>> operation failure [1] >>>>>>>>> [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry >>>>>>>>> BAD 1601, err=0 BDB0062 Successful return: 0 >>>>>>>>> >>>>>>>>> Packages: >>>>>>>>> freeipa-server-4.1.3-2.fc21.x86_64 >>>>>>>>> 389-ds-base-1.3.3.8-1.fc21.x86_64 >>>>>>>>> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Ender >>>>>>>>> >>>>>>>> -- >>>>>>>> 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 >> > > From dpal at redhat.com Thu May 7 00:14:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 May 2015 20:14:58 -0400 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com><20150505163959.GV3267@p.redhat.com><20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> Message-ID: <554AAE82.8060204@redhat.com> On 05/06/2015 12:14 AM, Nathan Peters wrote: >> From this link : > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb > > > The diagram in that section shows the client communicating with > FreeIPA and FreeIPA contacting AD. > > So why are you saying the client authenticates with the AD DC directly? You are looking at the older documentation. It is for RHEL6. Please use RHEL7.1 docs to get the latest info about 4.1 functionality. > > Also this page here : > https://www.freeipa.org/page/Active_Directory_trust_setup > > does not list having to add the AD domain in the krb5.conf. Is that > not necessary in the example because they are not using a different > UPN for their users like we are? > > -----Original Message----- From: Jakub Hrozek > Sent: Tuesday, May 05, 2015 8:43 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" > - AD trust and UPN issues > > On Tue, May 05, 2015 at 02:21:40PM -0700, nathan at nathanpeters.com wrote: >> I'm a little confused by that. >> >> If I add the AD dc, will my client try to contact AD directly to get a >> ticket? >> >> Doesn't it have to do get the ticket through FreeIPA by proxy somehow? > > No, authentication is always performed against an AD DC directly. > >> >> And to confirm what you meant by add the AD dc and realm, it would be >> like >> this ? >> >> SUB.ADDOMAIN.NET = { >> kdc = dc1.addomain.net:88 >> } >> >> I don't need the master_kdc, admin_server, default_domain entries? > > With a recent version of libkrb5 I don't think you need to set > master_kdc, libkrb5 should be able to follow referrals itself. > admin_servre, if unset, defaults to KDC. default_domain doesn't need to > be set either. > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu May 7 00:16:38 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 May 2015 20:16:38 -0400 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <6de84ca0250ed83df9c6ba0bf051ac6f.squirrel@webmail.nathanpeters.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> <20150506061248.GY3267@p.redhat.com> <6de84ca0250ed83df9c6ba0bf051ac6f.squirrel@webmail.nathanpeters.com> Message-ID: <554AAEE6.1050501@redhat.com> On 05/06/2015 02:15 PM, nathan at nathanpeters.com wrote: > Ok, I have attempted to set this up by adding the AD domain to my > configuration and it still isn't working. > I just want to confirm what I'm trying to accomplish here before I list > what I've done to troubleshoot this. > > We have an AD domain called corp.addomain.net. We have UPNs set so AD > users login to the AD domain as adusername at addomain.net when they login to > windows machines. > > The linux clients in our network are currently just using straight up > kerberos authentication against the domain and can currently login as > 'username' without entering any suffix. > > Because this means we can't control sudo policies centrally by our current > direct kerberos connection, we want to switch to logging in through > FreeIPA. > I need to be clear that we want to maintain the current logins of just > 'username' on Linux servers. > > To accomplish this, I added the following line to the sssd.conf file: > default_domain_suffix = corp.addomain.net I am not by any mean a specialist here but shouldn't it be the actual suffix that is appended to the user name, i.e. default_domain_suffix = addomain.net > > I have tried 3 different combinations of kerberos config to try to get the > logins to work, but am running into errors in each case. I have tried to > follow the suggestions given earlier in this thread. Here are the 3 > krb.conf configurations I tried and the errors given on each try. > > -------------- configuration 1 ------------------- > > [realms] > IPADOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = > RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ > auth_to_local = DEFAULT > } > CORP.ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > [domain_realm] > .ipadomain.net = IPADOMAIN.NET > ipadomain.net = IPADOMAIN.NET > .corp.addomain.net = CORP.ADDOMAIN.NET > corp.addomain.net = CORP.ADDOMAIN.NET > > > May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot > find KDC for realm "ADDOMAIN.NET" > May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot > find KDC for realm "ADDOMAIN.NET" > May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=adusername > May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): received > for user adusername: 4 (System error) > May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for > adusername from 10.5.5.57 port 1832 ssh2 > > ----------- configuration 2 ---------------- > > Notes : since the above error seemed to imply that I needed to add the > 'UPN realm' to the [realms] section I tried to add it. > > [realms] > IPADOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = > RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ > auth_to_local = DEFAULT > > } > ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > [domain_realm] > .ipadomain.net = IPADOMAIN.NET > ipadomain.net = IPADOMAIN.NET > addomain.net = ADDOMAIN.NET > .addomain.net = ADDOMAIN.NET > > May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm > not local to KDC > May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm > not local to KDC > May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=adusername > May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): received > for user adusername: 4 (System error) > May 06 16:48:34 dc1.ipadomain.net sshd[7542]: Failed password for > adusername from 10.5.5.57 port 1870 ssh2 > > ---- configuration 3 ----- > Notes : Since the eror message given in the second try indicated that the > realm wasn't local, I thought it might need both variations to recognize > it as local. > > [realms] > IPADOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > CORP.ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > [domain_realm] > .ipadomain.net = IPADOMAIN.NET > ipadomain.net = IPADOMAIN.NET > addomain.net = ADDOMAIN.NET > .addomain.net = ADDOMAIN.NET > corp.addomain.net = CORP.ADDOMAIN.NET > .corp.addomain.net = CORP.ADDOMAIN.NET > > May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm > not local to KDC > May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm > not local to KDC > May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=adusername > May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): received > for user adusername: 4 (System error) > May 06 16:56:28 dc1.ipadomain.net sshd[7660]: Failed password for > adusername from 10.5.5.57 port 1964 ssh2 > > > >> If you want to look up user data like e.g. the UID or the home >> directory the IPA client will talk to the IPA server exclusively, if the >> server does not know about the requested AD user it will try to get this >> information from a AD DC. >> >> For authentication this is different, because only the AD DC should know >> the password of the user. Hence authentication ans password changes as >> well are done directly with the AD DC. >> >>> Also this page here : >>> https://www.freeipa.org/page/Active_Directory_trust_setup >>> >>> does not list having to add the AD domain in the krb5.conf. Is that not >>> necessary in the example because they are not using a different UPN for >>> their users like we are? >> yes, it is because of the UPN in your case. As I said before this >> special entry in krb5.conf would not be needed anymore if the IPA KDC >> supports the Kerberos client referrals for the trusted domains. Adding >> the entry to krb5.conf in only a work-around here. >> >> bye, >> Sumit > > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu May 7 00:22:06 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 May 2015 20:22:06 -0400 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: Message-ID: <554AB02E.6080305@redhat.com> On 05/06/2015 05:11 PM, box 31978 wrote: > Hello everyone, > > These days I'm testing integration between FreeIPA4 and Samba4 at file > sharing level. Everything seems to work fine except share access from > a standalone Windows client. > > This is the setup (everything is up-to-date): > - ipa-server: CentOS 7.1, ipa-server 4.1, ipa-server-trust-ad plugin > - file-server: CentOS 7.1, ipa-client 4.1, samba 4.1 (sharing home > dirs, not a DC) > - win-client: Windows 7 Home Premium > > Config is done following the FreeIPA's Samba integration guide, and > testing with samba-client from ipa-server (or any other ipa-joined > machine) to file-server using kerberos after calling kinit is > successful (file manipulation included). > > Attempts to connect to the same share from win-client ends up with a > log in error. Analyzing logs: Samba can't find the user because it > can't find any DC, and that's because Samba can't resolve workgroup > name (note that's not a question of SSO: win-client asks to type > username and password). It seems that maybe Samba is not handling new > kerberos ticket requests. > > By now, my questions are: > - Can this setup work or it is absolutely necessary that any Windows > client expecting to access Samba shares have to be already joined to a > trusted domain? Samba can have different ID sources. May be there is a way to somehow specify users that are not members of the domain locally on the Samba server. At least this is what I would research if I faced that issue. > - If this setup can't be done, I'll go for an LDAP config in > file-server against ipa-server, but then, can I maintain the > file-server joined with ipa-client? Will it work? Yes. With SSSD 1.12 on the file server it should work. https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient > > Feel free to ask whatever you want, any suggestions will be welcome. > Thanks! > > Regards, > > A. > > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Thu May 7 00:25:53 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 06 May 2015 17:25:53 -0700 Subject: [Freeipa-users] more replication fun Message-ID: <554AB111.5050601@gmail.com> Hi again.. Seems to be an ongoing theme (replication). How does one remove these? unable to decode: {replica 9} 553ef80e000100090000 55402c39000000090000 I am hoping this is a stupid question with a really simple answer that I am simply missing? ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Frolushkin at megafon.ru Thu May 7 02:58:15 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Thu, 7 May 2015 02:58:15 +0000 Subject: [Freeipa-users] Known issues with IPA on VM? In-Reply-To: References: <960471ec49d743548a0e3d7a3657f11d@sib-ums03.Megafon.ru> Message-ID: Just a guess, what is your deployment size? We have a two ipa domains, one have 3 servers (2 hw and 1 vm, no issues with dirsrv yet), another currently includes 16 vm servers, ant dirsrv hangs and crashes periodically? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 From: David Dejaeghere [mailto:david.dejaeghere at gmail.com] Sent: Wednesday, May 06, 2015 3:26 PM To: Alexander Frolushkin (SIB) Cc: Christoph Kaminski; Freeipa-users Subject: Re: [Freeipa-users] Known issues with IPA on VM? Running FreeIPA 4.1 on Fedora 21 on Xenserver 6.2 in HVM mode. No issues. Kind Regards, David 2015-05-06 11:15 GMT+02:00 Alexander Frolushkin >: Hello. We have periodically hanging and crashing dirsrv in our ipa servers. All of them running in VM on Vmware. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Christoph Kaminski Sent: Wednesday, May 06, 2015 11:48 AM To: Freeipa-users Subject: [Freeipa-users] Known issues with IPA on VM? Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) Greetz Christoph Kaminski ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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 ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaclav.adamec at suchy-zleb.cz Thu May 7 03:12:06 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Thu, 7 May 2015 05:12:06 +0200 Subject: [Freeipa-users] more replication fun In-Reply-To: <554AB111.5050601@gmail.com> References: <554AB111.5050601@gmail.com> Message-ID: Hi, Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode thread), if you are sure that's not any live replica server behind this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" Vasek On Thu, May 7, 2015 at 2:25 AM, Janelle wrote: > > Hi again.. > > Seems to be an ongoing theme (replication). How does one remove these? > > unable to decode: {replica 9} 553ef80e000100090000 55402c39000000090000 > > I am hoping this is a stupid question with a really simple answer that I am simply missing? > > ~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 project -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " From janellenicole80 at gmail.com Thu May 7 03:39:06 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 06 May 2015 20:39:06 -0700 Subject: [Freeipa-users] more replication fun In-Reply-To: References: <554AB111.5050601@gmail.com> Message-ID: <554ADE5A.90801@gmail.com> On 5/6/15 8:12 PM, Vaclav Adamec wrote: > Hi, > Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode > thread), if you are sure that's not any live replica server behind > this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" > > Vasek > > > On Thu, May 7, 2015 at 2:25 AM, Janelle wrote: >> Hi again.. >> >> Seems to be an ongoing theme (replication). How does one remove these? >> >> unable to decode: {replica 9} 553ef80e000100090000 55402c39000000090000 >> >> I am hoping this is a stupid question with a really simple answer that I am simply missing? >> >> ~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 project > > > Thank you Vasek, I am curious however. I have been running OpenLDAP configs with 20 or more servers in replication for over 5 years. In all that time, I think I have had replication issues 5 times. In the 6 months of working with FreeIPA, replication issues are constant. From reading the threads, I am not the only one in this predicament. Is there any history on why replication is so problematic in FreeIPA? regards ~J From nathan at nathanpeters.com Thu May 7 04:43:54 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 6 May 2015 21:43:54 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <554AAEE6.1050501@redhat.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> <20150506061248.GY3267@p.redhat.com> <6de84ca0250ed83df9c6ba0bf051ac6f.squirrel@webmail.nathanpeters.com> <554AAEE6.1050501@redhat.com> Message-ID: > On 05/06/2015 02:15 PM, nathan at nathanpeters.com wrote: >> Ok, I have attempted to set this up by adding the AD domain to my >> configuration and it still isn't working. >> I just want to confirm what I'm trying to accomplish here before I list >> what I've done to troubleshoot this. >> >> We have an AD domain called corp.addomain.net. We have UPNs set so AD >> users login to the AD domain as adusername at addomain.net when they login >> to >> windows machines. >> >> The linux clients in our network are currently just using straight up >> kerberos authentication against the domain and can currently login as >> 'username' without entering any suffix. >> >> Because this means we can't control sudo policies centrally by our >> current >> direct kerberos connection, we want to switch to logging in through >> FreeIPA. >> I need to be clear that we want to maintain the current logins of just >> 'username' on Linux servers. >> >> To accomplish this, I added the following line to the sssd.conf file: >> default_domain_suffix = corp.addomain.net > > I am not by any mean a specialist here but shouldn't it be the actual > suffix that is appended to the user name, i.e. > > default_domain_suffix = addomain.net I don't think so. I think it is technically supposed to be the actual domain, since the upn is just an alias at the username level. When I try with addomain.net instead of the actual domain corp.addomain.net it doesnt' even recognize the username or try to contact any kdc. Here is the log entry: May 07 04:38:24 dc1.ipadomain.net sshd[9893]: Invalid user adusername from 10.5.5.57 May 07 04:38:24 dc1.ipadomain.net sshd[9893]: input_userauth_request: invalid user adusername [preauth] May 07 04:38:27 dc1.ipadomain.net sshd[9893]: pam_unix(sshd:auth): check pass; user unknown May 07 04:38:27 dc1.ipadomain.net sshd[9893]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 May 07 04:38:28 dc1.ipadomain.net sshd[9893]: Failed password for invalid user adusername from 10.5.5.57 port 10921 ssh2 > > > >> >> I have tried 3 different combinations of kerberos config to try to get >> the >> logins to work, but am running into errors in each case. I have tried >> to >> follow the suggestions given earlier in this thread. Here are the 3 >> krb.conf configurations I tried and the errors given on each try. >> >> -------------- configuration 1 ------------------- >> >> [realms] >> IPADOMAIN.NET = { >> kdc = dc1.ipadomain.net:88 >> master_kdc = dc1.ipadomain.net:88 >> admin_server = dc1.ipadomain.net:749 >> default_domain = ipadomain.net >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = >> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ >> auth_to_local = DEFAULT >> } >> CORP.ADDOMAIN.NET = { >> kdc = dc3.corp.addomain.net:88 >> master_kdc = dc3.corp.addomain.net:88 >> } >> >> [domain_realm] >> .ipadomain.net = IPADOMAIN.NET >> ipadomain.net = IPADOMAIN.NET >> .corp.addomain.net = CORP.ADDOMAIN.NET >> corp.addomain.net = CORP.ADDOMAIN.NET >> >> >> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot >> find KDC for realm "ADDOMAIN.NET" >> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot >> find KDC for realm "ADDOMAIN.NET" >> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=adusername >> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): >> received >> for user adusername: 4 (System error) >> May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for >> adusername from 10.5.5.57 port 1832 ssh2 >> >> ----------- configuration 2 ---------------- >> >> Notes : since the above error seemed to imply that I needed to add the >> 'UPN realm' to the [realms] section I tried to add it. >> >> [realms] >> IPADOMAIN.NET = { >> kdc = dc1.ipadomain.net:88 >> master_kdc = dc1.ipadomain.net:88 >> admin_server = dc1.ipadomain.net:749 >> default_domain = ipadomain.net >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = >> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ >> auth_to_local = DEFAULT >> >> } >> ADDOMAIN.NET = { >> kdc = dc3.corp.addomain.net:88 >> master_kdc = dc3.corp.addomain.net:88 >> } >> >> [domain_realm] >> .ipadomain.net = IPADOMAIN.NET >> ipadomain.net = IPADOMAIN.NET >> addomain.net = ADDOMAIN.NET >> .addomain.net = ADDOMAIN.NET >> >> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm >> not local to KDC >> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm >> not local to KDC >> May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=adusername >> May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): >> received >> for user adusername: 4 (System error) >> May 06 16:48:34 dc1.ipadomain.net sshd[7542]: Failed password for >> adusername from 10.5.5.57 port 1870 ssh2 >> >> ---- configuration 3 ----- >> Notes : Since the eror message given in the second try indicated that >> the >> realm wasn't local, I thought it might need both variations to recognize >> it as local. >> >> [realms] >> IPADOMAIN.NET = { >> kdc = dc1.ipadomain.net:88 >> master_kdc = dc1.ipadomain.net:88 >> admin_server = dc1.ipadomain.net:749 >> default_domain = ipadomain.net >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> ADDOMAIN.NET = { >> kdc = dc3.corp.addomain.net:88 >> master_kdc = dc3.corp.addomain.net:88 >> } >> >> CORP.ADDOMAIN.NET = { >> kdc = dc3.corp.addomain.net:88 >> master_kdc = dc3.corp.addomain.net:88 >> } >> >> [domain_realm] >> .ipadomain.net = IPADOMAIN.NET >> ipadomain.net = IPADOMAIN.NET >> addomain.net = ADDOMAIN.NET >> .addomain.net = ADDOMAIN.NET >> corp.addomain.net = CORP.ADDOMAIN.NET >> .corp.addomain.net = CORP.ADDOMAIN.NET >> >> May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm >> not local to KDC >> May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm >> not local to KDC >> May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=adusername >> May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): >> received >> for user adusername: 4 (System error) >> May 06 16:56:28 dc1.ipadomain.net sshd[7660]: Failed password for >> adusername from 10.5.5.57 port 1964 ssh2 >> >> >> >>> If you want to look up user data like e.g. the UID or the home >>> directory the IPA client will talk to the IPA server exclusively, if >>> the >>> server does not know about the requested AD user it will try to get >>> this >>> information from a AD DC. >>> >>> For authentication this is different, because only the AD DC should >>> know >>> the password of the user. Hence authentication ans password changes as >>> well are done directly with the AD DC. >>> >>>> Also this page here : >>>> https://www.freeipa.org/page/Active_Directory_trust_setup >>>> >>>> does not list having to add the AD domain in the krb5.conf. Is that >>>> not >>>> necessary in the example because they are not using a different UPN >>>> for >>>> their users like we are? >>> yes, it is because of the UPN in your case. As I said before this >>> special entry in krb5.conf would not be needed anymore if the IPA KDC >>> supports the Kerberos client referrals for the trusted domains. Adding >>> the entry to krb5.conf in only a work-around here. >>> >>> bye, >>> Sumit >> >> > > > -- > Thank you, > Dmitri Pal > > Director of Engineering for 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 > From abokovoy at redhat.com Thu May 7 05:28:05 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 7 May 2015 08:28:05 +0300 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: Message-ID: <20150507052805.GY11785@redhat.com> On Wed, 06 May 2015, box 31978 wrote: >Hello everyone, > >These days I'm testing integration between FreeIPA4 and Samba4 at file >sharing level. Everything seems to work fine except share access from a >standalone Windows client. > >This is the setup (everything is up-to-date): >- ipa-server: CentOS 7.1, ipa-server 4.1, ipa-server-trust-ad plugin >- file-server: CentOS 7.1, ipa-client 4.1, samba 4.1 (sharing home dirs, >not a DC) >- win-client: Windows 7 Home Premium > >Config is done following the FreeIPA's Samba integration guide, and testing >with samba-client from ipa-server (or any other ipa-joined machine) to >file-server using kerberos after calling kinit is successful (file >manipulation included). > >Attempts to connect to the same share from win-client ends up with a log in >error. Analyzing logs: Samba can't find the user because it can't find any >DC, and that's because Samba can't resolve workgroup name (note that's not >a question of SSO: win-client asks to type username and password). It seems >that maybe Samba is not handling new kerberos ticket requests. If Windows client is not a part of the domain, there is no SSO and no Kerberos. Windows client will attempt using NTLMSSP authentication. >By now, my questions are: >- Can this setup work or it is absolutely necessary that any Windows client >expecting to access Samba shares have to be already joined to a trusted >domain? Right now -- yes. You are saying you've following "FreeIPA's Samba integration guide" which I assume is http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA, which only works for Kerberos authentication because NTLMSSP is not supported by the SSSD. >- If this setup can't be done, I'll go for an LDAP config in file-server >against ipa-server, but then, can I maintain the file-server joined with >ipa-client? Will it work? Not really. The story is more complex than it seems and right now there is no ready-made solution for out-of-domain Windows clients. -- / Alexander Bokovoy From christopher.lamb at ch.ibm.com Thu May 7 05:39:24 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Thu, 7 May 2015 07:39:24 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: Message-ID: Hi Yes, it's possible to operate freeIPA and Samba as you suggest, we have been doing so for some years now (with several freeIPA and Samba versions). Our end users use a mix of Windows and OSX laptops / workstations. These are not members of any kind of domain. They access our file servers via Samba shares authenticated by freeIPA. The samba server is a freeIPA client. The samba config on the freeIPA side looks like it was done along the lines in the link http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ The ldap config in our samba smb.conf looks like this: security = user passdb backend = ldapsam:ldap://ldap.my.example.com ldap suffix = dc=my,dc=example,dc=com ldap admin dn = cn=Directory Manager ldap ssl = off Cheers Chris From: box 31978 To: freeipa-users at redhat.com Date: 06.05.2015 23:18 Subject: [Freeipa-users] freeipa-samba integration and windows clients Sent by: freeipa-users-bounces at redhat.com Hello everyone, These days I'm testing integration between FreeIPA4 and Samba4 at file sharing level. Everything seems to work fine except share access from a standalone Windows client. This is the setup (everything is up-to-date): - ipa-server: CentOS 7.1, ipa-server 4.1, ipa-server-trust-ad plugin - file-server: CentOS 7.1, ipa-client 4.1, samba 4.1 (sharing home dirs, not a DC) - win-client: Windows 7 Home Premium Config is done following the FreeIPA's Samba integration guide, and testing with samba-client from ipa-server (or any other ipa-joined machine) to file-server using kerberos after calling kinit is successful (file manipulation included). Attempts to connect to the same share from win-client ends up with a log in error. Analyzing logs: Samba can't find the user because it can't find any DC, and that's because Samba can't resolve workgroup name (note that's not a question of SSO: win-client asks to type username and password). It seems that maybe Samba is not handling new kerberos ticket requests. By now, my questions are: - Can this setup work or it is absolutely necessary that any Windows client expecting to access Samba shares have to be already joined to a trusted domain? - If this setup can't be done, I'll go for an LDAP config in file-server against ipa-server, but then, can I maintain the file-server joined with ipa-client? Will it work? Feel free to ask whatever you want, any suggestions will be welcome. Thanks! Regards, A.-- 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 From christoph.kaminski at biotronik.com Thu May 7 06:38:34 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Thu, 7 May 2015 08:38:34 +0200 Subject: [Freeipa-users] Antwort: RE: Known issues with IPA on VM? In-Reply-To: References: <960471ec49d743548a0e3d7a3657f11d@sib-ums03.Megafon.ru> Message-ID: > Just a guess, what is your deployment size? > We have a two ipa domains, one have 3 servers (2 hw and 1 vm, no > issues with dirsrv yet), another currently includes 16 vm servers, > ant dirsrv hangs and crashes periodically? > we have 8 IPA servers, 4 bare metal and 4 vm's. We see the crashes only on the vm's. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdh at dds.nl Thu May 7 07:31:17 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Thu, 07 May 2015 09:31:17 +0200 Subject: [Freeipa-users] External DNS Message-ID: <20150507093117.Horde.xBSVdmEwhY5VSxTFvAqV1JA@webmailnew.dds.nl> Hi all, One of the nice FreeIPA features is a host will be added to DNS automatically when the client is installed. However, in some situations using an other, external, DNS server is prefered. Now, this is possible but hosts have to added manually to this other DNS-server. Is it possible to handle DNS records by IPA on an external DNS server? Any future plans for this? Kind regards, Winfried ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 7 07:37:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 May 2015 09:37:40 +0200 Subject: [Freeipa-users] Using CNAME to point to different domain name In-Reply-To: References: Message-ID: <554B1644.4010308@redhat.com> On 06/05/15 22:28, Andrey Ptashnik wrote: > Hello Team, > > We are hosting a few servers at Amazon and using their Elastic Load > Balancing service that gives us a link to a load balancer in the > following format: > > webserver-1234567890.us-east-1.elb.amazonaws.com > > I was looking for a ways to implement a shorter alias using CNAME like: > > webserver.mydomain.com pointing to longer link from the load > balancer webserver-1234567890.us-west-2.elb.amazonaws.com > > Is there a way to do it in RHEL 7.1 with IPA server 4.1.0 using > different domain names? > > Regards, > > Andrey > > > Hello Andrey, If I understand correctly, IPA manages mydomain.com zone, so adding CNAME record should be simple: ipa dnsrecord-add mydomain.com webserver --cname-rec='webserver-1234567890.us-west-2.elb.amazonaws.com.' # <-- do not forget to add dot at the end If mydomain.com is managed outside IPA, the CNAME should be set on that external server, IPA cannot help in this case. Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu May 7 07:48:06 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 7 May 2015 10:48:06 +0300 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: <20150507052805.GY11785@redhat.com> Message-ID: <20150507074806.GZ11785@redhat.com> On Thu, 07 May 2015, box 31978 wrote: >Hello Alexander, > >Thank you very much for your answers! > >> If Windows client is not a part of the domain, there is no SSO and no >> Kerberos. Windows client will attempt using NTLMSSP authentication. >> ... >> Right now -- yes. You are saying you've following "FreeIPA's Samba >> integration guide" which I assume is >> http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA >, >> which only works for Kerberos authentication because NTLMSSP is not >> supported by the SSSD. > >Yes, your assumption is absolutely exact ;-) > >That's clear now, my thoughts went on this direction too: anyone is >handling a new kerberos ticket request because of authentication type. > >> Not really. The story is more complex than it seems and right now there >> is no ready-made solution for out-of-domain Windows clients. > >Ok, I understand. > >Then, I'd go for an LDAP approach pointing Samba to IPA's directory (this >works fine on Samba3 and 389-DS), but I'm not sure about the configuration. >Can file-server's SSSD have Kerberos auth (result of ipa-client-install) >and LDAP auth (added settings in sssd.conf) at the same time for the same >domain? Will it work together or will I've to choose on of the two? SSSD can but you need Samba to be aware of these things because Samba needs way more than just passwords. FreeIPA uses different LDAP schema for the additional attributes compared to what standard Samba PASSDB module for LDAP expects so if you enable that one in smb.conf, you'll get nothing. As Christoph pointed in the another email, you may try to enable older Samba-compatible scheme but that wouldn't play well with IPA's support for SIDs (including on SSSD side) as we are using different attributes and you'll be forced to maintain certain aspects manually. There is hope to get NTLMSSP support implemented but not soon, we have bits in place but there is still work to be done. -- / Alexander Bokovoy From tbordaz at redhat.com Thu May 7 07:59:17 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 07 May 2015 09:59:17 +0200 Subject: [Freeipa-users] more replication fun In-Reply-To: <554ADE5A.90801@gmail.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> Message-ID: <554B1B55.2000908@redhat.com> On 05/07/2015 05:39 AM, Janelle wrote: > On 5/6/15 8:12 PM, Vaclav Adamec wrote: >> Hi, >> Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode >> thread), if you are sure that's not any live replica server behind >> this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" >> >> Vasek >> >> >> On Thu, May 7, 2015 at 2:25 AM, Janelle >> wrote: >>> Hi again.. >>> >>> Seems to be an ongoing theme (replication). How does one remove these? >>> >>> unable to decode: {replica 9} 553ef80e000100090000 55402c39000000090000 >>> >>> I am hoping this is a stupid question with a really simple answer >>> that I am simply missing? >>> >>> ~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 project >> >> >> > Thank you Vasek, > > I am curious however. I have been running OpenLDAP configs with 20 or > more servers in replication for over 5 years. In all that time, I > think I have had replication issues 5 times. In the 6 months of > working with FreeIPA, replication issues are constant. From reading > the threads, I am not the only one in this predicament. Is there any > history on why replication is so problematic in FreeIPA? > > regards > ~J > Hi Janelle, This is a large question and I have no precise answer. My understanding of OpenLDAP replication vs RHDS replication is that it is not based on the same approach syncrepl vs replica_agreement. Both are working. Replication is complex and when I compare RHDS with others DS implementation using the same approach (replica_agreement) I can say that RHDS is doing a good job in terms of performance, stability and robustness. Replication is sensitive to administrative tasks, backup-restore, reinit, upgrade, schema update. This is possibly your case we have seen 'unable to decode' during upgrade/cleanruv and still investigating that bug. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu May 7 08:37:53 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 07 May 2015 10:37:53 +0200 Subject: [Freeipa-users] External DNS In-Reply-To: <20150507093117.Horde.xBSVdmEwhY5VSxTFvAqV1JA@webmailnew.dds.nl> References: <20150507093117.Horde.xBSVdmEwhY5VSxTFvAqV1JA@webmailnew.dds.nl> Message-ID: <554B2461.9040109@redhat.com> On 7.5.2015 09:31, Winfried de Heiden wrote: > Hi all, > > One of the nice FreeIPA features is a host will be added to DNS > automatically when the client is installed. However, in some situations > using an other, external, DNS server is prefered. Now, this is possible but > hosts have to added manually to this other DNS-server. > > Is it possible to handle DNS records by IPA on an external DNS server? Any > future plans for this? This automatic update is handled by SSSD and uses standard DNS update protocol. I.e. it should work as long as your 'external' DNS server is configured to accept updates from clients. Please refer to documentation to your DNS server for further information and let us know if you encounter some problem. Have a nice day! -- Petr^2 Spacek From christoph.kaminski at biotronik.com Thu May 7 08:46:27 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Thu, 7 May 2015 10:46:27 +0200 Subject: [Freeipa-users] Antwort: Re: more replication fun In-Reply-To: <554ADE5A.90801@gmail.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> Message-ID: > I am curious however. I have been running OpenLDAP configs with 20 or > more servers in replication for over 5 years. In all that time, I think > I have had replication issues 5 times. In the 6 months of working with > FreeIPA, replication issues are constant. From reading the threads, I am > not the only one in this predicament. Is there any history on why > replication is so problematic in FreeIPA? > same here... OpenLDAP no problems, since we use IPA we have ever replikation issues I think the replikation design is the problem. All IPA's are master. I think it would be more stable if there would be 1 Master and all replicas are read only. Greetz -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Thu May 7 09:00:25 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 07 May 2015 11:00:25 +0200 Subject: [Freeipa-users] Antwort: Re: more replication fun In-Reply-To: References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> Message-ID: <554B29A9.3040503@redhat.com> On 05/07/2015 10:46 AM, Christoph Kaminski wrote: > > I am curious however. I have been running OpenLDAP configs with 20 or > > more servers in replication for over 5 years. In all that time, I think > > I have had replication issues 5 times. In the 6 months of working with > > FreeIPA, replication issues are constant. From reading the threads, > I am > > not the only one in this predicament. Is there any history on why > > replication is so problematic in FreeIPA? > > > same here... OpenLDAP no problems, since we use IPA we have ever > replikation issues > > I think the replikation design is the problem. All IPA's are master. I > think it would be more stable if there would be 1 Master and all > replicas are read only. > > Greetz i don't think that the multimaster design is a problem in itself (it is complex and can make things complicated, yes).-As Thierry said, we have customers with large 389-ds deployments, with many million entries in the db, lots of mods and stable replication. The current issues with the RUVs seem to come from the dymanics of adding and removing replicas, which reveals new problems. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu May 7 09:13:21 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 7 May 2015 12:13:21 +0300 Subject: [Freeipa-users] Antwort: Re: more replication fun In-Reply-To: References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> Message-ID: <20150507091321.GA11785@redhat.com> On Thu, 07 May 2015, Christoph Kaminski wrote: >> I am curious however. I have been running OpenLDAP configs with 20 or >> more servers in replication for over 5 years. In all that time, I think >> I have had replication issues 5 times. In the 6 months of working with >> FreeIPA, replication issues are constant. From reading the threads, I am > >> not the only one in this predicament. Is there any history on why >> replication is so problematic in FreeIPA? >> >same here... OpenLDAP no problems, since we use IPA we have ever >replikation issues > >I think the replikation design is the problem. All IPA's are master. I >think it would be more stable if there would be 1 Master and all replicas >are read only. Replicas cannot be read only right now because this would mean Kerberos would be broken as every issued ticket means modification of the principal's LDAP entry to record account-related information for the successful and unsuccessful authentication. This is important to synchronize with other replicas because it also reflects lockout of accounts. You haven't experienced it with OpenLDAP-based LDAP clusters because most likely you did simply not use them to handle tasks like this, considering you were running read-only replicas. It is possible to run OpenLDAP in multi-master read-write setup as KDC backends, but you would need to use a different replication mechanism (delta-syncrepl). Delta-synchrepl would be similar to what 389-ds uses for replication and there are some related issues with it too, not really too different from what 389-ds experiences. However, I must add that to fix possible issues in 389-ds replication it is not enough to say 'we are experiencing issues in VM'. Please provide logs and detail of your configuration. It may well be that time drifts in VM cause more harm than actual replication protocol itself. -- / Alexander Bokovoy From jpazdziora at redhat.com Thu May 7 13:21:44 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 7 May 2015 15:21:44 +0200 Subject: [Freeipa-users] user-mod --rename and password Message-ID: <20150507132144.GA5887@redhat.com> Hello, I try to test renaming of user objects. I start with user bob and I'm able to kinit just fine: # echo BobPassword123 | kinit bob Password for bob at EXAMPLE.TEST: # I then rename the user: # echo Password123 | kinit admin Password for admin at EXAMPLE.TEST: # ipa user-mod --rename=bob1 bob ------------------------ Modified user "bob" ------------------------ User login: bob1 First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: bob at example.test UID: 251800001 GID: 251800001 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True And I try to kinit with the original password and it fails: # echo BobPassword123 | kinit bob1 Password for bob1 at EXAMPLE.TEST: kinit: Password incorrect while getting initial credentials # Then I rename the user back and the original password starts to work again: # echo Password123 | kinit admin Password for admin at EXAMPLE.TEST: # ipa user-mod --rename=bob bob1 -------------------- Modified user "bob1" -------------------- User login: bob First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: bob at example.test UID: 251800001 GID: 251800001 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True # echo BobPassword123 | kinit bob Password for bob at EXAMPLE.TEST: # Is this expected? It's with 4.1.0. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Thu May 7 13:38:37 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 7 May 2015 16:38:37 +0300 Subject: [Freeipa-users] user-mod --rename and password In-Reply-To: <20150507132144.GA5887@redhat.com> References: <20150507132144.GA5887@redhat.com> Message-ID: <20150507133837.GB11785@redhat.com> On Thu, 07 May 2015, Jan Pazdziora wrote: > >Hello, > >I try to test renaming of user objects. I start with user bob and I'm >able to kinit just fine: > > # echo BobPassword123 | kinit bob > Password for bob at EXAMPLE.TEST: > # > >I then rename the user: > > # echo Password123 | kinit admin > Password for admin at EXAMPLE.TEST: > # ipa user-mod --rename=bob1 bob > ------------------------ > Modified user "bob" > ------------------------ > User login: bob1 > First name: Robert > Last name: Chase > Home directory: /home/bob > Login shell: /bin/sh > Email address: bob at example.test > UID: 251800001 > GID: 251800001 > Account disabled: False > Password: True > Member of HBAC rule: allow_wikiapp > Kerberos keys available: True > >And I try to kinit with the original password and it fails: > > # echo BobPassword123 | kinit bob1 > Password for bob1 at EXAMPLE.TEST: > kinit: Password incorrect while getting initial credentials > # > >Then I rename the user back and the original password starts to work >again: > > # echo Password123 | kinit admin > Password for admin at EXAMPLE.TEST: > # ipa user-mod --rename=bob bob1 > -------------------- > Modified user "bob1" > -------------------- > User login: bob > First name: Robert > Last name: Chase > Home directory: /home/bob > Login shell: /bin/sh > Email address: bob at example.test > UID: 251800001 > GID: 251800001 > Account disabled: False > Password: True > Member of HBAC rule: allow_wikiapp > Kerberos keys available: True > # echo BobPassword123 | kinit bob > Password for bob at EXAMPLE.TEST: > # > >Is this expected? It's with 4.1.0. Yes, we have a bug for this, actually, few of them: https://fedorahosted.org/freeipa/ticket/4757 The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914 -- / Alexander Bokovoy From jpazdziora at redhat.com Thu May 7 13:47:38 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 7 May 2015 15:47:38 +0200 Subject: [Freeipa-users] user-mod --rename and password In-Reply-To: <20150507133837.GB11785@redhat.com> References: <20150507132144.GA5887@redhat.com> <20150507133837.GB11785@redhat.com> Message-ID: <20150507134738.GP6587@redhat.com> On Thu, May 07, 2015 at 04:38:37PM +0300, Alexander Bokovoy wrote: > > > >And I try to kinit with the original password and it fails: [...] > Yes, we have a bug for this, actually, few of them: > https://fedorahosted.org/freeipa/ticket/4757 > > The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914 Thank you! -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From rcritten at redhat.com Thu May 7 13:48:01 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 May 2015 09:48:01 -0400 Subject: [Freeipa-users] user-mod --rename and password In-Reply-To: <20150507133837.GB11785@redhat.com> References: <20150507132144.GA5887@redhat.com> <20150507133837.GB11785@redhat.com> Message-ID: <554B6D11.1020008@redhat.com> Alexander Bokovoy wrote: > On Thu, 07 May 2015, Jan Pazdziora wrote: >> >> Hello, >> >> I try to test renaming of user objects. I start with user bob and I'm >> able to kinit just fine: >> >> # echo BobPassword123 | kinit bob >> Password for bob at EXAMPLE.TEST: >> # >> >> I then rename the user: >> >> # echo Password123 | kinit admin >> Password for admin at EXAMPLE.TEST: >> # ipa user-mod --rename=bob1 bob >> ------------------------ >> Modified user "bob" >> ------------------------ >> User login: bob1 >> First name: Robert >> Last name: Chase >> Home directory: /home/bob >> Login shell: /bin/sh >> Email address: bob at example.test >> UID: 251800001 >> GID: 251800001 >> Account disabled: False >> Password: True >> Member of HBAC rule: allow_wikiapp >> Kerberos keys available: True >> >> And I try to kinit with the original password and it fails: >> >> # echo BobPassword123 | kinit bob1 >> Password for bob1 at EXAMPLE.TEST: >> kinit: Password incorrect while getting initial credentials >> # >> >> Then I rename the user back and the original password starts to work >> again: >> >> # echo Password123 | kinit admin >> Password for admin at EXAMPLE.TEST: >> # ipa user-mod --rename=bob bob1 >> -------------------- >> Modified user "bob1" >> -------------------- >> User login: bob >> First name: Robert >> Last name: Chase >> Home directory: /home/bob >> Login shell: /bin/sh >> Email address: bob at example.test >> UID: 251800001 >> GID: 251800001 >> Account disabled: False >> Password: True >> Member of HBAC rule: allow_wikiapp >> Kerberos keys available: True >> # echo BobPassword123 | kinit bob >> Password for bob at EXAMPLE.TEST: >> # >> >> Is this expected? It's with 4.1.0. > Yes, we have a bug for this, actually, few of them: > https://fedorahosted.org/freeipa/ticket/4757 > > The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914 > Well, in this case the principal isn't changed at all, it's still bob at EXAMPLE.TEST, which is why the password doesn't work. There probably is no bob1 principal anywhere. rob From abokovoy at redhat.com Thu May 7 14:01:33 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 7 May 2015 17:01:33 +0300 Subject: [Freeipa-users] user-mod --rename and password In-Reply-To: <554B6D11.1020008@redhat.com> References: <20150507132144.GA5887@redhat.com> <20150507133837.GB11785@redhat.com> <554B6D11.1020008@redhat.com> Message-ID: <20150507140133.GC11785@redhat.com> On Thu, 07 May 2015, Rob Crittenden wrote: >Alexander Bokovoy wrote: >> On Thu, 07 May 2015, Jan Pazdziora wrote: >>> >>> Hello, >>> >>> I try to test renaming of user objects. I start with user bob and I'm >>> able to kinit just fine: >>> >>> # echo BobPassword123 | kinit bob >>> Password for bob at EXAMPLE.TEST: >>> # >>> >>> I then rename the user: >>> >>> # echo Password123 | kinit admin >>> Password for admin at EXAMPLE.TEST: >>> # ipa user-mod --rename=bob1 bob >>> ------------------------ >>> Modified user "bob" >>> ------------------------ >>> User login: bob1 >>> First name: Robert >>> Last name: Chase >>> Home directory: /home/bob >>> Login shell: /bin/sh >>> Email address: bob at example.test >>> UID: 251800001 >>> GID: 251800001 >>> Account disabled: False >>> Password: True >>> Member of HBAC rule: allow_wikiapp >>> Kerberos keys available: True >>> >>> And I try to kinit with the original password and it fails: >>> >>> # echo BobPassword123 | kinit bob1 >>> Password for bob1 at EXAMPLE.TEST: >>> kinit: Password incorrect while getting initial credentials >>> # >>> >>> Then I rename the user back and the original password starts to work >>> again: >>> >>> # echo Password123 | kinit admin >>> Password for admin at EXAMPLE.TEST: >>> # ipa user-mod --rename=bob bob1 >>> -------------------- >>> Modified user "bob1" >>> -------------------- >>> User login: bob >>> First name: Robert >>> Last name: Chase >>> Home directory: /home/bob >>> Login shell: /bin/sh >>> Email address: bob at example.test >>> UID: 251800001 >>> GID: 251800001 >>> Account disabled: False >>> Password: True >>> Member of HBAC rule: allow_wikiapp >>> Kerberos keys available: True >>> # echo BobPassword123 | kinit bob >>> Password for bob at EXAMPLE.TEST: >>> # >>> >>> Is this expected? It's with 4.1.0. >> Yes, we have a bug for this, actually, few of them: >> https://fedorahosted.org/freeipa/ticket/4757 >> >> The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914 >> > >Well, in this case the principal isn't changed at all, it's still >bob at EXAMPLE.TEST, which is why the password doesn't work. There probably >is no bob1 principal anywhere. Yep, and there is a note in the first bug (#4757) about that. I think ipa user-mod should be doing that rename for krbPrincipalName too but we need to fix password generation via kadmin as well because chances are that users changed their passwords via SSSD which leads to kadmin use. -- / Alexander Bokovoy From devans01 at gmail.com Thu May 7 14:30:06 2015 From: devans01 at gmail.com (Dylan Evans) Date: Thu, 7 May 2015 15:30:06 +0100 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: <20150507074806.GZ11785@redhat.com> References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> Message-ID: By coincidence I posted a very similar question yesterday - https://www.redhat.com/archives/freeipa-users/2015-May/msg00103.html. +1 for the necessary support for out-of-domain Windows clients and NTLMSSP. Is there a time-table for this? Thanks, Dylan. On 7 May 2015 at 08:48, Alexander Bokovoy wrote: > On Thu, 07 May 2015, box 31978 wrote: >> >> Hello Alexander, >> >> Thank you very much for your answers! >> >>> If Windows client is not a part of the domain, there is no SSO and no >>> Kerberos. Windows client will attempt using NTLMSSP authentication. >>> ... >>> Right now -- yes. You are saying you've following "FreeIPA's Samba >>> integration guide" which I assume is >>> >>> http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA >> >> , >>> >>> which only works for Kerberos authentication because NTLMSSP is not >>> supported by the SSSD. >> >> >> Yes, your assumption is absolutely exact ;-) >> >> That's clear now, my thoughts went on this direction too: anyone is >> handling a new kerberos ticket request because of authentication type. >> >>> Not really. The story is more complex than it seems and right now there >>> is no ready-made solution for out-of-domain Windows clients. >> >> >> Ok, I understand. >> >> Then, I'd go for an LDAP approach pointing Samba to IPA's directory (this >> works fine on Samba3 and 389-DS), but I'm not sure about the >> configuration. >> Can file-server's SSSD have Kerberos auth (result of ipa-client-install) >> and LDAP auth (added settings in sssd.conf) at the same time for the same >> domain? Will it work together or will I've to choose on of the two? > > SSSD can but you need Samba to be aware of these things because Samba > needs way more than just passwords. FreeIPA uses different LDAP schema > for the additional attributes compared to what standard Samba PASSDB > module for LDAP expects so if you enable that one in smb.conf, you'll > get nothing. > > As Christoph pointed in the another email, you may try to enable older > Samba-compatible scheme but that wouldn't play well with IPA's support > for SIDs (including on SSSD side) as we are using different attributes > and you'll be forced to maintain certain aspects manually. > > There is hope to get NTLMSSP support implemented but not soon, we have > bits in place but there is still work to be done. > > -- > / 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 From nathan at nathanpeters.com Thu May 7 15:53:47 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 7 May 2015 08:53:47 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <554AAE82.8060204@redhat.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com><20150505163959.GV3267@p.redhat.com><20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> <554AAE82.8060204@redhat.com> Message-ID: > On 05/06/2015 12:14 AM, Nathan Peters wrote: >>> From this link : >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb >> >> >> The diagram in that section shows the client communicating with >> FreeIPA and FreeIPA contacting AD. >> >> So why are you saying the client authenticates with the AD DC directly? > > You are looking at the older documentation. It is for RHEL6. Please use > RHEL7.1 docs to get the latest info about 4.1 functionality. > Well according to the 7 docs here https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html it still shows in section 5.1.3.1 of that page that the sssd sends the request on behalf of the client and the client never directly connects to the AD dc. Both the 6 and 7 docs show the exact same diagram. From APtashnik at cccis.com Thu May 7 16:30:55 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Thu, 7 May 2015 16:30:55 +0000 Subject: [Freeipa-users] Using CNAME to point to different domain name In-Reply-To: <554B1644.4010308@redhat.com> References: <554B1644.4010308@redhat.com> Message-ID: <10136309-7911-40DD-B5C4-B3317DD0925A@cccis.com> Hi Martin, Thank you for a catch! I just noticed that I was missing the dot you mentioned! Regards, Andrey From: Martin Basti > Date: Thursday, May 7, 2015 at 2:37 AM To: Andrey Ptashnik >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Using CNAME to point to different domain name On 06/05/15 22:28, Andrey Ptashnik wrote: Hello Team, We are hosting a few servers at Amazon and using their Elastic Load Balancing service that gives us a link to a load balancer in the following format: webserver-1234567890.us-east-1.elb.amazonaws.com I was looking for a ways to implement a shorter alias using CNAME like: webserver.mydomain.com pointing to longer link from the load balancer webserver-1234567890.us-west-2.elb.amazonaws.com Is there a way to do it in RHEL 7.1 with IPA server 4.1.0 using different domain names? Regards, Andrey Hello Andrey, If I understand correctly, IPA manages mydomain.com zone, so adding CNAME record should be simple: ipa dnsrecord-add mydomain.com webserver --cname-rec='webserver-1234567890.us-west-2.elb.amazonaws.com.' # <-- do not forget to add dot at the end If mydomain.com is managed outside IPA, the CNAME should be set on that external server, IPA cannot help in this case. Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 7 16:32:28 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 May 2015 18:32:28 +0200 Subject: [Freeipa-users] Using CNAME to point to different domain name [SOLVED] In-Reply-To: <10136309-7911-40DD-B5C4-B3317DD0925A@cccis.com> References: <554B1644.4010308@redhat.com> <10136309-7911-40DD-B5C4-B3317DD0925A@cccis.com> Message-ID: <554B939C.7090503@redhat.com> On 07/05/15 18:30, Andrey Ptashnik wrote: > Hi Martin, > > Thank you for a catch! I just noticed that I was missing the dot you > mentioned! > > Regards, > > Andrey > > > From: Martin Basti > > Date: Thursday, May 7, 2015 at 2:37 AM > To: Andrey Ptashnik >, "freeipa-users at redhat.com > " > > Subject: Re: [Freeipa-users] Using CNAME to point to different domain name > > On 06/05/15 22:28, Andrey Ptashnik wrote: >> Hello Team, >> >> We are hosting a few servers at Amazon and using their Elastic Load >> Balancing service that gives us a link to a load balancer in the >> following format: >> >> webserver-1234567890.us-east-1.elb.amazonaws.com >> >> I was looking for a ways to implement a shorter alias using CNAME like: >> >> webserver.mydomain.com pointing to longer link from the load >> balancer webserver-1234567890.us-west-2.elb.amazonaws.com >> >> Is there a way to do it in RHEL 7.1 with IPA server 4.1.0 using >> different domain names? >> >> Regards, >> >> Andrey >> >> >> > Hello Andrey, > > If I understand correctly, IPA manages mydomain.com zone, so adding > CNAME record should be simple: > > ipa dnsrecord-add mydomain.com webserver > --cname-rec='webserver-1234567890.us-west-2.elb.amazonaws.com.' # <-- > do not forget to add dot at the end > > If mydomain.com is managed outside IPA, the CNAME should be set on > that external server, IPA cannot help in this case. > > Martin > -- > Martin Basti You are welcome. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu May 7 16:43:30 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 7 May 2015 18:43:30 +0200 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <6de84ca0250ed83df9c6ba0bf051ac6f.squirrel@webmail.nathanpeters.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> <20150506061248.GY3267@p.redhat.com> <6de84ca0250ed83df9c6ba0bf051ac6f.squirrel@webmail.nathanpeters.com> Message-ID: <20150507164330.GA6227@p.redhat.com> On Wed, May 06, 2015 at 11:15:15AM -0700, nathan at nathanpeters.com wrote: > Ok, I have attempted to set this up by adding the AD domain to my > configuration and it still isn't working. > I just want to confirm what I'm trying to accomplish here before I list > what I've done to troubleshoot this. > > We have an AD domain called corp.addomain.net. We have UPNs set so AD > users login to the AD domain as adusername at addomain.net when they login to > windows machines. > > The linux clients in our network are currently just using straight up > kerberos authentication against the domain and can currently login as > 'username' without entering any suffix. > > Because this means we can't control sudo policies centrally by our current > direct kerberos connection, we want to switch to logging in through > FreeIPA. > I need to be clear that we want to maintain the current logins of just > 'username' on Linux servers. > > To accomplish this, I added the following line to the sssd.conf file: > default_domain_suffix = corp.addomain.net > > I have tried 3 different combinations of kerberos config to try to get the > logins to work, but am running into errors in each case. I have tried to > follow the suggestions given earlier in this thread. Here are the 3 > krb.conf configurations I tried and the errors given on each try. > > -------------- configuration 1 ------------------- > > [realms] > IPADOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = > RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ > auth_to_local = DEFAULT > } > CORP.ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > [domain_realm] > .ipadomain.net = IPADOMAIN.NET > ipadomain.net = IPADOMAIN.NET > .corp.addomain.net = CORP.ADDOMAIN.NET > corp.addomain.net = CORP.ADDOMAIN.NET > > > May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot > find KDC for realm "ADDOMAIN.NET" > May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot > find KDC for realm "ADDOMAIN.NET" > May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=adusername > May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): received > for user adusername: 4 (System error) > May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for > adusername from 10.5.5.57 port 1832 ssh2 > > ----------- configuration 2 ---------------- > > Notes : since the above error seemed to imply that I needed to add the > 'UPN realm' to the [realms] section I tried to add it. > > [realms] > IPADOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = > RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ > auth_to_local = DEFAULT > > } > ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > [domain_realm] > .ipadomain.net = IPADOMAIN.NET > ipadomain.net = IPADOMAIN.NET > addomain.net = ADDOMAIN.NET > .addomain.net = ADDOMAIN.NET > > May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm > not local to KDC > May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm > not local to KDC hm, the AD DC requires that enterprise principal are used here, but we cannot enable them because as mentioned earlier the FreeIPA KDC currently does not support client referrals. Basically you are seeing the same as described in https://bugzilla.redhat.com/show_bug.cgi?id=1211631 . The userPrincipalName attribute in AD contains a value we currently cannot use. Unfortunately SSSD prefers this value if available and as described in the bugzilla tickets it is currently not possible to override the attribute name as well. There might be one ugly hack which might help you, but it is really ugly because you have to edit a executable file. The name of the attribute 'userPrincipalName' can be found exactly once in the IPA provider executable, you can check this with strings /usr/{lib|lib64}/sssd/libsss_ipa.so | grep userPrincipalName if you replace a single letter in this string with a different one, e.g. 'userPrinXipalName' in this file on all of your IPA servers and flush the cache on all servers with 'sss_cache -E' and restart sssd on the servers then SSSD should not be able anymore to read the attribute from AD and will generate a principal on its own based on the user name and the domain name which is corp.addomain.net in your case. With the principal it should be possible to authenticate against AD. But as said, this is really ugly, not supported and has to be done again at the next update. I'm sorry but currently I cannot think of a different way to make it work with the current versions of SSSD and IPA. bye, Sumit > May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=adusername > May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): received > for user adusername: 4 (System error) > May 06 16:48:34 dc1.ipadomain.net sshd[7542]: Failed password for > adusername from 10.5.5.57 port 1870 ssh2 > > ---- configuration 3 ----- > Notes : Since the eror message given in the second try indicated that the > realm wasn't local, I thought it might need both variations to recognize > it as local. > > [realms] > IPADOMAIN.NET = { > kdc = dc1.ipadomain.net:88 > master_kdc = dc1.ipadomain.net:88 > admin_server = dc1.ipadomain.net:749 > default_domain = ipadomain.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > CORP.ADDOMAIN.NET = { > kdc = dc3.corp.addomain.net:88 > master_kdc = dc3.corp.addomain.net:88 > } > > [domain_realm] > .ipadomain.net = IPADOMAIN.NET > ipadomain.net = IPADOMAIN.NET > addomain.net = ADDOMAIN.NET > .addomain.net = ADDOMAIN.NET > corp.addomain.net = CORP.ADDOMAIN.NET > .corp.addomain.net = CORP.ADDOMAIN.NET > > May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm > not local to KDC > May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm > not local to KDC > May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.5.5.57 user=adusername > May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): received > for user adusername: 4 (System error) > May 06 16:56:28 dc1.ipadomain.net sshd[7660]: Failed password for > adusername from 10.5.5.57 port 1964 ssh2 > > > > > If you want to look up user data like e.g. the UID or the home > > directory the IPA client will talk to the IPA server exclusively, if the > > server does not know about the requested AD user it will try to get this > > information from a AD DC. > > > > For authentication this is different, because only the AD DC should know > > the password of the user. Hence authentication ans password changes as > > well are done directly with the AD DC. > > > >> > >> Also this page here : > >> https://www.freeipa.org/page/Active_Directory_trust_setup > >> > >> does not list having to add the AD domain in the krb5.conf. Is that not > >> necessary in the example because they are not using a different UPN for > >> their users like we are? > > > > yes, it is because of the UPN in your case. As I said before this > > special entry in krb5.conf would not be needed anymore if the IPA KDC > > supports the Kerberos client referrals for the trusted domains. Adding > > the entry to krb5.conf in only a work-around here. > > > > bye, > > Sumit > > From dpal at redhat.com Thu May 7 17:07:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 07 May 2015 13:07:58 -0400 Subject: [Freeipa-users] External DNS In-Reply-To: <554B2461.9040109@redhat.com> References: <20150507093117.Horde.xBSVdmEwhY5VSxTFvAqV1JA@webmailnew.dds.nl> <554B2461.9040109@redhat.com> Message-ID: <554B9BEE.8060102@redhat.com> On 05/07/2015 04:37 AM, Petr Spacek wrote: > On 7.5.2015 09:31, Winfried de Heiden wrote: >> Hi all, >> >> One of the nice FreeIPA features is a host will be added to DNS >> automatically when the client is installed. However, in some situations >> using an other, external, DNS server is prefered. Now, this is possible but >> hosts have to added manually to this other DNS-server. >> >> Is it possible to handle DNS records by IPA on an external DNS server? Any >> future plans for this? > This automatic update is handled by SSSD and uses standard DNS update > protocol. I.e. it should work as long as your 'external' DNS server is > configured to accept updates from clients. This is the update not the creation. Will the update create both A/AAAA and PTR record? I thought that it will just update IP but not create these records. If I am correct then the question is valid and we need to have a way to create entries in an external data store. Sounds like another use case for the notification system. And for that we do not have firm plans yet but we are collecting the use cases to justify the effort. Martin do you think it is worth opening a ticket? > Please refer to documentation to your DNS server for further information and > let us know if you encounter some problem. > > Have a nice day! > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From nathan at nathanpeters.com Thu May 7 19:03:23 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 7 May 2015 12:03:23 -0700 Subject: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues In-Reply-To: <20150507164330.GA6227@p.redhat.com> References: <51596bc30ead216e43fb0f57270e68a9.squirrel@webmail.nathanpeters.com> <20150505163959.GV3267@p.redhat.com> <20150505182840.GW3267@p.redhat.com> <20150506034325.GD3722@hendrix.payandsurf.com> <302FDCEE7CCF419EAF07DD8CFD1970EB@Azul> <20150506061248.GY3267@p.redhat.com> <6de84ca0250ed83df9c6ba0bf051ac6f.squirrel@webmail.nathanpeters.com> <20150507164330.GA6227@p.redhat.com> Message-ID: > On Wed, May 06, 2015 at 11:15:15AM -0700, nathan at nathanpeters.com wrote: >> Ok, I have attempted to set this up by adding the AD domain to my >> configuration and it still isn't working. >> I just want to confirm what I'm trying to accomplish here before I list >> what I've done to troubleshoot this. >> >> We have an AD domain called corp.addomain.net. We have UPNs set so AD >> users login to the AD domain as adusername at addomain.net when they login >> to >> windows machines. >> >> The linux clients in our network are currently just using straight up >> kerberos authentication against the domain and can currently login as >> 'username' without entering any suffix. >> >> Because this means we can't control sudo policies centrally by our >> current >> direct kerberos connection, we want to switch to logging in through >> FreeIPA. >> I need to be clear that we want to maintain the current logins of just >> 'username' on Linux servers. >> >> To accomplish this, I added the following line to the sssd.conf file: >> default_domain_suffix = corp.addomain.net >> >> I have tried 3 different combinations of kerberos config to try to get >> the >> logins to work, but am running into errors in each case. I have tried >> to >> follow the suggestions given earlier in this thread. Here are the 3 >> krb.conf configurations I tried and the errors given on each try. >> >> -------------- configuration 1 ------------------- >> >> [realms] >> IPADOMAIN.NET = { >> kdc = dc1.ipadomain.net:88 >> master_kdc = dc1.ipadomain.net:88 >> admin_server = dc1.ipadomain.net:749 >> default_domain = ipadomain.net >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = >> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ >> auth_to_local = DEFAULT >> } >> CORP.ADDOMAIN.NET = { >> kdc = dc3.corp.addomain.net:88 >> master_kdc = dc3.corp.addomain.net:88 >> } >> >> [domain_realm] >> .ipadomain.net = IPADOMAIN.NET >> ipadomain.net = IPADOMAIN.NET >> .corp.addomain.net = CORP.ADDOMAIN.NET >> corp.addomain.net = CORP.ADDOMAIN.NET >> >> >> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot >> find KDC for realm "ADDOMAIN.NET" >> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot >> find KDC for realm "ADDOMAIN.NET" >> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.5.5.57 user=adusername >> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): >> received >> for user adusername: 4 (System error) >> May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for >> adusername from 10.5.5.57 port 1832 ssh2 >> >> ----------- configuration 2 ---------------- >> >> Notes : since the above error seemed to imply that I needed to add the >> 'UPN realm' to the [realms] section I tried to add it. >> >> [realms] >> IPADOMAIN.NET = { >> kdc = dc1.ipadomain.net:88 >> master_kdc = dc1.ipadomain.net:88 >> admin_server = dc1.ipadomain.net:749 >> default_domain = ipadomain.net >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = >> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/ >> auth_to_local = DEFAULT >> >> } >> ADDOMAIN.NET = { >> kdc = dc3.corp.addomain.net:88 >> master_kdc = dc3.corp.addomain.net:88 >> } >> >> [domain_realm] >> .ipadomain.net = IPADOMAIN.NET >> ipadomain.net = IPADOMAIN.NET >> addomain.net = ADDOMAIN.NET >> .addomain.net = ADDOMAIN.NET >> >> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm >> not local to KDC >> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm >> not local to KDC > > hm, the AD DC requires that enterprise principal are used here, but we > cannot enable them because as mentioned earlier the FreeIPA KDC > currently does not support client referrals. > > Basically you are seeing the same as described in > https://bugzilla.redhat.com/show_bug.cgi?id=1211631 . The > userPrincipalName attribute in AD contains a value we currently cannot > use. Unfortunately SSSD prefers this value if available and as described > in the bugzilla tickets it is currently not possible to override the > attribute name as well. > > There might be one ugly hack which might help you, but it is really ugly > because you have to edit a executable file. The name of the attribute > 'userPrincipalName' can be found exactly once in the IPA provider > executable, you can check this with > > strings /usr/{lib|lib64}/sssd/libsss_ipa.so | grep userPrincipalName > > if you replace a single letter in this string with a different one, e.g. > 'userPrinXipalName' in this file on all of your IPA servers and flush > the cache on all servers with 'sss_cache -E' and restart sssd on the > servers then SSSD should not be able anymore to read the attribute from > AD and will generate a principal on its own based on the user name and > the domain name which is corp.addomain.net in your case. With the > principal it should be possible to authenticate against AD. But as said, > this is really ugly, not supported and has to be done again at the next > update. > > I'm sorry but currently I cannot think of a different way to make it > work with the current versions of SSSD and IPA. > > bye, > Sumit Hey I tried to lookup that bug but after I logged in I got : "You are not authorized to access bug #1211631. Most likely the bug has been restricted for internal development processes and we cannot grant access." I think I found a workaround that is an even uglier hack but appears to work. Perhaps you could tell me why this is working? Basically, you make an entry for the UPN 'domain' in krb5.conf and give it servers that don't exist. I'm not sure why this is happening but here are the logs and proof of successful login by intentionally breaking kerberos. I have posted 2 attempts. The first uses a valid syntax but fails. The second attempt uses non-existent servers but actually works. Note that if I do not include either a real or fake upn section, it fails. Once again, I could probably use this hack, but I need to know why it works so I can be confident it won't break in the future. We will be doing this on several hundred machines. Failed attempt using a valid ADUPNALIAS.NET section ------------------------------------- /etc/krb5.conf extra realm section ADUPNALIAS.NET = { kdc = dc3.corp.addomain.net:88 master_kdc = c3.corp.addomain.net:88 default_domain = adupnalias.net } May 07 18:40:09 ipadc1.ipadomain.net sshd[2437]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=adusername May 07 18:40:10 ipadc1.ipadomain.net [sssd[krb5_child[2440]]][2440]: Realm not local to KDC May 07 18:40:10 ipadc1.ipadomain.net [sssd[krb5_child[2440]]][2440]: Realm not local to KDC May 07 18:40:10 ipadc1.ipadomain.net sshd[2437]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=adusername May 07 18:40:10 ipadc1.ipadomain.net sshd[2437]: pam_sss(sshd:auth): received for user adusername: 4 (System error) May 07 18:40:11 ipadc1.ipadomain.net sshd[2437]: Failed password for adusername from 10.5.5.57 port 18472 ssh2 Successful login using invalid ADUPNALIAS.NET section ------------------------------------- /etc/krb5.conf extra realm section ADUPNALIAS.NET = { kdc = someserverthatdoesnotexist.unreachabledomain.net:88 master_kdc = someserverthatdoesnotexist.unreachabledomain.net:88 default_domain = adupnalias.net } May 07 18:31:16 ipadc1.ipadomain.net sshd[2317]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=adusername May 07 18:31:17 ipadc1.ipadomain.net [sssd[krb5_child[2319]]][2319]: Cannot contact any KDC for realm 'ADUPNALIAS.NET' May 07 18:31:17 ipadc1.ipadomain.net [sssd[krb5_child[2319]]][2319]: Cannot contact any KDC for realm 'ADUPNALIAS.NET' May 07 18:31:17 ipadc1.ipadomain.net sshd[2317]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.5.5.57 user=adusername May 07 18:31:19 ipadc1.ipadomain.net sshd[2317]: Accepted password for adusername from 10.5.5.57 port 18346 ssh2 May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Starting user-1539201103.slice. May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Created slice user-1539201103.slice. May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Starting Session 4 of user adusername at corp.adupnalias.net. May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Started Session 4 of user adusername at corp.adupnalias.net. May 07 18:31:19 ipadc1.ipadomain.net systemd-logind[718]: New session 4 of user adusername at corp.adupnalias.net. May 07 18:31:19 ipadc1.ipadomain.net sshd[2317]: pam_unix(sshd:session): session opened for user adusername by (uid=0) From nagemnna at gmail.com Thu May 7 19:07:36 2015 From: nagemnna at gmail.com (Megan .) Date: Thu, 7 May 2015 15:07:36 -0400 Subject: [Freeipa-users] Host groups not working with SUDO Rules Message-ID: I'm having an issue where user's can't use sudo commands on ipa client hosts. I previously thought my issues with sudo were related to the type of commands, but I've narrowed it down to an issue with using host groups in the sudo rule access list instead of listing the hosts directly. When I use the host group with the host in it, my user cannot run the sudo commands on the host. I have multiple debugs on in my sssd.conf and I have a ton of log files but i'm not sure what will be useful in helping me troubleshoot. IPA client 3.0.0 Centos 6.6 To reproduce: Add in sudo command Create command group Create host group Add host into host group create sudo rule use user groups, host groups, and sudo command groups to create rule Go onto client server clear out /var/lib/sss/db restart sssd test sudo for a user in the user group Test will fail. If i do the same steps and just list the hosts for the sudo rule access, and not the host groups, the sudo commands works fine for the user. When i'm using host groups in the sssd_EXAMPLE.COM.log i see what looks like a successful check for the host in the host group. My hostgroup is uatcluster: (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [be_get_account_info] (0x0100): Got request for [4100][1][name=uatcluster] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] (0x0200): Found 3 expired group entries! i tried to recreate all of my host groups, and uninstall and reinstall the ipa client on one of my hosts. Nothing seems to fix the issue. I'm not really sure where to go from here. It took me 4 days to figure get this far. I'm only mostly sure this is the issue. Thanks in advance for any help. From dpal at redhat.com Thu May 7 19:15:34 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 07 May 2015 15:15:34 -0400 Subject: [Freeipa-users] Host groups not working with SUDO Rules In-Reply-To: References: Message-ID: <554BB9D6.5020109@redhat.com> On 05/07/2015 03:07 PM, Megan . wrote: > I'm having an issue where user's can't use sudo commands on ipa client > hosts. I previously thought my issues with sudo were related to the > type of commands, but I've narrowed it down to an issue with using > host groups in the sudo rule access list instead of listing the hosts > directly. When I use the host group with the host in it, my user > cannot run the sudo commands on the host. > > I have multiple debugs on in my sssd.conf and I have a ton of log > files but i'm not sure what will be useful in helping me troubleshoot. > > IPA client 3.0.0 > Centos 6.6 > > > To reproduce: > > Add in sudo command > Create command group > Create host group > Add host into host group > create sudo rule > use user groups, host groups, and sudo command groups to create rule > > Go onto client server > clear out /var/lib/sss/db > restart sssd > test sudo for a user in the user group > > Test will fail. > > If i do the same steps and just list the hosts for the sudo rule > access, and not the host groups, the sudo commands works fine for the > user. > > > When i'm using host groups in the sssd_EXAMPLE.COM.log i see what > looks like a successful check for the host in the host group. My > hostgroup is uatcluster: > > (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] > [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute > while id-mapping. [0][Success] > (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] > (0x0100): Request processed. Returned 0,0,Success > (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] > [be_get_account_info] (0x0100): Got request for > [4100][1][name=uatcluster] > (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] > (0x0100): Request processed. Returned 0,0,Success > (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] > (0x0200): Found 3 expired group entries! > > > i tried to recreate all of my host groups, and uninstall and reinstall > the ipa client on one of my hosts. Nothing seems to fix the issue. > I'm not really sure where to go from here. It took me 4 days to > figure get this far. I'm only mostly sure this is the issue. > > > Thanks in advance for any help. > What version are you using? This sounds familiar. I vaguely remember a bug being fixed in this area some time ago. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From box31978 at gmail.com Thu May 7 07:20:46 2015 From: box31978 at gmail.com (box 31978) Date: Thu, 7 May 2015 09:20:46 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: <20150507052805.GY11785@redhat.com> References: <20150507052805.GY11785@redhat.com> Message-ID: Hello Alexander, Thank you very much for your answers! > If Windows client is not a part of the domain, there is no SSO and no > Kerberos. Windows client will attempt using NTLMSSP authentication. > ... > Right now -- yes. You are saying you've following "FreeIPA's Samba > integration guide" which I assume is > http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA , > which only works for Kerberos authentication because NTLMSSP is not > supported by the SSSD. Yes, your assumption is absolutely exact ;-) That's clear now, my thoughts went on this direction too: anyone is handling a new kerberos ticket request because of authentication type. > Not really. The story is more complex than it seems and right now there > is no ready-made solution for out-of-domain Windows clients. Ok, I understand. Then, I'd go for an LDAP approach pointing Samba to IPA's directory (this works fine on Samba3 and 389-DS), but I'm not sure about the configuration. Can file-server's SSSD have Kerberos auth (result of ipa-client-install) and LDAP auth (added settings in sssd.conf) at the same time for the same domain? Will it work together or will I've to choose on of the two? Thank you! Regards, A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From box31978 at gmail.com Thu May 7 07:32:28 2015 From: box31978 at gmail.com (box 31978) Date: Thu, 7 May 2015 09:32:28 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: Message-ID: Hello Chris, And thank you too for your answers! > Our end users use a mix of Windows and OSX laptops / workstations. These > are not members of any kind of domain. They access our file servers via > Samba shares authenticated by freeIPA. > The samba server is a freeIPA client. > The samba config on the freeIPA side looks like it was done along the lines > in the link > http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ > The ldap config in our samba smb.conf looks like this: > security = user > passdb backend = ldapsam:ldap://ldap.my.example.com > ldap suffix = dc=my,dc=example,dc=com > ldap admin dn = cn=Directory Manager > ldap ssl = off That's interesting: Samba as an IPA client and resolving via LDAP, what about sssd.conf? I already know the link (and I don't like very much patching the code), but it won't be needed anymore since ?ipa-server-trust-ad? is out, right? Thanks and cheers! A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From box31978 at gmail.com Thu May 7 10:06:30 2015 From: box31978 at gmail.com (box 31978) Date: Thu, 7 May 2015 12:06:30 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: <20150507074806.GZ11785@redhat.com> References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> Message-ID: Hi Alexander, Thank you very much for all that precious information. > SSSD can but you need Samba to be aware of these things because Samba > needs way more than just passwords. FreeIPA uses different LDAP schema > for the additional attributes compared to what standard Samba PASSDB > module for LDAP expects so if you enable that one in smb.conf, you'll > get nothing. You're absolutely correct. Just after mailing you, I've been testing it and Samba can successfully connect to IPA's LDAP but didn't find password's backend. > As Christoph pointed in the another email, you may try to enable older > Samba-compatible scheme but that wouldn't play well with IPA's support > for SIDs (including on SSSD side) as we are using different attributes > and you'll be forced to maintain certain aspects manually. Then, I'd go for a straight-forward 389-DS instance with Samba schema and authenticate other servers and clients against it via LDAP + TLS over SSSD. I've got this setup running on production systems and works flawlessly for a couple of years now. I don't like very much patching here and there, and then having to fight with upstream updates that can broke something. Everything must (almost) work out of the box. > There is hope to get NTLMSSP support implemented but not soon, we have > bits in place but there is still work to be done. Your work with IPA is absolutely awesome. I follow the project from early versions and I'm a big proponent of moving to from my classic LDAP approach. I think IPA is the way to go for further deployments, but I understand that mixed environments (as mine) are complicated to solve: lots of work and many things that can be problematic. Again, thank you very much. Regards, A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu May 7 19:43:01 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 May 2015 15:43:01 -0400 Subject: [Freeipa-users] Host groups not working with SUDO Rules In-Reply-To: <554BB9D6.5020109@redhat.com> References: <554BB9D6.5020109@redhat.com> Message-ID: <554BC045.7040808@redhat.com> Dmitri Pal wrote: > On 05/07/2015 03:07 PM, Megan . wrote: >> I'm having an issue where user's can't use sudo commands on ipa client >> hosts. I previously thought my issues with sudo were related to the >> type of commands, but I've narrowed it down to an issue with using >> host groups in the sudo rule access list instead of listing the hosts >> directly. When I use the host group with the host in it, my user >> cannot run the sudo commands on the host. >> >> I have multiple debugs on in my sssd.conf and I have a ton of log >> files but i'm not sure what will be useful in helping me troubleshoot. >> >> IPA client 3.0.0 >> Centos 6.6 >> >> >> To reproduce: >> >> Add in sudo command >> Create command group >> Create host group >> Add host into host group >> create sudo rule >> use user groups, host groups, and sudo command groups to create rule >> >> Go onto client server >> clear out /var/lib/sss/db >> restart sssd >> test sudo for a user in the user group >> >> Test will fail. >> >> If i do the same steps and just list the hosts for the sudo rule >> access, and not the host groups, the sudo commands works fine for the >> user. >> >> >> When i'm using host groups in the sssd_EXAMPLE.COM.log i see what >> looks like a successful check for the host in the host group. My >> hostgroup is uatcluster: >> >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >> domain SID from [(null)] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute >> while id-mapping. [0][Success] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >> domain SID from [(null)] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >> (0x0100): Request processed. Returned 0,0,Success >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [be_get_account_info] (0x0100): Got request for >> [4100][1][name=uatcluster] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >> (0x0100): Request processed. Returned 0,0,Success >> (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] >> (0x0200): Found 3 expired group entries! >> >> >> i tried to recreate all of my host groups, and uninstall and reinstall >> the ipa client on one of my hosts. Nothing seems to fix the issue. >> I'm not really sure where to go from here. It took me 4 days to >> figure get this far. I'm only mostly sure this is the issue. >> >> >> Thanks in advance for any help. >> > > What version are you using? > This sounds familiar. I vaguely remember a bug being fixed in this area > some time ago. > Make sure nisdomainname is set to your domain. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/sudo.html#sudo-nis rob From simo at redhat.com Thu May 7 19:43:45 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 07 May 2015 15:43:45 -0400 Subject: [Freeipa-users] user-mod --rename and password In-Reply-To: <20150507140133.GC11785@redhat.com> References: <20150507132144.GA5887@redhat.com> <20150507133837.GB11785@redhat.com> <554B6D11.1020008@redhat.com> <20150507140133.GC11785@redhat.com> Message-ID: <1431027825.10241.13.camel@willson.usersys.redhat.com> On Thu, 2015-05-07 at 17:01 +0300, Alexander Bokovoy wrote: > On Thu, 07 May 2015, Rob Crittenden wrote: > >Alexander Bokovoy wrote: > >> On Thu, 07 May 2015, Jan Pazdziora wrote: > >>> > >>> Hello, > >>> > >>> I try to test renaming of user objects. I start with user bob and I'm > >>> able to kinit just fine: > >>> > >>> # echo BobPassword123 | kinit bob > >>> Password for bob at EXAMPLE.TEST: > >>> # > >>> > >>> I then rename the user: > >>> > >>> # echo Password123 | kinit admin > >>> Password for admin at EXAMPLE.TEST: > >>> # ipa user-mod --rename=bob1 bob > >>> ------------------------ > >>> Modified user "bob" > >>> ------------------------ > >>> User login: bob1 > >>> First name: Robert > >>> Last name: Chase > >>> Home directory: /home/bob > >>> Login shell: /bin/sh > >>> Email address: bob at example.test > >>> UID: 251800001 > >>> GID: 251800001 > >>> Account disabled: False > >>> Password: True > >>> Member of HBAC rule: allow_wikiapp > >>> Kerberos keys available: True > >>> > >>> And I try to kinit with the original password and it fails: > >>> > >>> # echo BobPassword123 | kinit bob1 > >>> Password for bob1 at EXAMPLE.TEST: > >>> kinit: Password incorrect while getting initial credentials > >>> # > >>> > >>> Then I rename the user back and the original password starts to work > >>> again: > >>> > >>> # echo Password123 | kinit admin > >>> Password for admin at EXAMPLE.TEST: > >>> # ipa user-mod --rename=bob bob1 > >>> -------------------- > >>> Modified user "bob1" > >>> -------------------- > >>> User login: bob > >>> First name: Robert > >>> Last name: Chase > >>> Home directory: /home/bob > >>> Login shell: /bin/sh > >>> Email address: bob at example.test > >>> UID: 251800001 > >>> GID: 251800001 > >>> Account disabled: False > >>> Password: True > >>> Member of HBAC rule: allow_wikiapp > >>> Kerberos keys available: True > >>> # echo BobPassword123 | kinit bob > >>> Password for bob at EXAMPLE.TEST: > >>> # > >>> > >>> Is this expected? It's with 4.1.0. > >> Yes, we have a bug for this, actually, few of them: > >> https://fedorahosted.org/freeipa/ticket/4757 > >> > >> The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914 > >> > > > >Well, in this case the principal isn't changed at all, it's still > >bob at EXAMPLE.TEST, which is why the password doesn't work. There probably > >is no bob1 principal anywhere. > Yep, and there is a note in the first bug (#4757) about that. I think > ipa user-mod should be doing that rename for krbPrincipalName too but we > need to fix password generation via kadmin as well because chances are > that users changed their passwords via SSSD which leads to kadmin use. Patch to fix this is sitting in the fedora-devel list for a month or so, please review and ack it. Simo. -- Simo Sorce * Red Hat, Inc * New York From nagemnna at gmail.com Fri May 8 00:00:50 2015 From: nagemnna at gmail.com (Megan .) Date: Thu, 7 May 2015 20:00:50 -0400 Subject: [Freeipa-users] Host groups not working with SUDO Rules In-Reply-To: <554BB9D6.5020109@redhat.com> References: <554BB9D6.5020109@redhat.com> Message-ID: On the server I am running CentOS release 6.6 (Final) with: sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 sudo-1.8.6p3-15.el6.x86_64 On the clients I'm running CentOS release 6.6 (Final): sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 sudo-1.8.6p3-15.el6.x86_64 On Thu, May 7, 2015 at 3:15 PM, Dmitri Pal wrote: > On 05/07/2015 03:07 PM, Megan . wrote: >> >> I'm having an issue where user's can't use sudo commands on ipa client >> hosts. I previously thought my issues with sudo were related to the >> type of commands, but I've narrowed it down to an issue with using >> host groups in the sudo rule access list instead of listing the hosts >> directly. When I use the host group with the host in it, my user >> cannot run the sudo commands on the host. >> >> I have multiple debugs on in my sssd.conf and I have a ton of log >> files but i'm not sure what will be useful in helping me troubleshoot. >> >> IPA client 3.0.0 >> Centos 6.6 >> >> >> To reproduce: >> >> Add in sudo command >> Create command group >> Create host group >> Add host into host group >> create sudo rule >> use user groups, host groups, and sudo command groups to create rule >> >> Go onto client server >> clear out /var/lib/sss/db >> restart sssd >> test sudo for a user in the user group >> >> Test will fail. >> >> If i do the same steps and just list the hosts for the sudo rule >> access, and not the host groups, the sudo commands works fine for the >> user. >> >> >> When i'm using host groups in the sssd_EXAMPLE.COM.log i see what >> looks like a successful check for the host in the host group. My >> hostgroup is uatcluster: >> >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >> domain SID from [(null)] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute >> while id-mapping. [0][Success] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >> domain SID from [(null)] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >> (0x0100): Request processed. Returned 0,0,Success >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >> [be_get_account_info] (0x0100): Got request for >> [4100][1][name=uatcluster] >> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >> (0x0100): Request processed. Returned 0,0,Success >> (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] >> (0x0200): Found 3 expired group entries! >> >> >> i tried to recreate all of my host groups, and uninstall and reinstall >> the ipa client on one of my hosts. Nothing seems to fix the issue. >> I'm not really sure where to go from here. It took me 4 days to >> figure get this far. I'm only mostly sure this is the issue. >> >> >> Thanks in advance for any help. >> > > What version are you using? > This sounds familiar. I vaguely remember a bug being fixed in this area some > time ago. > > -- > Thank you, > Dmitri Pal > > Director of Engineering for 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 From nagemnna at gmail.com Fri May 8 00:15:09 2015 From: nagemnna at gmail.com (Megan .) Date: Thu, 7 May 2015 20:15:09 -0400 Subject: [Freeipa-users] Host groups not working with SUDO Rules In-Reply-To: <554BC045.7040808@redhat.com> References: <554BB9D6.5020109@redhat.com> <554BC045.7040808@redhat.com> Message-ID: Thank you for the link. I had the nisdomainname set to the hostname of the directory server. I changed it to the domain (example.com instead of dir1.example.com) and that seems to have corrected my issue. Thank you so much! I have it set in /etc/rc.d/rc.local so that it comes up on boot but i was reading that setting NISDOMAIN in /etc/sysconfig/network might be a better place for it. Are there any pros/cons? On Thu, May 7, 2015 at 3:43 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 05/07/2015 03:07 PM, Megan . wrote: >>> I'm having an issue where user's can't use sudo commands on ipa client >>> hosts. I previously thought my issues with sudo were related to the >>> type of commands, but I've narrowed it down to an issue with using >>> host groups in the sudo rule access list instead of listing the hosts >>> directly. When I use the host group with the host in it, my user >>> cannot run the sudo commands on the host. >>> >>> I have multiple debugs on in my sssd.conf and I have a ton of log >>> files but i'm not sure what will be useful in helping me troubleshoot. >>> >>> IPA client 3.0.0 >>> Centos 6.6 >>> >>> >>> To reproduce: >>> >>> Add in sudo command >>> Create command group >>> Create host group >>> Add host into host group >>> create sudo rule >>> use user groups, host groups, and sudo command groups to create rule >>> >>> Go onto client server >>> clear out /var/lib/sss/db >>> restart sssd >>> test sudo for a user in the user group >>> >>> Test will fail. >>> >>> If i do the same steps and just list the hosts for the sudo rule >>> access, and not the host groups, the sudo commands works fine for the >>> user. >>> >>> >>> When i'm using host groups in the sssd_EXAMPLE.COM.log i see what >>> looks like a successful check for the host in the host group. My >>> hostgroup is uatcluster: >>> >>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >>> domain SID from [(null)] >>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>> [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute >>> while id-mapping. [0][Success] >>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >>> domain SID from [(null)] >>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >>> (0x0100): Request processed. Returned 0,0,Success >>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>> [be_get_account_info] (0x0100): Got request for >>> [4100][1][name=uatcluster] >>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >>> (0x0100): Request processed. Returned 0,0,Success >>> (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] >>> (0x0200): Found 3 expired group entries! >>> >>> >>> i tried to recreate all of my host groups, and uninstall and reinstall >>> the ipa client on one of my hosts. Nothing seems to fix the issue. >>> I'm not really sure where to go from here. It took me 4 days to >>> figure get this far. I'm only mostly sure this is the issue. >>> >>> >>> Thanks in advance for any help. >>> >> >> What version are you using? >> This sounds familiar. I vaguely remember a bug being fixed in this area >> some time ago. >> > > Make sure nisdomainname is set to your domain. > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/sudo.html#sudo-nis > > 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 From rcritten at redhat.com Fri May 8 02:25:43 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 May 2015 22:25:43 -0400 Subject: [Freeipa-users] Host groups not working with SUDO Rules In-Reply-To: References: <554BB9D6.5020109@redhat.com> <554BC045.7040808@redhat.com> Message-ID: <554C1EA7.3030107@redhat.com> Megan . wrote: > Thank you for the link. I had the nisdomainname set to the hostname > of the directory server. I changed it to the domain (example.com > instead of dir1.example.com) and that seems to have corrected my > issue. Thank you so much! > > I have it set in /etc/rc.d/rc.local so that it comes up on boot but i > was reading that setting NISDOMAIN in /etc/sysconfig/network might be > a better place for it. Are there any pros/cons? /etc/sysconfig/network is probably the proper place to add it as other tools that use NIS may look there (authconfig, for example). I doubt, but can't guarantee, that rc.local would be just as effective though. Given that there is already machinery to set it based on the config file though, I'd lean towards that myself. rob > > > > On Thu, May 7, 2015 at 3:43 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 05/07/2015 03:07 PM, Megan . wrote: >>>> I'm having an issue where user's can't use sudo commands on ipa client >>>> hosts. I previously thought my issues with sudo were related to the >>>> type of commands, but I've narrowed it down to an issue with using >>>> host groups in the sudo rule access list instead of listing the hosts >>>> directly. When I use the host group with the host in it, my user >>>> cannot run the sudo commands on the host. >>>> >>>> I have multiple debugs on in my sssd.conf and I have a ton of log >>>> files but i'm not sure what will be useful in helping me troubleshoot. >>>> >>>> IPA client 3.0.0 >>>> Centos 6.6 >>>> >>>> >>>> To reproduce: >>>> >>>> Add in sudo command >>>> Create command group >>>> Create host group >>>> Add host into host group >>>> create sudo rule >>>> use user groups, host groups, and sudo command groups to create rule >>>> >>>> Go onto client server >>>> clear out /var/lib/sss/db >>>> restart sssd >>>> test sudo for a user in the user group >>>> >>>> Test will fail. >>>> >>>> If i do the same steps and just list the hosts for the sudo rule >>>> access, and not the host groups, the sudo commands works fine for the >>>> user. >>>> >>>> >>>> When i'm using host groups in the sssd_EXAMPLE.COM.log i see what >>>> looks like a successful check for the host in the host group. My >>>> hostgroup is uatcluster: >>>> >>>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>>> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >>>> domain SID from [(null)] >>>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>>> [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute >>>> while id-mapping. [0][Success] >>>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>>> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >>>> domain SID from [(null)] >>>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >>>> (0x0100): Request processed. Returned 0,0,Success >>>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] >>>> [be_get_account_info] (0x0100): Got request for >>>> [4100][1][name=uatcluster] >>>> (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] >>>> (0x0100): Request processed. Returned 0,0,Success >>>> (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] >>>> (0x0200): Found 3 expired group entries! >>>> >>>> >>>> i tried to recreate all of my host groups, and uninstall and reinstall >>>> the ipa client on one of my hosts. Nothing seems to fix the issue. >>>> I'm not really sure where to go from here. It took me 4 days to >>>> figure get this far. I'm only mostly sure this is the issue. >>>> >>>> >>>> Thanks in advance for any help. >>>> >>> >>> What version are you using? >>> This sounds familiar. I vaguely remember a bug being fixed in this area >>> some time ago. >>> >> >> Make sure nisdomainname is set to your domain. >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/sudo.html#sudo-nis >> >> 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 From Andy.Thompson at e-tcc.com Fri May 8 12:04:36 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 8 May 2015 12:04:36 +0000 Subject: [Freeipa-users] multi homed environment Message-ID: I'm trying to roll out IPA in an existing windows environment where everything is multi homed. I did not put my IPA server on all the subnets. I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code "-1073741801", message "Memory allocation error" (both may be "None") DNS I think since it round robins all the existing A records and is returning IPs out of the local subnet. I don't know much about windows dns services but it's got netmask optimization enabled and doing digs against the service returns the local IP first every time, but pings return them in any order. I've considered adding the DCs to the local hosts file but I'm not sure if that will solve the problem or not. Is that a viable fix? Anyone have any experience in an environment like this? Really not sure what additional problems I will run into with all this multi homed nonsense. *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From lkrispen at redhat.com Fri May 8 12:12:31 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 08 May 2015 14:12:31 +0200 Subject: [Freeipa-users] Antwort: RE: Known issues with IPA on VM? In-Reply-To: References: <960471ec49d743548a0e3d7a3657f11d@sib-ums03.Megafon.ru> Message-ID: <554CA82F.4010902@redhat.com> On 05/07/2015 08:38 AM, Christoph Kaminski wrote: > > Just a guess, what is your deployment size? > > We have a two ipa domains, one have 3 servers (2 hw and 1 vm, no > > issues with dirsrv yet), another currently includes 16 vm servers, > > ant dirsrv hangs and crashes periodically... > > > > we have 8 IPA servers, 4 bare metal and 4 vm's. We see the crashes > only on the vm's. > > > > yes, there have been several reports about problems on VMs, but as Martin and Rich said for investigation we need some data about the crashes -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri May 8 12:16:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 8 May 2015 15:16:53 +0300 Subject: [Freeipa-users] multi homed environment In-Reply-To: References: Message-ID: <20150508121653.GJ11785@redhat.com> On Fri, 08 May 2015, Andy Thompson wrote: >I'm trying to roll out IPA in an existing windows environment where >everything is multi homed. I did not put my IPA server on all the >subnets. > >I'm having an issue with adding a trust to the domain with the error >below > >ipa: ERROR: CIFS server communication error: code "-1073741801", > message "Memory allocation error" (both may be "None") > >DNS I think since it round robins all the existing A records and is >returning IPs out of the local subnet. I don't know much about windows >dns services but it's got netmask optimization enabled and doing digs >against the service returns the local IP first every time, but pings >return them in any order. > >I've considered adding the DCs to the local hosts file but I'm not sure >if that will solve the problem or not. Is that a viable fix? > >Anyone have any experience in an environment like this? Really not >sure what additional problems I will run into with all this multi homed >nonsense. Stop here and make sure you obtained the debugging information as described in http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust Without that information it is hard to tell what is happening. Make also sure to tell exact environment (distribution, version, package versions, etc). -- / Alexander Bokovoy From andrew.holway at gmail.com Fri May 8 12:18:35 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 8 May 2015 14:18:35 +0200 Subject: [Freeipa-users] Known issues with IPA on VM? In-Reply-To: References: Message-ID: > > (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) > Are you using ECC memory? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Fri May 8 13:15:56 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 8 May 2015 13:15:56 +0000 Subject: [Freeipa-users] multi homed environment In-Reply-To: <20150508121653.GJ11785@redhat.com> References: <20150508121653.GJ11785@redhat.com> Message-ID: <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Friday, May 8, 2015 8:17 AM > To: Andy Thompson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] multi homed environment > > On Fri, 08 May 2015, Andy Thompson wrote: > >I'm trying to roll out IPA in an existing windows environment where > >everything is multi homed. I did not put my IPA server on all the > >subnets. > > > >I'm having an issue with adding a trust to the domain with the error > >below > > > >ipa: ERROR: CIFS server communication error: code "-1073741801", > > message "Memory allocation error" (both may be > >"None") > > > >DNS I think since it round robins all the existing A records and is > >returning IPs out of the local subnet. I don't know much about windows > >dns services but it's got netmask optimization enabled and doing digs > >against the service returns the local IP first every time, but pings > >return them in any order. > > > >I've considered adding the DCs to the local hosts file but I'm not sure > >if that will solve the problem or not. Is that a viable fix? > > > >Anyone have any experience in an environment like this? Really not > >sure what additional problems I will run into with all this multi homed > >nonsense. > Stop here and make sure you obtained the debugging information as > described in > http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tru > st > > Without that information it is hard to tell what is happening. > > Make also sure to tell exact environment (distribution, version, package > versions, etc). > Well things got ugly. I enabled debug and pointed in the right direction, smb failed to start. Came down to the cifs service was not added when I did the adtrust-install. I tried adding it and it complained that it could not find the A record for the host even though it was there. Thinking something was hung up in resolver cache possibly I restarted the ipa service and it failed completely. Ipactl start fails starting smb because of the missing service and everything fails from there. Is there any way to recover from this mess I just made? :) thanks From christoph.kaminski at biotronik.com Fri May 8 13:27:15 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Fri, 8 May 2015 15:27:15 +0200 Subject: [Freeipa-users] Antwort: Re: Known issues with IPA on VM? In-Reply-To: References: Message-ID: Andrew Holway schrieb am 08.05.2015 14:18:35: > Von: Andrew Holway > An: Christoph Kaminski > Kopie: Freeipa-users > Datum: 08.05.2015 14:18 > Betreff: Re: [Freeipa-users] Known issues with IPA on VM? > > (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) > > Are you using ECC memory? it is a 19" IBM server, enterprise hardware (AFAIK it have ever ECC memory) Greetz Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri May 8 13:39:40 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 8 May 2015 16:39:40 +0300 Subject: [Freeipa-users] multi homed environment In-Reply-To: <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> References: <20150508121653.GJ11785@redhat.com> <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> Message-ID: <20150508133940.GN11785@redhat.com> On Fri, 08 May 2015, Andy Thompson wrote: >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Friday, May 8, 2015 8:17 AM >> To: Andy Thompson >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] multi homed environment >> >> On Fri, 08 May 2015, Andy Thompson wrote: >> >I'm trying to roll out IPA in an existing windows environment where >> >everything is multi homed. I did not put my IPA server on all the >> >subnets. >> > >> >I'm having an issue with adding a trust to the domain with the error >> >below >> > >> >ipa: ERROR: CIFS server communication error: code "-1073741801", >> > message "Memory allocation error" (both may be >> >"None") >> > >> >DNS I think since it round robins all the existing A records and is >> >returning IPs out of the local subnet. I don't know much about windows >> >dns services but it's got netmask optimization enabled and doing digs >> >against the service returns the local IP first every time, but pings >> >return them in any order. >> > >> >I've considered adding the DCs to the local hosts file but I'm not sure >> >if that will solve the problem or not. Is that a viable fix? >> > >> >Anyone have any experience in an environment like this? Really not >> >sure what additional problems I will run into with all this multi homed >> >nonsense. >> Stop here and make sure you obtained the debugging information as >> described in >> http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tru >> st >> >> Without that information it is hard to tell what is happening. >> >> Make also sure to tell exact environment (distribution, version, package >> versions, etc). >> > >Well things got ugly. I enabled debug and pointed in the right >direction, smb failed to start. Came down to the cifs service was not >added when I did the adtrust-install. I tried adding it and it >complained that it could not find the A record for the host even though >it was there. Thinking something was hung up in resolver cache >possibly I restarted the ipa service and it failed completely. > >Ipactl start fails starting smb because of the missing service and >everything fails from there. > >Is there any way to recover from this mess I just made? :) I assume you have IPA 4.x, i.e. systemd-based environment. 1. Start manually dirsrv at INSTANCE-NAME.service 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. Note that you SHOULD NOT replace $FOO variables below, they should be as specified in the resulting file. For ipa-ldap-updater use see its manual page and my blog: https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ # cat 88-disable-adtrust-extid.update dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService END # ipa-ldap-updater -l ./88-disable-adtrust-extid.update 3. Restart IPA 4. Re-run ipa-adtrust-install and look at the output, including what it appends to /var/log/ipaserver-install.log. -- / Alexander Bokovoy From Andy.Thompson at e-tcc.com Fri May 8 14:05:24 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 8 May 2015 14:05:24 +0000 Subject: [Freeipa-users] multi homed environment In-Reply-To: <20150508133940.GN11785@redhat.com> References: <20150508121653.GJ11785@redhat.com> <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> <20150508133940.GN11785@redhat.com> Message-ID: > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Friday, May 8, 2015 9:40 AM > To: Andy Thompson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] multi homed environment > > On Fri, 08 May 2015, Andy Thompson wrote: > >> -----Original Message----- > >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > >> Sent: Friday, May 8, 2015 8:17 AM > >> To: Andy Thompson > >> Cc: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] multi homed environment > >> > >> On Fri, 08 May 2015, Andy Thompson wrote: > >> >I'm trying to roll out IPA in an existing windows environment where > >> >everything is multi homed. I did not put my IPA server on all the > >> >subnets. > >> > > >> >I'm having an issue with adding a trust to the domain with the error > >> >below > >> > > >> >ipa: ERROR: CIFS server communication error: code "-1073741801", > >> > message "Memory allocation error" (both may be > >> >"None") > >> > > >> >DNS I think since it round robins all the existing A records and is > >> >returning IPs out of the local subnet. I don't know much about > >> >windows dns services but it's got netmask optimization enabled and > >> >doing digs against the service returns the local IP first every > >> >time, but pings return them in any order. > >> > > >> >I've considered adding the DCs to the local hosts file but I'm not > >> >sure if that will solve the problem or not. Is that a viable fix? > >> > > >> >Anyone have any experience in an environment like this? Really not > >> >sure what additional problems I will run into with all this multi > >> >homed nonsense. > >> Stop here and make sure you obtained the debugging information as > >> described in > >> > http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tr > >> u > >> st > >> > >> Without that information it is hard to tell what is happening. > >> > >> Make also sure to tell exact environment (distribution, version, > >> package versions, etc). > >> > > > >Well things got ugly. I enabled debug and pointed in the right > >direction, smb failed to start. Came down to the cifs service was not > >added when I did the adtrust-install. I tried adding it and it > >complained that it could not find the A record for the host even though > >it was there. Thinking something was hung up in resolver cache > >possibly I restarted the ipa service and it failed completely. > > > >Ipactl start fails starting smb because of the missing service and > >everything fails from there. > > > >Is there any way to recover from this mess I just made? :) > I assume you have IPA 4.x, i.e. systemd-based environment. > Yes, sorry forgot to include that. > 1. Start manually dirsrv at INSTANCE-NAME.service > > 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. > Note that you SHOULD NOT replace $FOO variables below, they should be as > specified in the resulting file. For ipa-ldap-updater use see its manual page > and my blog: > https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ > > # cat 88-disable-adtrust-extid.update > dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > remove:ipaConfigString:enabledService > > dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > remove:ipaConfigString:enabledService > END > > # ipa-ldap-updater -l ./88-disable-adtrust-extid.update > > 3. Restart IPA > > 4. Re-run ipa-adtrust-install and look at the output, including what it appends > to /var/log/ipaserver-install.log. > Beautiful, that much is running again, thanks for those pointers. And I'm ashamed to say I tracked down the issue to a fat finger in the resolv.conf file, so it really couldn't look up the needed record :/ So back to the original issue that was in the end because smb wasn't started most likely. I'm still not sure how this will all respond in a multi homed environment like this if the IPA server cannot communicate with all of the interfaces on the DC. Will that cause an issue with the trust or is there anything I need to take into consideration with this? Thanks much From abokovoy at redhat.com Fri May 8 14:21:09 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 8 May 2015 17:21:09 +0300 Subject: [Freeipa-users] multi homed environment In-Reply-To: References: <20150508121653.GJ11785@redhat.com> <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> <20150508133940.GN11785@redhat.com> Message-ID: <20150508142109.GA7682@redhat.com> On Fri, 08 May 2015, Andy Thompson wrote: > > >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Friday, May 8, 2015 9:40 AM >> To: Andy Thompson >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] multi homed environment >> >> On Fri, 08 May 2015, Andy Thompson wrote: >> >> -----Original Message----- >> >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> >> Sent: Friday, May 8, 2015 8:17 AM >> >> To: Andy Thompson >> >> Cc: freeipa-users at redhat.com >> >> Subject: Re: [Freeipa-users] multi homed environment >> >> >> >> On Fri, 08 May 2015, Andy Thompson wrote: >> >> >I'm trying to roll out IPA in an existing windows environment where >> >> >everything is multi homed. I did not put my IPA server on all the >> >> >subnets. >> >> > >> >> >I'm having an issue with adding a trust to the domain with the error >> >> >below >> >> > >> >> >ipa: ERROR: CIFS server communication error: code "-1073741801", >> >> > message "Memory allocation error" (both may be >> >> >"None") >> >> > >> >> >DNS I think since it round robins all the existing A records and is >> >> >returning IPs out of the local subnet. I don't know much about >> >> >windows dns services but it's got netmask optimization enabled and >> >> >doing digs against the service returns the local IP first every >> >> >time, but pings return them in any order. >> >> > >> >> >I've considered adding the DCs to the local hosts file but I'm not >> >> >sure if that will solve the problem or not. Is that a viable fix? >> >> > >> >> >Anyone have any experience in an environment like this? Really not >> >> >sure what additional problems I will run into with all this multi >> >> >homed nonsense. >> >> Stop here and make sure you obtained the debugging information as >> >> described in >> >> >> http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tr >> >> u >> >> st >> >> >> >> Without that information it is hard to tell what is happening. >> >> >> >> Make also sure to tell exact environment (distribution, version, >> >> package versions, etc). >> >> >> > >> >Well things got ugly. I enabled debug and pointed in the right >> >direction, smb failed to start. Came down to the cifs service was not >> >added when I did the adtrust-install. I tried adding it and it >> >complained that it could not find the A record for the host even though >> >it was there. Thinking something was hung up in resolver cache >> >possibly I restarted the ipa service and it failed completely. >> > >> >Ipactl start fails starting smb because of the missing service and >> >everything fails from there. >> > >> >Is there any way to recover from this mess I just made? :) >> I assume you have IPA 4.x, i.e. systemd-based environment. >> > >Yes, sorry forgot to include that. > >> 1. Start manually dirsrv at INSTANCE-NAME.service >> >> 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. >> Note that you SHOULD NOT replace $FOO variables below, they should be as >> specified in the resulting file. For ipa-ldap-updater use see its manual page >> and my blog: >> https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ >> >> # cat 88-disable-adtrust-extid.update >> dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX >> remove:ipaConfigString:enabledService >> >> dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX >> remove:ipaConfigString:enabledService >> END >> >> # ipa-ldap-updater -l ./88-disable-adtrust-extid.update >> >> 3. Restart IPA >> >> 4. Re-run ipa-adtrust-install and look at the output, including what it appends >> to /var/log/ipaserver-install.log. >> > >Beautiful, that much is running again, thanks for those pointers. > >And I'm ashamed to say I tracked down the issue to a fat finger in the >resolv.conf file, so it really couldn't look up the needed record :/ > >So back to the original issue that was in the end because smb wasn't >started most likely. I'm still not sure how this will all respond in a >multi homed environment like this if the IPA server cannot communicate >with all of the interfaces on the DC. Will that cause an issue with >the trust or is there anything I need to take into consideration with >this? There are few things to consider: 1. IPA master uses DNS SRV records to discover whom to talk to on AD side. Received name from the SRV record is them used by IPA master to connect to the AD DC. 2. AD DCs use DNS SRV records to discover which IPA master to respond to when verifying trust. Received name from the SRV record is then used by AD DC to connect to the IPA master. 3. While right now trust is established using password-based authentication between IPA and AD DCs, actual resolution of identities when trust is in use requires working Kerberos authentication. This might give you a headache in multi-homed environments if the IP returned when resolving AD DC or IPA master would be unreachable. In any case, it is mostly a question of correct routing tables and DNS name resolution. -- / Alexander Bokovoy From Andy.Thompson at e-tcc.com Fri May 8 15:05:31 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 8 May 2015 15:05:31 +0000 Subject: [Freeipa-users] multi homed environment In-Reply-To: <20150508142109.GA7682@redhat.com> References: <20150508121653.GJ11785@redhat.com> <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> <20150508133940.GN11785@redhat.com> <20150508142109.GA7682@redhat.com> Message-ID: <6a816495fdd945b69802e11b9e067890@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Friday, May 8, 2015 10:21 AM > To: Andy Thompson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] multi homed environment > > On Fri, 08 May 2015, Andy Thompson wrote: > > > > > >> -----Original Message----- > >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > >> Sent: Friday, May 8, 2015 9:40 AM > >> To: Andy Thompson > >> Cc: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] multi homed environment > >> > >> On Fri, 08 May 2015, Andy Thompson wrote: > >> >> -----Original Message----- > >> >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > >> >> Sent: Friday, May 8, 2015 8:17 AM > >> >> To: Andy Thompson > >> >> Cc: freeipa-users at redhat.com > >> >> Subject: Re: [Freeipa-users] multi homed environment > >> >> > >> >> On Fri, 08 May 2015, Andy Thompson wrote: > >> >> >I'm trying to roll out IPA in an existing windows environment > >> >> >where everything is multi homed. I did not put my IPA server on > >> >> >all the subnets. > >> >> > > >> >> >I'm having an issue with adding a trust to the domain with the > >> >> >error below > >> >> > > >> >> >ipa: ERROR: CIFS server communication error: code "-1073741801", > >> >> > message "Memory allocation error" (both may be > >> >> >"None") > >> >> > > >> >> >DNS I think since it round robins all the existing A records and > >> >> >is returning IPs out of the local subnet. I don't know much > >> >> >about windows dns services but it's got netmask optimization > >> >> >enabled and doing digs against the service returns the local IP > >> >> >first every time, but pings return them in any order. > >> >> > > >> >> >I've considered adding the DCs to the local hosts file but I'm > >> >> >not sure if that will solve the problem or not. Is that a viable fix? > >> >> > > >> >> >Anyone have any experience in an environment like this? Really not > >> >> >sure what additional problems I will run into with all this multi > >> >> >homed nonsense. > >> >> Stop here and make sure you obtained the debugging information as > >> >> described in > >> >> > >> > http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tr > >> >> u > >> >> st > >> >> > >> >> Without that information it is hard to tell what is happening. > >> >> > >> >> Make also sure to tell exact environment (distribution, version, > >> >> package versions, etc). > >> >> > >> > > >> >Well things got ugly. I enabled debug and pointed in the right > >> >direction, smb failed to start. Came down to the cifs service was > >> >not added when I did the adtrust-install. I tried adding it and it > >> >complained that it could not find the A record for the host even > >> >though it was there. Thinking something was hung up in resolver > >> >cache possibly I restarted the ipa service and it failed completely. > >> > > >> >Ipactl start fails starting smb because of the missing service and > >> >everything fails from there. > >> > > >> >Is there any way to recover from this mess I just made? :) > >> I assume you have IPA 4.x, i.e. systemd-based environment. > >> > > > >Yes, sorry forgot to include that. > > > >> 1. Start manually dirsrv at INSTANCE-NAME.service > >> > >> 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. > >> Note that you SHOULD NOT replace $FOO variables below, they should be > >> as specified in the resulting file. For ipa-ldap-updater use see its > >> manual page and my blog: > >> https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-upda > >> ter/ > >> > >> # cat 88-disable-adtrust-extid.update > >> dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > >> remove:ipaConfigString:enabledService > >> > >> dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > >> remove:ipaConfigString:enabledService > >> END > >> > >> # ipa-ldap-updater -l ./88-disable-adtrust-extid.update > >> > >> 3. Restart IPA > >> > >> 4. Re-run ipa-adtrust-install and look at the output, including what > >> it appends to /var/log/ipaserver-install.log. > >> > > > >Beautiful, that much is running again, thanks for those pointers. > > > >And I'm ashamed to say I tracked down the issue to a fat finger in the > >resolv.conf file, so it really couldn't look up the needed record :/ > > > >So back to the original issue that was in the end because smb wasn't > >started most likely. I'm still not sure how this will all respond in a > >multi homed environment like this if the IPA server cannot communicate > >with all of the interfaces on the DC. Will that cause an issue with > >the trust or is there anything I need to take into consideration with > >this? > There are few things to consider: > > 1. IPA master uses DNS SRV records to discover whom to talk to on AD side. > Received name from the SRV record is them used by IPA master to connect > to the AD DC. > > 2. AD DCs use DNS SRV records to discover which IPA master to respond to > when verifying trust. Received name from the SRV record is then used by AD > DC to connect to the IPA master. > > 3. While right now trust is established using password-based authentication > between IPA and AD DCs, actual resolution of identities when trust is in use > requires working Kerberos authentication. This might give you a headache in > multi-homed environments if the IP returned when resolving AD DC or IPA > master would be unreachable. > > In any case, it is mostly a question of correct routing tables and DNS name > resolution. > IPA will only ever return a single address, it's the AD side I'm concerned about because it's a mess. I can't route to the other interfaces of the DC because IPA and the DC both share a net right now. Will adding the DC ip addresses to the IPA host files work around the potential for the problem? I don't know that I can guarantee the windows DNS doing anything I expect it to :) From janellenicole80 at gmail.com Fri May 8 15:22:57 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 08 May 2015 08:22:57 -0700 Subject: [Freeipa-users] more replication fun In-Reply-To: <554B1B55.2000908@redhat.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> <554B1B55.2000908@redhat.com> Message-ID: <554CD4D1.3030103@gmail.com> On 5/7/15 12:59 AM, thierry bordaz wrote: > On 05/07/2015 05:39 AM, Janelle wrote: >> On 5/6/15 8:12 PM, Vaclav Adamec wrote: >>> Hi, >>> Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode >>> thread), if you are sure that's not any live replica server behind >>> this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" >>> >>> Vasek >>> >>> >>> On Thu, May 7, 2015 at 2:25 AM, Janelle >>> wrote: >>>> Hi again.. >>>> >>>> Seems to be an ongoing theme (replication). How does one remove these? >>>> >>>> unable to decode: {replica 9} 553ef80e000100090000 >>>> 55402c39000000090000 >>>> >>>> I am hoping this is a stupid question with a really simple answer >>>> that I am simply missing? >>>> >>>> ~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 project >>> >>> >>> >> Thank you Vasek, >> >> I am curious however. I have been running OpenLDAP configs with 20 or >> more servers in replication for over 5 years. In all that time, I >> think I have had replication issues 5 times. In the 6 months of >> working with FreeIPA, replication issues are constant. From reading >> the threads, I am not the only one in this predicament. Is there any >> history on why replication is so problematic in FreeIPA? >> >> regards >> ~J >> > Hi Janelle, > > This is a large question and I have no precise answer. My > understanding of OpenLDAP replication vs RHDS replication is that > it is not based on the same approach syncrepl vs > replica_agreement. Both are working. Replication is complex and > when I compare RHDS with others DS implementation using the same > approach (replica_agreement) I can say that RHDS is doing a good > job in terms of performance, stability and robustness. > > Replication is sensitive to administrative tasks, backup-restore, > reinit, upgrade, schema update. This is possibly your case we have > seen 'unable to decode' during upgrade/cleanruv and still > investigating that bug. > > thanks > thierry > All of this makes good sense - in fact, even the OpenLDAP vs 389-ds issues and replication. Yes, in the environment I had, there were a couple of masters, and the reset were read-only, which meant keeping in sync - easy. Now, I was looking through the archives and can't seem to find the recommended way to delete one of these: unable to decode {replica 22} 553eec64000400160000 553eec64000400160000 I think someone mentioned a script, but I can't find it. I have several replicas in this state and would like to try and clean them up. The interesting thing is - the replicas in this state seem to have a higher CPU load as based on "uptime". Interesting. Thanks ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri May 8 15:30:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 May 2015 11:30:36 -0400 Subject: [Freeipa-users] more replication fun In-Reply-To: <554CD4D1.3030103@gmail.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> <554B1B55.2000908@redhat.com> <554CD4D1.3030103@gmail.com> Message-ID: <554CD69C.3050400@redhat.com> Janelle wrote: > On 5/7/15 12:59 AM, thierry bordaz wrote: >> On 05/07/2015 05:39 AM, Janelle wrote: >>> On 5/6/15 8:12 PM, Vaclav Adamec wrote: >>>> Hi, >>>> Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode >>>> thread), if you are sure that's not any live replica server behind >>>> this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" >>>> >>>> Vasek >>>> >>>> >>>> On Thu, May 7, 2015 at 2:25 AM, Janelle >>>> wrote: >>>>> Hi again.. >>>>> >>>>> Seems to be an ongoing theme (replication). How does one remove these? >>>>> >>>>> unable to decode: {replica 9} 553ef80e000100090000 >>>>> 55402c39000000090000 >>>>> >>>>> I am hoping this is a stupid question with a really simple answer >>>>> that I am simply missing? >>>>> >>>>> ~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 project >>>> >>>> >>>> >>> Thank you Vasek, >>> >>> I am curious however. I have been running OpenLDAP configs with 20 or >>> more servers in replication for over 5 years. In all that time, I >>> think I have had replication issues 5 times. In the 6 months of >>> working with FreeIPA, replication issues are constant. From reading >>> the threads, I am not the only one in this predicament. Is there any >>> history on why replication is so problematic in FreeIPA? >>> >>> regards >>> ~J >>> >> Hi Janelle, >> >> This is a large question and I have no precise answer. My >> understanding of OpenLDAP replication vs RHDS replication is that >> it is not based on the same approach syncrepl vs >> replica_agreement. Both are working. Replication is complex and >> when I compare RHDS with others DS implementation using the same >> approach (replica_agreement) I can say that RHDS is doing a good >> job in terms of performance, stability and robustness. >> >> Replication is sensitive to administrative tasks, backup-restore, >> reinit, upgrade, schema update. This is possibly your case we have >> seen 'unable to decode' during upgrade/cleanruv and still >> investigating that bug. >> >> thanks >> thierry >> > All of this makes good sense - in fact, even the OpenLDAP vs 389-ds > issues and replication. Yes, in the environment I had, there were a > couple of masters, and the reset were read-only, which meant keeping in > sync - easy. > > Now, I was looking through the archives and can't seem to find the > recommended way to delete one of these: > > unable to decode {replica 22} 553eec64000400160000 553eec64000400160000 > > I think someone mentioned a script, but I can't find it. I have > several replicas in this state and would like to try and clean them up. > The interesting thing is - the replicas in this state seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm to have a > higher CPU load as based on "uptime". Interesting. > > Thanks > ~J > > See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html It would be nice to know if this style of RUV could be acted on by ipa-replica-manage. I added this bit as a catch-all so no RUV would be invisibly skipped if it didn't match the regex I wrote. If this kind of RUV could indeed still be cleaned it would be nice to know and we could make that possible. rob From lkrispen at redhat.com Fri May 8 15:43:15 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 08 May 2015 17:43:15 +0200 Subject: [Freeipa-users] more replication fun In-Reply-To: <554CD69C.3050400@redhat.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> <554B1B55.2000908@redhat.com> <554CD4D1.3030103@gmail.com> <554CD69C.3050400@redhat.com> Message-ID: <554CD993.4040106@redhat.com> On 05/08/2015 05:30 PM, Rob Crittenden wrote: > Janelle wrote: >> On 5/7/15 12:59 AM, thierry bordaz wrote: >>> On 05/07/2015 05:39 AM, Janelle wrote: >>>> On 5/6/15 8:12 PM, Vaclav Adamec wrote: >>>>> Hi, >>>>> Mike Reynolds recommend cleanallruv script (IPA RUV unable to >>>>> decode >>>>> thread), if you are sure that's not any live replica server behind >>>>> this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" >>>>> >>>>> Vasek >>>>> >>>>> >>>>> On Thu, May 7, 2015 at 2:25 AM, Janelle >>>>> wrote: >>>>>> Hi again.. >>>>>> >>>>>> Seems to be an ongoing theme (replication). How does one remove >>>>>> these? >>>>>> >>>>>> unable to decode: {replica 9} 553ef80e000100090000 >>>>>> 55402c39000000090000 >>>>>> >>>>>> I am hoping this is a stupid question with a really simple answer >>>>>> that I am simply missing? >>>>>> >>>>>> ~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 project >>>>> >>>>> >>>>> >>>> Thank you Vasek, >>>> >>>> I am curious however. I have been running OpenLDAP configs with 20 or >>>> more servers in replication for over 5 years. In all that time, I >>>> think I have had replication issues 5 times. In the 6 months of >>>> working with FreeIPA, replication issues are constant. From reading >>>> the threads, I am not the only one in this predicament. Is there any >>>> history on why replication is so problematic in FreeIPA? >>>> >>>> regards >>>> ~J >>>> >>> Hi Janelle, >>> >>> This is a large question and I have no precise answer. My >>> understanding of OpenLDAP replication vs RHDS replication is that >>> it is not based on the same approach syncrepl vs >>> replica_agreement. Both are working. Replication is complex and >>> when I compare RHDS with others DS implementation using the same >>> approach (replica_agreement) I can say that RHDS is doing a good >>> job in terms of performance, stability and robustness. >>> >>> Replication is sensitive to administrative tasks, backup-restore, >>> reinit, upgrade, schema update. This is possibly your case we have >>> seen 'unable to decode' during upgrade/cleanruv and still >>> investigating that bug. >>> >>> thanks >>> thierry >>> >> All of this makes good sense - in fact, even the OpenLDAP vs 389-ds >> issues and replication. Yes, in the environment I had, there were a >> couple of masters, and the reset were read-only, which meant keeping in >> sync - easy. >> >> Now, I was looking through the archives and can't seem to find the >> recommended way to delete one of these: >> >> unable to decode {replica 22} 553eec64000400160000 553eec64000400160000 >> >> I think someone mentioned a script, but I can't find it. I have >> several replicas in this state and would like to try and clean them up. >> The interesting thing is - the replicas in this state >> seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm >> to have a >> higher CPU load as based on "uptime". Interesting. >> >> Thanks >> ~J >> >> > > See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html hopefully it does, if not maybe Mark can help to get rid of it > > It would be nice to know if this style of RUV could be acted on by > ipa-replica-manage. I added this bit as a catch-all so no RUV would be > invisibly skipped if it didn't match the regex I wrote. If this kind > of RUV could indeed still be cleaned it would be nice to know and we > could make that possible. I think this kind of RUV should never exist, strange enough we have a hard time to reproduce it in the lab, but out in the real world they seem to proliferate. Any help to reproduce is greatly appreciated. Ludwig > > rob > From janellenicole80 at gmail.com Fri May 8 15:47:30 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 08 May 2015 08:47:30 -0700 Subject: [Freeipa-users] more replication fun In-Reply-To: <554CD993.4040106@redhat.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> <554B1B55.2000908@redhat.com> <554CD4D1.3030103@gmail.com> <554CD69C.3050400@redhat.com> <554CD993.4040106@redhat.com> Message-ID: <554CDA92.509@gmail.com> On 5/8/15 8:43 AM, Ludwig Krispenz wrote: > > On 05/08/2015 05:30 PM, Rob Crittenden wrote: >> Janelle wrote: >>> On 5/7/15 12:59 AM, thierry bordaz wrote: >>>> On 05/07/2015 05:39 AM, Janelle wrote: >>>>> On 5/6/15 8:12 PM, Vaclav Adamec wrote: >>>>>> Hi, >>>>>> Mike Reynolds recommend cleanallruv script (IPA RUV unable to >>>>>> decode >>>>>> thread), if you are sure that's not any live replica server behind >>>>>> this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" >>>>>> >>>>>> Vasek >>>>>> >>>>>> >>>>>> On Thu, May 7, 2015 at 2:25 AM, Janelle >>>>>> wrote: >>>>>>> Hi again.. >>>>>>> >>>>>>> Seems to be an ongoing theme (replication). How does one remove >>>>>>> these? >>>>>>> >>>>>>> unable to decode: {replica 9} 553ef80e000100090000 >>>>>>> 55402c39000000090000 >>>>>>> >>>>>>> I am hoping this is a stupid question with a really simple answer >>>>>>> that I am simply missing? >>>>>>> >>>>>>> ~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 project >>>>>> >>>>>> >>>>>> >>>>> Thank you Vasek, >>>>> >>>>> I am curious however. I have been running OpenLDAP configs with 20 or >>>>> more servers in replication for over 5 years. In all that time, I >>>>> think I have had replication issues 5 times. In the 6 months of >>>>> working with FreeIPA, replication issues are constant. From reading >>>>> the threads, I am not the only one in this predicament. Is there any >>>>> history on why replication is so problematic in FreeIPA? >>>>> >>>>> regards >>>>> ~J >>>>> >>>> Hi Janelle, >>>> >>>> This is a large question and I have no precise answer. My >>>> understanding of OpenLDAP replication vs RHDS replication is that >>>> it is not based on the same approach syncrepl vs >>>> replica_agreement. Both are working. Replication is complex and >>>> when I compare RHDS with others DS implementation using the same >>>> approach (replica_agreement) I can say that RHDS is doing a good >>>> job in terms of performance, stability and robustness. >>>> >>>> Replication is sensitive to administrative tasks, backup-restore, >>>> reinit, upgrade, schema update. This is possibly your case we have >>>> seen 'unable to decode' during upgrade/cleanruv and still >>>> investigating that bug. >>>> >>>> thanks >>>> thierry >>>> >>> All of this makes good sense - in fact, even the OpenLDAP vs 389-ds >>> issues and replication. Yes, in the environment I had, there were a >>> couple of masters, and the reset were read-only, which meant keeping in >>> sync - easy. >>> >>> Now, I was looking through the archives and can't seem to find the >>> recommended way to delete one of these: >>> >>> unable to decode {replica 22} 553eec64000400160000 >>> 553eec64000400160000 >>> >>> I think someone mentioned a script, but I can't find it. I have >>> several replicas in this state and would like to try and clean them up. >>> The interesting thing is - the replicas in this state >>> seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm >>> to have a >>> higher CPU load as based on "uptime". Interesting. >>> >>> Thanks >>> ~J >>> >>> >> >> See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html > hopefully it does, if not maybe Mark can help to get rid of it >> >> It would be nice to know if this style of RUV could be acted on by >> ipa-replica-manage. I added this bit as a catch-all so no RUV would >> be invisibly skipped if it didn't match the regex I wrote. If this >> kind of RUV could indeed still be cleaned it would be nice to know >> and we could make that possible. > I think this kind of RUV should never exist, strange enough we have a > hard time to reproduce it in the lab, but out in the real world they > seem to proliferate. > > Any help to reproduce is greatly appreciated. > > Ludwig >> >> rob >> > That little ldapmodify - did indeed do the trick In fact, it seemed to "replicate" the clean correctly and it disappeared from all my replicas in a few seconds. Let me see if I can reproduce in my lab. Thank you ~J From nathan at nathanpeters.com Fri May 8 16:25:25 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 8 May 2015 09:25:25 -0700 Subject: [Freeipa-users] Are there active plans to allow AD trust users to login to the FreeIPA webUI? Message-ID: <7448fa35568ea120c2878639d81ce8fa.squirrel@webmail.nathanpeters.com> We have all of our users in a trusted Active Directory domain and it would be nice to allow them to administer our DNS using their AD accounts. I tried creating a group called DNS administrators and assigning it the DNS administrator privilege and then adding my ad_domain_admin group (containing the nested external group containing my ad groups), but when I try to login to the webui it denies me access. I see a ticket here regarding allowing this : https://fedorahosted.org/freeipa/ticket/3242 It doesn't look like anything has happened on that ticket in the last 15 months though. Any idea if / when this will be implemented? From dpal at redhat.com Fri May 8 17:12:02 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 May 2015 13:12:02 -0400 Subject: [Freeipa-users] Are there active plans to allow AD trust users to login to the FreeIPA webUI? In-Reply-To: <7448fa35568ea120c2878639d81ce8fa.squirrel@webmail.nathanpeters.com> References: <7448fa35568ea120c2878639d81ce8fa.squirrel@webmail.nathanpeters.com> Message-ID: <554CEE62.6060602@redhat.com> On 05/08/2015 12:25 PM, nathan at nathanpeters.com wrote: > We have all of our users in a trusted Active Directory domain and it would > be nice to allow them to administer our DNS using their AD accounts. > > I tried creating a group called DNS administrators and assigning it the > DNS administrator privilege and then adding my ad_domain_admin group > (containing the nested external group containing my ad groups), but when I > try to login to the webui it denies me access. > > I see a ticket here regarding allowing this : > https://fedorahosted.org/freeipa/ticket/3242 > > It doesn't look like anything has happened on that ticket in the last 15 > months though. > > Any idea if / when this will be implemented? > > There are no current plans. It is quite complex as we need to have a ticket for the user for ldap server to have this functionality enabled. This is the first time anyone from the community actually requested this feature. I think for the future planning it would be best if you can comment in the ticket and add your justification. We will consider it in the next planning cycle. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From janellenicole80 at gmail.com Fri May 8 17:12:40 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 08 May 2015 10:12:40 -0700 Subject: [Freeipa-users] more replication fun In-Reply-To: <554CD993.4040106@redhat.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> <554B1B55.2000908@redhat.com> <554CD4D1.3030103@gmail.com> <554CD69C.3050400@redhat.com> <554CD993.4040106@redhat.com> Message-ID: <554CEE88.1040902@gmail.com> On 5/8/15 8:43 AM, Ludwig Krispenz wrote: > > On 05/08/2015 05:30 PM, Rob Crittenden wrote: >> Janelle wrote: >>> On 5/7/15 12:59 AM, thierry bordaz wrote: >>>> On 05/07/2015 05:39 AM, Janelle wrote: >>>>> On 5/6/15 8:12 PM, Vaclav Adamec wrote: >>>>>> Hi, >>>>>> Mike Reynolds recommend cleanallruv script (IPA RUV unable to >>>>>> decode >>>>>> thread), if you are sure that's not any live replica server behind >>>>>> this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" >>>>>> >>>>>> Vasek >>>>>> >>>>>> >>>>>> On Thu, May 7, 2015 at 2:25 AM, Janelle >>>>>> wrote: >>>>>>> Hi again.. >>>>>>> >>>>>>> Seems to be an ongoing theme (replication). How does one remove >>>>>>> these? >>>>>>> >>>>>>> unable to decode: {replica 9} 553ef80e000100090000 >>>>>>> 55402c39000000090000 >>>>>>> >>>>>>> I am hoping this is a stupid question with a really simple answer >>>>>>> that I am simply missing? >>>>>>> >>>>>>> ~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 project >>>>>> >>>>>> >>>>>> >>>>> Thank you Vasek, >>>>> >>>>> I am curious however. I have been running OpenLDAP configs with 20 or >>>>> more servers in replication for over 5 years. In all that time, I >>>>> think I have had replication issues 5 times. In the 6 months of >>>>> working with FreeIPA, replication issues are constant. From reading >>>>> the threads, I am not the only one in this predicament. Is there any >>>>> history on why replication is so problematic in FreeIPA? >>>>> >>>>> regards >>>>> ~J >>>>> >>>> Hi Janelle, >>>> >>>> This is a large question and I have no precise answer. My >>>> understanding of OpenLDAP replication vs RHDS replication is that >>>> it is not based on the same approach syncrepl vs >>>> replica_agreement. Both are working. Replication is complex and >>>> when I compare RHDS with others DS implementation using the same >>>> approach (replica_agreement) I can say that RHDS is doing a good >>>> job in terms of performance, stability and robustness. >>>> >>>> Replication is sensitive to administrative tasks, backup-restore, >>>> reinit, upgrade, schema update. This is possibly your case we have >>>> seen 'unable to decode' during upgrade/cleanruv and still >>>> investigating that bug. >>>> >>>> thanks >>>> thierry >>>> >>> All of this makes good sense - in fact, even the OpenLDAP vs 389-ds >>> issues and replication. Yes, in the environment I had, there were a >>> couple of masters, and the reset were read-only, which meant keeping in >>> sync - easy. >>> >>> Now, I was looking through the archives and can't seem to find the >>> recommended way to delete one of these: >>> >>> unable to decode {replica 22} 553eec64000400160000 >>> 553eec64000400160000 >>> >>> I think someone mentioned a script, but I can't find it. I have >>> several replicas in this state and would like to try and clean them up. >>> The interesting thing is - the replicas in this state >>> seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm >>> to have a >>> higher CPU load as based on "uptime". Interesting. >>> >>> Thanks >>> ~J >>> >>> >> >> See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html > hopefully it does, if not maybe Mark can help to get rid of it >> >> It would be nice to know if this style of RUV could be acted on by >> ipa-replica-manage. I added this bit as a catch-all so no RUV would >> be invisibly skipped if it didn't match the regex I wrote. If this >> kind of RUV could indeed still be cleaned it would be nice to know >> and we could make that possible. > I think this kind of RUV should never exist, strange enough we have a > hard time to reproduce it in the lab, but out in the real world they > seem to proliferate. > > Any help to reproduce is greatly appreciated. > > Ludwig >> >> rob >> > One last question regarding this (I hope). Now I am trying to re-add a server that does not show up in replica list, has no outstanding clean-ruv tasks, BUT - I still get: The host ipa03.example.com already exists on the master server. You should remove it before proceeding: % ipa host-del ipa03.example.com BUT - trying that results in: ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or disabled :-( Help? ~J From rcritten at redhat.com Fri May 8 17:22:15 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 May 2015 13:22:15 -0400 Subject: [Freeipa-users] more replication fun In-Reply-To: <554CEE88.1040902@gmail.com> References: <554AB111.5050601@gmail.com> <554ADE5A.90801@gmail.com> <554B1B55.2000908@redhat.com> <554CD4D1.3030103@gmail.com> <554CD69C.3050400@redhat.com> <554CD993.4040106@redhat.com> <554CEE88.1040902@gmail.com> Message-ID: <554CF0C7.5090004@redhat.com> Janelle wrote: > On 5/8/15 8:43 AM, Ludwig Krispenz wrote: >> >> On 05/08/2015 05:30 PM, Rob Crittenden wrote: >>> Janelle wrote: >>>> On 5/7/15 12:59 AM, thierry bordaz wrote: >>>>> On 05/07/2015 05:39 AM, Janelle wrote: >>>>>> On 5/6/15 8:12 PM, Vaclav Adamec wrote: >>>>>>> Hi, >>>>>>> Mike Reynolds recommend cleanallruv script (IPA RUV unable to >>>>>>> decode >>>>>>> thread), if you are sure that's not any live replica server behind >>>>>>> this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9" >>>>>>> >>>>>>> Vasek >>>>>>> >>>>>>> >>>>>>> On Thu, May 7, 2015 at 2:25 AM, Janelle >>>>>>> wrote: >>>>>>>> Hi again.. >>>>>>>> >>>>>>>> Seems to be an ongoing theme (replication). How does one remove >>>>>>>> these? >>>>>>>> >>>>>>>> unable to decode: {replica 9} 553ef80e000100090000 >>>>>>>> 55402c39000000090000 >>>>>>>> >>>>>>>> I am hoping this is a stupid question with a really simple answer >>>>>>>> that I am simply missing? >>>>>>>> >>>>>>>> ~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 project >>>>>>> >>>>>>> >>>>>>> >>>>>> Thank you Vasek, >>>>>> >>>>>> I am curious however. I have been running OpenLDAP configs with 20 or >>>>>> more servers in replication for over 5 years. In all that time, I >>>>>> think I have had replication issues 5 times. In the 6 months of >>>>>> working with FreeIPA, replication issues are constant. From reading >>>>>> the threads, I am not the only one in this predicament. Is there any >>>>>> history on why replication is so problematic in FreeIPA? >>>>>> >>>>>> regards >>>>>> ~J >>>>>> >>>>> Hi Janelle, >>>>> >>>>> This is a large question and I have no precise answer. My >>>>> understanding of OpenLDAP replication vs RHDS replication is that >>>>> it is not based on the same approach syncrepl vs >>>>> replica_agreement. Both are working. Replication is complex and >>>>> when I compare RHDS with others DS implementation using the same >>>>> approach (replica_agreement) I can say that RHDS is doing a good >>>>> job in terms of performance, stability and robustness. >>>>> >>>>> Replication is sensitive to administrative tasks, backup-restore, >>>>> reinit, upgrade, schema update. This is possibly your case we have >>>>> seen 'unable to decode' during upgrade/cleanruv and still >>>>> investigating that bug. >>>>> >>>>> thanks >>>>> thierry >>>>> >>>> All of this makes good sense - in fact, even the OpenLDAP vs 389-ds >>>> issues and replication. Yes, in the environment I had, there were a >>>> couple of masters, and the reset were read-only, which meant keeping in >>>> sync - easy. >>>> >>>> Now, I was looking through the archives and can't seem to find the >>>> recommended way to delete one of these: >>>> >>>> unable to decode {replica 22} 553eec64000400160000 >>>> 553eec64000400160000 >>>> >>>> I think someone mentioned a script, but I can't find it. I have >>>> several replicas in this state and would like to try and clean them up. >>>> The interesting thing is - the replicas in this state >>>> seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm >>>> to have a >>>> higher CPU load as based on "uptime". Interesting. >>>> >>>> Thanks >>>> ~J >>>> >>>> >>> >>> See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html >> hopefully it does, if not maybe Mark can help to get rid of it >>> >>> It would be nice to know if this style of RUV could be acted on by >>> ipa-replica-manage. I added this bit as a catch-all so no RUV would >>> be invisibly skipped if it didn't match the regex I wrote. If this >>> kind of RUV could indeed still be cleaned it would be nice to know >>> and we could make that possible. >> I think this kind of RUV should never exist, strange enough we have a >> hard time to reproduce it in the lab, but out in the real world they >> seem to proliferate. >> >> Any help to reproduce is greatly appreciated. >> >> Ludwig >>> >>> rob >>> >> > One last question regarding this (I hope). > > Now I am trying to re-add a server that does not show up in replica > list, has no outstanding clean-ruv tasks, BUT - I still get: > > The host ipa03.example.com already exists on the master server. > You should remove it before proceeding: > % ipa host-del ipa03.example.com > > BUT - trying that results in: > > ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or > disabled I'm guessing the replica was removed without being formally deleted. You can remove it with: ipa-replica-manage del --force --cleanup ipa03.example.com rob From nathan at nathanpeters.com Fri May 8 17:24:58 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 8 May 2015 10:24:58 -0700 Subject: [Freeipa-users] Are there active plans to allow AD trust users to login to the FreeIPA webUI? In-Reply-To: <554CEE62.6060602@redhat.com> References: <7448fa35568ea120c2878639d81ce8fa.squirrel@webmail.nathanpeters.com> <554CEE62.6060602@redhat.com> Message-ID: <4f5d2ac6eb02e470612b950a431c5484.squirrel@webmail.nathanpeters.com> > On 05/08/2015 12:25 PM, nathan at nathanpeters.com wrote: >> We have all of our users in a trusted Active Directory domain and it >> would >> be nice to allow them to administer our DNS using their AD accounts. >> >> I tried creating a group called DNS administrators and assigning it the >> DNS administrator privilege and then adding my ad_domain_admin group >> (containing the nested external group containing my ad groups), but when >> I >> try to login to the webui it denies me access. >> >> I see a ticket here regarding allowing this : >> https://fedorahosted.org/freeipa/ticket/3242 >> >> It doesn't look like anything has happened on that ticket in the last 15 >> months though. >> >> Any idea if / when this will be implemented? >> >> > There are no current plans. It is quite complex as we need to have a > ticket for the user for ldap server to have this functionality enabled. > This is the first time anyone from the community actually requested this > feature. > I think for the future planning it would be best if you can comment in > the ticket and add your justification. > We will consider it in the next planning cycle. > > -- > Thank you, > Dmitri Pal > > Director of Engineering for 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 > Ok, thanks. I've updated the ticket with my justification for continuing work on this feature: https://fedorahosted.org/freeipa/ticket/3242#comment:12 From shelllinux5 at gmail.com Fri May 8 18:06:40 2015 From: shelllinux5 at gmail.com (Linux Shell) Date: Fri, 8 May 2015 14:06:40 -0400 Subject: [Freeipa-users] Configuration of client side components failed! Message-ID: So i have been looking around for a solution for this issue for a few days now and have had no luck. I know in older versions of freeipa this was a issue but i think i should be using the most updated version. (Please note that my company's name is withheld) During the ipa-server-install it fails with: Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' '.com' '--server' '###-#####-centos7..com' '--realm' '.COM' '--hostname' '####-#####-centos7..com'' returned non-zero exit status 1 here is the yum ipa-server package i am using: # yum info ipa-server Loaded plugins: fastestmirror, rhnplugin This system is receiving updates from RHN Classic or Red Hat Satellite. Loading mirror speeds from cached hostfile * base: mirrors.usinternet.com * extras: mirror.oss.ou.edu * updates: mirrors.gigenet.com Installed Packages Name : ipa-server Arch : x86_64 Version : 4.1.0 Release : 18.el7.centos.3 Size : 4.2 M Repo : installed >From repo : updates Summary : The IPA authentication server URL : http://www.freeipa.org/ License : GPLv3+ Description : IPA is an integrated solution to provide centrally managed Identity (machine, : user, virtual machines, groups, authentication credentials), Policy : (configuration settings, access control information) and Audit (events, : logs, analysis thereof). If you are installing an IPA server you need : to install this package (in other words, most people should NOT install : this package). here is the yum ipa-client package i am using: # yum info ipa-client Loaded plugins: fastestmirror, rhnplugin This system is receiving updates from RHN Classic or Red Hat Satellite. Loading mirror speeds from cached hostfile * base: mirrors.usinternet.com * extras: mirror.oss.ou.edu * updates: mirrors.gigenet.com Installed Packages Name : ipa-client Arch : x86_64 Version : 4.1.0 Release : 18.el7.centos.3 Size : 440 k Repo : installed >From repo : updates Summary : IPA authentication for use on clients URL : http://www.freeipa.org/ License : GPLv3+ Description : IPA is an integrated solution to provide centrally managed Identity (machine, : user, virtual machines, groups, authentication credentials), Policy : (configuration settings, access control information) and Audit (events, : logs, analysis thereof). If your network uses IPA for authentication, : this package should be installed on every client machine. here is the /var/log/ipaserver-install.log: 2015-05-08T17:47:16Z DEBUG stderr=Using existing certificate '/etc/ipa/ca.crt'. Hostname: ###-####-centos7..com Realm: .COM DNS Domain: .com IPA Server: ####-#####-centos7..com BaseDN: dc=####,dc=#### Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf trying https://####-#####-centos7..com/ipa/json Forwarding 'ping' to json server 'https:// ###-#####-centos7..com/ipa/json' Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 2925, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 2906, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2609, in install api.Backend.rpcclient.forward('ping') File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 883, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 860, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1011, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 980, in __request verbose=self.__verbose >= 3, File "/usr/lib64/python2.7/xmlrpclib.py", line 1228, in request h = self.make_connection(host) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 484, in make_connection if self._connection and host == self._connection[0]: AttributeError: KerbTransport instance has no attribute '_connection' 2015-05-08T17:47:16Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1292, in main sys.exit("Configuration of client side components failed!\nipa-client-install returned: " + str(e)) please let me know of any thing i can give to help fix the issue Thanks Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From asacamano at gmail.com Fri May 8 19:27:34 2015 From: asacamano at gmail.com (Andrew Sacamano) Date: Fri, 8 May 2015 13:27:34 -0600 Subject: [Freeipa-users] Stuck getting sudo working with Ubuntu client In-Reply-To: <55492B76.4030401@ubuntu.com> References: <20150417202822.GA13306@mail.corp.redhat.com> <20150420072957.GC30713@mail.corp.redhat.com> <20150421194556.GA6409@mail.corp.redhat.com> <55374AC0.4030608@ubuntu.com> <55492B76.4030401@ubuntu.com> Message-ID: Thanks Timo, And sorry I missed that. How's this? https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1453253 Thanks again, Andrew On Tue, May 5, 2015 at 2:43 PM, Timo Aaltonen wrote: > On 05.05.2015 23:27, Andrew Sacamano wrote: > > Thanks again Lukas and Timo, > > > > I'm very sorry it took so long for me to get to this - I got pulled into > > an urgent project at work and am just getting my head above water today. > > > > I've filed https://fedorahosted.org/sssd/ticket/2648 > > err, the bug needs to be on launchpad, since that's where it belongs > > > > On Wed, Apr 22, 2015 at 1:16 AM, Timo Aaltonen > > wrote: > > > > On 21.04.2015 22 :45, Lukas Slebodnik wrote: > > > On (20/04/15 17:54), Andrew Sacamano wrote: > > >> Thanks again, Lukas! > > >> > > >> I was wondering if the overlaps of names was a problem, so I > > redid parts of > > >> my IPA setup to rename them - thanks for pointing out the ticket! > > >> > > >> Also, your suggestion to use ldap_group_object_class = > > ipaUserGroup worked > > >> - which saves me the trouble of tracking that down in six months > > when my > > >> IPA domain grows and the performance issues associated with > > enumerate begin > > >> to manifest. > > >> > > >> Many thanks - you are extraordinarily helpful. My colleagues and > > I are > > >> quite grateful for all your advice! > > >> > > > You are welcome, > > > I'm glad I could help. > > > > > > You can file a ticket to backport patch for ticket #2471 in your > > distribution. > > > > Please do, I've pulled the patch in git but need a bug# for SRU: > > > > https://bugs.launchpad.net/ubuntu/+source/sssd/+filebug > > > > > > -- > > t > > > > > > > -- > t > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri May 8 20:00:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 May 2015 16:00:20 -0400 Subject: [Freeipa-users] Configuration of client side components failed! In-Reply-To: References: Message-ID: <554D15D4.3030502@redhat.com> On 05/08/2015 02:06 PM, Linux Shell wrote: > So i have been looking around for a solution for this issue for a few > days now and have had no luck. I know in older versions of freeipa > this was a issue but i think i should be using the most updated version. > > (Please note that my company's name is withheld) > > During the ipa-server-install it fails with: > > Restarting the web server > Configuration of client side components failed! > ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' > '--on-master' '--unattended' '--domain' '.com' '--server' > '###-#####-centos7..com' '--realm' '.COM' > '--hostname' '####-#####-centos7..com'' returned non-zero > exit status 1 > > here is the yum ipa-server package i am using: > > # yum info ipa-server > Loaded plugins: fastestmirror, rhnplugin > This system is receiving updates from RHN Classic or Red Hat Satellite. > Loading mirror speeds from cached hostfile > * base: mirrors.usinternet.com > * extras: mirror.oss.ou.edu > * updates: mirrors.gigenet.com > Installed Packages > Name : ipa-server > Arch : x86_64 > Version : 4.1.0 > Release : 18.el7.centos.3 > Size : 4.2 M > Repo : installed > From repo : updates > Summary : The IPA authentication server > URL : http://www.freeipa.org/ > License : GPLv3+ > Description : IPA is an integrated solution to provide centrally > managed Identity (machine, > : user, virtual machines, groups, authentication > credentials), Policy > : (configuration settings, access control information) and > Audit (events, > : logs, analysis thereof). If you are installing an IPA > server you need > : to install this package (in other words, most people > should NOT install > : this package). > > > here is the yum ipa-client package i am using: > > # yum info ipa-client > Loaded plugins: fastestmirror, rhnplugin > This system is receiving updates from RHN Classic or Red Hat Satellite. > Loading mirror speeds from cached hostfile > * base: mirrors.usinternet.com > * extras: mirror.oss.ou.edu > * updates: mirrors.gigenet.com > Installed Packages > Name : ipa-client > Arch : x86_64 > Version : 4.1.0 > Release : 18.el7.centos.3 > Size : 440 k > Repo : installed > From repo : updates > Summary : IPA authentication for use on clients > URL : http://www.freeipa.org/ > License : GPLv3+ > Description : IPA is an integrated solution to provide centrally > managed Identity (machine, > : user, virtual machines, groups, authentication > credentials), Policy > : (configuration settings, access control information) and > Audit (events, > : logs, analysis thereof). If your network uses IPA for > authentication, > : this package should be installed on every client machine. > > here is the /var/log/ipaserver-install.log: > > 2015-05-08T17:47:16Z DEBUG stderr=Using existing certificate > '/etc/ipa/ca.crt'. > Hostname: ###-####-centos7..com > Realm: .COM > DNS Domain: .com > IPA Server: ####-#####-centos7..com > BaseDN: dc=####,dc=#### > Configured sudoers in /etc/nsswitch.conf > Configured /etc/sssd/sssd.conf > trying https://####-#####-centos7..com/ipa/json > Forwarding 'ping' to json server > 'https://###-#####-centos7..com/ipa/json' > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2925, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2906, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 2609, in install > api.Backend.rpcclient.forward('ping') > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 883, in > forward > return self._call_command(command, params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 860, in > _call_command > return command(*params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1011, in > _call > return self.__request(name, args) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 980, in > __request > verbose=self.__verbose >= 3, > File "/usr/lib64/python2.7/xmlrpclib.py", line 1228, in request > h = self.make_connection(host) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 484, in > make_connection > if self._connection and host == self._connection[0]: > AttributeError: KerbTransport instance has no attribute '_connection' I would assume that this is an attempt to do some kerberos call that failed. On server that most likely means that KDC was not started for some reason. And it in turn might not start for different reasons. Please check the troubleshooting page. http://www.freeipa.org/page/Troubleshooting Things to think about: - DNS configuration - Is hostname correct and properly resolvable - Is time correct (time zone?) - Are there any SELinux denials? > > 2015-05-08T17:47:16Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 646, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1292, in main > sys.exit("Configuration of client side components > failed!\nipa-client-install returned: " + str(e)) > > please let me know of any thing i can give to help fix the issue > Thanks > Jacob > > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri May 8 20:01:06 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 May 2015 16:01:06 -0400 Subject: [Freeipa-users] Are there active plans to allow AD trust users to login to the FreeIPA webUI? In-Reply-To: <4f5d2ac6eb02e470612b950a431c5484.squirrel@webmail.nathanpeters.com> References: <7448fa35568ea120c2878639d81ce8fa.squirrel@webmail.nathanpeters.com> <554CEE62.6060602@redhat.com> <4f5d2ac6eb02e470612b950a431c5484.squirrel@webmail.nathanpeters.com> Message-ID: <554D1602.40708@redhat.com> On 05/08/2015 01:24 PM, nathan at nathanpeters.com wrote: >> On 05/08/2015 12:25 PM, nathan at nathanpeters.com wrote: >>> We have all of our users in a trusted Active Directory domain and it >>> would >>> be nice to allow them to administer our DNS using their AD accounts. >>> >>> I tried creating a group called DNS administrators and assigning it the >>> DNS administrator privilege and then adding my ad_domain_admin group >>> (containing the nested external group containing my ad groups), but when >>> I >>> try to login to the webui it denies me access. >>> >>> I see a ticket here regarding allowing this : >>> https://fedorahosted.org/freeipa/ticket/3242 >>> >>> It doesn't look like anything has happened on that ticket in the last 15 >>> months though. >>> >>> Any idea if / when this will be implemented? >>> >>> >> There are no current plans. It is quite complex as we need to have a >> ticket for the user for ldap server to have this functionality enabled. >> This is the first time anyone from the community actually requested this >> feature. >> I think for the future planning it would be best if you can comment in >> the ticket and add your justification. >> We will consider it in the next planning cycle. >> >> -- >> Thank you, >> Dmitri Pal >> >> Director of Engineering for 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 >> > Ok, thanks. I've updated the ticket with my justification for continuing > work on this feature: > https://fedorahosted.org/freeipa/ticket/3242#comment:12 > Thank you! Much appreciated. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From jhrozek at redhat.com Sun May 10 16:47:09 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 10 May 2015 18:47:09 +0200 Subject: [Freeipa-users] Removing REALM requirement and home directory location In-Reply-To: <5434D6A65FEF2B428D5CC8D77FA7DA7106A46824@wexc201p.bsc.bscal.com> References: <5434D6A65FEF2B428D5CC8D77FA7DA7106A41CD8@wexc201p.bsc.bscal.com> <55487FCC.2090106@redhat.com> <5434D6A65FEF2B428D5CC8D77FA7DA7106A46824@wexc201p.bsc.bscal.com> Message-ID: <20150510164709.GK38847@Jakubs-MacBook-Pro.local> On Wed, May 06, 2015 at 06:53:49PM +0000, Redmond, Stacy wrote: > That's great, I got it all working, perhaps you can answer one last question, although not sure this is going to be fixable or not. > > Anyway to get rid of the realm when using id, as you can see below, kinda messy. > > [root at linuxtest1 home]# su - aduser1 > -sh-4.1$ id > uid=1989603105(aduser1 at sbx.local) gid=1989603105(aduser1 at sbx.local) groups=1989603105(aduser1 at sbx.local) > -sh-4.1$ pwd > /home/aduser1 > -sh-4.1$ ls -l /home/ > total 4 > drwxr-xr-x 2 aduser1 at sbx.local aduser1 at sbx.local 4096 May 5 09:38 aduser1 > -sh-4.1$ On the clients you may experiment with default_domain_suffix and setting the full_name_format to just "%1$s" but on the server, this format is mandatory. The extdom plugin is only able to parse input in the name at domain form.. From jhrozek at redhat.com Sun May 10 16:53:47 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 10 May 2015 18:53:47 +0200 Subject: [Freeipa-users] External DNS In-Reply-To: <554B9BEE.8060102@redhat.com> References: <20150507093117.Horde.xBSVdmEwhY5VSxTFvAqV1JA@webmailnew.dds.nl> <554B2461.9040109@redhat.com> <554B9BEE.8060102@redhat.com> Message-ID: <20150510165347.GL38847@Jakubs-MacBook-Pro.local> On Thu, May 07, 2015 at 01:07:58PM -0400, Dmitri Pal wrote: > On 05/07/2015 04:37 AM, Petr Spacek wrote: > >On 7.5.2015 09:31, Winfried de Heiden wrote: > >>Hi all, > >> > >> One of the nice FreeIPA features is a host will be added to DNS > >>automatically when the client is installed. However, in some situations > >>using an other, external, DNS server is prefered. Now, this is possible but > >>hosts have to added manually to this other DNS-server. > >> > >> Is it possible to handle DNS records by IPA on an external DNS server? Any > >>future plans for this? > >This automatic update is handled by SSSD and uses standard DNS update > >protocol. I.e. it should work as long as your 'external' DNS server is > >configured to accept updates from clients. > > This is the update not the creation. > Will the update create both A/AAAA and PTR record? It should also create the record (although I haven't tested right now). SSSD would so far only create the address family that is used to connect to the server. We have an RFE open to update both: https://fedorahosted.org/sssd/ticket/2120 and also update the address on startup, not on going offline, which might be too late in some cases: https://fedorahosted.org/sssd/ticket/1926 But what I see as a potentially more important blocker is that SSSD always use the GSSAPI credentials of the joined realm. If the external DNS server requires different authentication, the update wouldn't succeed. > I thought that it will just update IP but not create these records. > If I am correct then the question is valid and we need to have a way to > create entries in an external data store. > > Sounds like another use case for the notification system. > And for that we do not have firm plans yet but we are collecting the use > cases to justify the effort. > Martin do you think it is worth opening a ticket? > > >Please refer to documentation to your DNS server for further information and > >let us know if you encounter some problem. > > > >Have a nice day! > > > > > -- > Thank you, > Dmitri Pal > > Director of Engineering for 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 From jhrozek at redhat.com Sun May 10 17:02:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 10 May 2015 19:02:28 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> Message-ID: <20150510170228.GM38847@Jakubs-MacBook-Pro.local> On Thu, May 07, 2015 at 03:30:06PM +0100, Dylan Evans wrote: > By coincidence I posted a very similar question yesterday - > https://www.redhat.com/archives/freeipa-users/2015-May/msg00103.html. > > +1 for the necessary support for out-of-domain Windows clients and NTLMSSP. > > Is there a time-table for this? It is a nice-to-have feature for the next SSSD version (1.13, this summber), but my hopes are not high that we're going to make it. I think 1.14 is more realistic. From jhrozek at redhat.com Sun May 10 17:10:49 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 10 May 2015 19:10:49 +0200 Subject: [Freeipa-users] External DNS In-Reply-To: <20150510165347.GL38847@Jakubs-MacBook-Pro.local> References: <20150507093117.Horde.xBSVdmEwhY5VSxTFvAqV1JA@webmailnew.dds.nl> <554B2461.9040109@redhat.com> <554B9BEE.8060102@redhat.com> <20150510165347.GL38847@Jakubs-MacBook-Pro.local> Message-ID: <20150510171049.GN38847@Jakubs-MacBook-Pro.local> On Sun, May 10, 2015 at 06:53:47PM +0200, Jakub Hrozek wrote: > SSSD would so far only create the address family that is used to connect > to the server. We have an RFE open to update both: > https://fedorahosted.org/sssd/ticket/2120 > and also update the address on startup, not on going offline, which ~~~~~~~~~~~~~ Shoud be going online of course.. > might be too late in some cases: > https://fedorahosted.org/sssd/ticket/1926 From janellenicole80 at gmail.com Mon May 11 00:44:42 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sun, 10 May 2015 17:44:42 -0700 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <5548C9E6.6050306@redhat.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> Message-ID: <554FFB7A.1040701@gmail.com> On 5/5/15 6:47 AM, Dmitri Pal wrote: > On 05/04/2015 09:38 PM, Janelle wrote: >> On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >>> On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >>>> Happy Star Wars Day! >>>> May the Fourth be with you! >>>> >>>> So I have a strange Kerberos problem trying to figure out. On a >>>> CLIENT, (CentOS 7.1) if I login to account "usera" they get a >>>> ticket as >>>> expected. However, if I login to a 6.6 client, it doesn't seem to >>>> work. >>>> Both were enrolled the same, obviously one is newer. >>>> >>>> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >>>> as >>>> root, bypassing kerberos, and then do "kinit admin" it works just >>>> fine. >>>> But if I do "kinit usera" I get: >>>> >>>> kinit: Generic preauthentication failure while getting initial >>>> credentials >>>> >>>> Which makes no sense. The account works with a 7.1 client but not a >>>> 6.x >>>> client?? And yet "admin" works, no matter what. What am I missing >>>> here? >>> If I had to guess, usera is enabled for OTP-only login. Is that >>> correct? >>> >>> If so, clients require RHEL 7.1 for OTP support. Also, the error you >>> are getting is the result of not enabling FAST support for OTP >>> authentication (see the -T option). >>> >>> Nathaniel >> Ok, this did give me an idea (Thanks Nathaniel) -- the account was >> set for BOTH "password" and OTP. >> Apparently setting both does nothing. Yes a user can login with their >> password-only, but trying to use kinit does not work. >> >> I am not sure I understand where the FAST support or the -T option is >> to be applied. On kinit? That does not seem correct. Perhaps I am >> misunderstanding this option? >> >> ~J >> > If the user is enabled for OTP his credential are sent differently > than in the case when it is not enabled. Effectively instead of using > encrypted timestamp the password and OTP are sent to the server as > data. But they can't be sent in clear. You need to encrypt the data. > To encrypt it you need another key - the host key. The encryption of > the data in this context is called tunneling . FAST is the Kerberos > protocol feature to provide tunneling of the data sent over the wire. > To use FAST one needs to use -T on the kinit command line. > Does this help? > It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. >From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server principal" and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Thank you Janelle From abokovoy at redhat.com Mon May 11 06:57:59 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 May 2015 09:57:59 +0300 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <554FFB7A.1040701@gmail.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> Message-ID: <20150511065759.GA5152@redhat.com> On Sun, 10 May 2015, Janelle wrote: >On 5/5/15 6:47 AM, Dmitri Pal wrote: >>On 05/04/2015 09:38 PM, Janelle wrote: >>>On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >>>>On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >>>>>Happy Star Wars Day! >>>>>May the Fourth be with you! >>>>> >>>>>So I have a strange Kerberos problem trying to figure out. On a >>>>>CLIENT, (CentOS 7.1) if I login to account "usera" they get a >>>>>ticket as >>>>>expected. However, if I login to a 6.6 client, it doesn't seem to >>>>>work. >>>>>Both were enrolled the same, obviously one is newer. >>>>> >>>>>Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >>>>>as >>>>>root, bypassing kerberos, and then do "kinit admin" it works just >>>>>fine. >>>>>But if I do "kinit usera" I get: >>>>> >>>>>kinit: Generic preauthentication failure while getting initial >>>>>credentials >>>>> >>>>>Which makes no sense. The account works with a 7.1 client but not a >>>>>6.x >>>>>client?? And yet "admin" works, no matter what. What am I missing >>>>>here? >>>>If I had to guess, usera is enabled for OTP-only login. Is that >>>>correct? >>>> >>>>If so, clients require RHEL 7.1 for OTP support. Also, the error you >>>>are getting is the result of not enabling FAST support for OTP >>>>authentication (see the -T option). >>>> >>>>Nathaniel >>>Ok, this did give me an idea (Thanks Nathaniel) -- the account >>>was set for BOTH "password" and OTP. >>>Apparently setting both does nothing. Yes a user can login with >>>their password-only, but trying to use kinit does not work. >>> >>>I am not sure I understand where the FAST support or the -T option >>>is to be applied. On kinit? That does not seem correct. Perhaps I >>>am misunderstanding this option? >>> >>>~J >>> >>If the user is enabled for OTP his credential are sent differently >>than in the case when it is not enabled. Effectively instead of >>using encrypted timestamp the password and OTP are sent to the >>server as data. But they can't be sent in clear. You need to encrypt >>the data. To encrypt it you need another key - the host key. The >>encryption of the data in this context is called tunneling . FAST is >>the Kerberos protocol feature to provide tunneling of the data sent >>over the wire. To use FAST one needs to use -T on the kinit command >>line. >>Does this help? >> >It helps -- thank you. > >Now allow me to add a little more fun, and there may not be a >solution. >>From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server >principal" and it works, gives me a ticket, and if I attempt to login >to the web interface, since I already have my ticket - boom, works >fine. > >Now, I enable 2FA and setup a token and change my account to OTP (with >TOTP). But as previously discussed, can't seem to specify a -T option >from OS X. > >I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. -- / Alexander Bokovoy From vangass at gazeta.pl Mon May 11 11:19:01 2015 From: vangass at gazeta.pl (Vangass) Date: Mon, 11 May 2015 13:19:01 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem Message-ID: Hello, I have a problem with HBAC rules with conjunction with PAM authentication. What I try to do is to authenticate users: tac_plus - PAM (pam_sssd) - FreeIPA. It works just fine but without checking HBAC rules. What I did: - disabled allow_all rule - created new rule with one user and one service (tac_plus) And then, if I try to authenticate another user which is not in above rule then authetication is accepted and this user gets logged in. In logs, what I didn't find is an information about checking HBAC rules... Of course, when I use HBAC Test then everything is correct - one user is granted and another is declined. # cat /etc/pam.d/tac_plus auth required pam_sss.so account required pam_sss.so Did I miss something? Thanks, Bartek Witkowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon May 11 11:57:38 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 11 May 2015 13:57:38 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: References: Message-ID: <20150511115738.GP3722@hendrix.payandsurf.com> On Mon, May 11, 2015 at 01:19:01PM +0200, Vangass wrote: > Hello, > > I have a problem with HBAC rules with conjunction with PAM authentication. > What I try to do is to authenticate users: tac_plus - PAM (pam_sssd) - > FreeIPA. > It works just fine but without checking HBAC rules. > What I did: > - disabled allow_all rule > - created new rule with one user and one service (tac_plus) > And then, if I try to authenticate another user which is not in above rule > then authetication is accepted and this user gets logged in. > In logs, what I didn't find is an information about checking HBAC rules... > Of course, when I use HBAC Test then everything is correct - one user is > granted and another is declined. > > # cat /etc/pam.d/tac_plus > auth required pam_sss.so > account required pam_sss.so If hbactest passes, then we need to see the logs, /var/log/secure and SSSD logs. Also the sssd.conf, please. From jpazdziora at redhat.com Mon May 11 12:05:15 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 11 May 2015 14:05:15 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: <20150511115738.GP3722@hendrix.payandsurf.com> References: <20150511115738.GP3722@hendrix.payandsurf.com> Message-ID: <20150511120515.GY6587@redhat.com> On Mon, May 11, 2015 at 01:57:38PM +0200, Jakub Hrozek wrote: > On Mon, May 11, 2015 at 01:19:01PM +0200, Vangass wrote: > > Hello, > > > > I have a problem with HBAC rules with conjunction with PAM authentication. > > What I try to do is to authenticate users: tac_plus - PAM (pam_sssd) - > > FreeIPA. > > It works just fine but without checking HBAC rules. > > What I did: > > - disabled allow_all rule > > - created new rule with one user and one service (tac_plus) > > And then, if I try to authenticate another user which is not in above rule > > then authetication is accepted and this user gets logged in. > > In logs, what I didn't find is an information about checking HBAC rules... > > Of course, when I use HBAC Test then everything is correct - one user is > > granted and another is declined. > > > > # cat /etc/pam.d/tac_plus > > auth required pam_sss.so > > account required pam_sss.so > > If hbactest passes, then we need to see the logs, /var/log/secure and > SSSD logs. Also the sssd.conf, please. Also, how did you configure that tac_plus PAM service should be used? How do you try to access the machine / service? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Mon May 11 12:14:07 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 11 May 2015 14:14:07 +0200 Subject: [Freeipa-users] multi homed environment In-Reply-To: <20150508142109.GA7682@redhat.com> References: <20150508121653.GJ11785@redhat.com> <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> <20150508133940.GN11785@redhat.com> <20150508142109.GA7682@redhat.com> Message-ID: <20150511121406.GZ6587@redhat.com> On Fri, May 08, 2015 at 05:21:09PM +0300, Alexander Bokovoy wrote: > On Fri, 08 May 2015, Andy Thompson wrote: > >>>> On Fri, 08 May 2015, Andy Thompson wrote: > >>>> > > >>>> >I'm having an issue with adding a trust to the domain with the error > >>>> >below > >>>> > > >>>> >ipa: ERROR: CIFS server communication error: code "-1073741801", > >>>> > message "Memory allocation error" (both may be > >>>> >"None") > > >And I'm ashamed to say I tracked down the issue to a fat finger in the > >resolv.conf file, so it really couldn't look up the needed record :/ > > In any case, it is mostly a question of correct routing tables and DNS > name resolution. Is there anything we can add to the tool on our side to catch the errors earlier and/or make the error messages less scary and more descriptive? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From Andy.Thompson at e-tcc.com Mon May 11 12:44:54 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Mon, 11 May 2015 12:44:54 +0000 Subject: [Freeipa-users] multi homed environment In-Reply-To: <20150511121406.GZ6587@redhat.com> References: <20150508121653.GJ11785@redhat.com> <9bbc954e37f44557b71cc8959d675297@TCCCORPEXCH02.TCC.local> <20150508133940.GN11785@redhat.com> <20150508142109.GA7682@redhat.com> <20150511121406.GZ6587@redhat.com> Message-ID: <1cff9718bfe0408ab4f4e3168824c024@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Jan Pazdziora > Sent: Monday, May 11, 2015 8:14 AM > To: Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] multi homed environment > > On Fri, May 08, 2015 at 05:21:09PM +0300, Alexander Bokovoy wrote: > > On Fri, 08 May 2015, Andy Thompson wrote: > > >>>> On Fri, 08 May 2015, Andy Thompson wrote: > > >>>> > > > >>>> >I'm having an issue with adding a trust to the domain with the > > >>>> >error below > > >>>> > > > >>>> >ipa: ERROR: CIFS server communication error: code "-1073741801", > > >>>> > message "Memory allocation error" (both may be > > >>>> >"None") > > > > >And I'm ashamed to say I tracked down the issue to a fat finger in > > >the resolv.conf file, so it really couldn't look up the needed record > > >:/ > > > > In any case, it is mostly a question of correct routing tables and DNS > > name resolution. > > Is there anything we can add to the tool on our side to catch the errors earlier > and/or make the error messages less scary and more descriptive? > Possibly error out and stop the setup entirely if DNS can't be resolved... make it a pre setup check and halt. Currently it allows the install to continue, albeit saying what happened. I just didn't pay close enough attention the first time around to see that it failed that step... I think I started it, went to another screen and came back and noted it was completed and moved forward. From arthur at deus.pro Mon May 11 12:51:28 2015 From: arthur at deus.pro (Arthur Fayzullin) Date: Mon, 11 May 2015 17:51:28 +0500 Subject: [Freeipa-users] some documentation issues Message-ID: <1431348688.2040.3.camel@deus.pro> Have a nice day! I think that I have found somethings that are mispresent and unpresent in documentation. I have tried to configure debian jessie as a freeipa client. This has been done in 2 ways: * reference instalation: I have installed freeipa-client package from sid and configured host by running ipa-client-install command. * manual instalation: I have installed packages that've been installed as dependencies during reference installation. And I have done steps described here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/linux-manual.html Evrything seems to work fine (and even sudo rules) exept 1 thing: I could not get host certificate by certmonger. comparing to reference installation I have found that ipa-client-install also makes 1 more config file: /etc/ipa/default.conf but this step is not described in documentation. so this is unpresent. Another thing that I think is present with mistake: according to documentation I should give this command to get host-certificate: # ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM' and we can see that 'HOST' is capitalised, but it should in small letters. Thanks for reading! From vangass at gazeta.pl Mon May 11 12:57:37 2015 From: vangass at gazeta.pl (Vangass) Date: Mon, 11 May 2015 14:57:37 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: <20150511120515.GY6587@redhat.com> References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> Message-ID: Hi, I try to access Cisco switch via ssh. Cisco has tacacs login configured. # tail /var/log/secure May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= user=bartosz May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= user=test User bartosz is added in HBAC rule as Specified Users and Groups. User test exist in FreeIPA but isn't in HBAC rule and shouldn't be autheniticated. # cat /etc/sssd/sssd.conf [domain/test.example.com] debug_level = 6 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = test.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = freeipa.test.example.com chpass_provider = ipa ipa_server = freeipa.test.example.com ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = test.example.com [nss] homedir_substring = /home [pam] debug_level = 6 domains = test.example.com [sudo] [autofs] [ssh] [pac] [ifp] #cat /var/log/sssd/sssd_pam.log (Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): Client connected to privileged pipe! (Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'test' matched without domain, user is test (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: tac_plus (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not set (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 29218 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: test (Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f4f20215ed0:3:test at test.example.com] (Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [test.example.com][3][1][name=test] (Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f4f20215ed0:3:test at test.example.com] (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [test at test.example.com] (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [test at test.example.com] (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: test.example.com (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: tac_plus (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not set (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 29218 (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: test (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f4f20215ed0:3:test at test.example.com] (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][test.example.com] (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 81 (Mon May 11 14:40:28 2015) [sssd[pam]] [client_recv] (0x0200): Client disconnected! # cat /var/log/sssd/sssd_test.example.com.log (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_get_account_info] (0x0200): Got request for [0x3][1][name=test] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] (0x0400): Changing request domain from [test.example.com] to [ test.example.com] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=test,dc=example,dc=com] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=test)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] (0x0400): Save user (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_primary_name] (0x0400): Processing object test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] (0x0400): Processing user test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [test]. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] (0x0400): Adding user principal [test at TEST.EXAMPLE.COM] to attributes of [test]. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] (0x0400): Storing info for user test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_primary_name] (0x0400): Processing object test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=ipausers,cn=groups,cn=accounts,dc=test,dc=example,dc=com]. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_primary_name] (0x0400): Processing object ipausers (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=test,dc=example,dc=com] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=732000003)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 1 results. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_nested_group_recv] (0x0400): 0 users found in the hash table (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_nested_group_recv] (0x0400): 1 groups found in the hash table (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_primary_name] (0x0400): Processing object test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] (0x0400): Processing group test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_process_ghost_members] (0x0400): The group has 0 members (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_process_ghost_members] (0x0400): Group has 0 members (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] (0x0400): Storing info for group test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_primary_name] (0x0400): Processing object test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] (0x0400): Processing group test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] (0x0400): Failed to get group sid (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] (0x0400): No members for group [test] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:test.example.com:b8e22526-f4c0-11e4-8865-005056a8f368))][cn=Default Trust View,cn=views,cn=accounts,dc=test,dc=example,dc=com]. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: No such object(32), no errmsg set (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] (0x0400): Changing request domain from [test.example.com] to [ test.example.com] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_pam_handler] (0x0100): Got request with the following data (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): domain: test.example.com (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): user: test (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): service: tac_plus (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): tty: (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): ruser: (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): rhost: (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): authtok type: 1 (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): priv: 1 (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): cli_pid: 29218 (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] (0x0100): logon name: not set (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_resolve_server_process] (0x0200): Found address for server freeipa.test.example.com: [172.21.0.20] TTL 7200 (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [child_sig_handler] (0x0100): child [29226] finished successfully. (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server ' freeipa.test.example.com' as 'working' (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [set_server_common_status] (0x0100): Marking server ' freeipa.test.example.com' as 'working' (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server ' freeipa.test.example.com' as 'working' (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][test.example.com] (Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_pam_handler_callback] (0x0100): Sent result [0][test.example.com] 2015-05-11 14:05 GMT+02:00 Jan Pazdziora : > On Mon, May 11, 2015 at 01:57:38PM +0200, Jakub Hrozek wrote: > > On Mon, May 11, 2015 at 01:19:01PM +0200, Vangass wrote: > > > Hello, > > > > > > I have a problem with HBAC rules with conjunction with PAM > authentication. > > > What I try to do is to authenticate users: tac_plus - PAM (pam_sssd) - > > > FreeIPA. > > > It works just fine but without checking HBAC rules. > > > What I did: > > > - disabled allow_all rule > > > - created new rule with one user and one service (tac_plus) > > > And then, if I try to authenticate another user which is not in above > rule > > > then authetication is accepted and this user gets logged in. > > > In logs, what I didn't find is an information about checking HBAC > rules... > > > Of course, when I use HBAC Test then everything is correct - one user > is > > > granted and another is declined. > > > > > > # cat /etc/pam.d/tac_plus > > > auth required pam_sss.so > > > account required pam_sss.so > > > > If hbactest passes, then we need to see the logs, /var/log/secure and > > SSSD logs. Also the sssd.conf, please. > > Also, how did you configure that tac_plus PAM service should be used? > How do you try to access the machine / service? > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon May 11 13:20:05 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 11 May 2015 15:20:05 +0200 Subject: [Freeipa-users] allow trust users to login without domain In-Reply-To: References: Message-ID: <20150511132005.GS3722@hendrix.payandsurf.com> On Wed, Apr 29, 2015 at 10:57:45AM +0000, Andy Thompson wrote: > In the environment I'm working on currently we have a single trusted AD domain and will never have any additional domain trusts in place. Is there a way to allow users to login without using @ad_domain in their username? We use DB2 in the environment and it's from the dark ages and doesn't like usernames with more than 8 chars :/ > > Thanks > > -andy (I was searching for a different thread and found out that this message was left unanswered. Sorry about that!) default_domain_suffix is what you're looking for. From pspacek at redhat.com Mon May 11 13:53:07 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 11 May 2015 15:53:07 +0200 Subject: [Freeipa-users] some documentation issues In-Reply-To: <1431348688.2040.3.camel@deus.pro> References: <1431348688.2040.3.camel@deus.pro> Message-ID: <5550B443.9080704@redhat.com> On 11.5.2015 14:51, Arthur Fayzullin wrote: > Have a nice day! > > I think that I have found somethings that are mispresent and unpresent in documentation. > I have tried to configure debian jessie as a freeipa client. This has been done in 2 ways: > > * reference instalation: > I have installed freeipa-client package from sid and configured host by running ipa-client-install command. > > * manual instalation: > I have installed packages that've been installed as dependencies during reference installation. And I have done steps described here: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/linux-manual.html > Evrything seems to work fine (and even sudo rules) exept 1 thing: I could not get host certificate by certmonger. > comparing to reference installation I have found that ipa-client-install also makes 1 more config file: > /etc/ipa/default.conf > but this step is not described in documentation. so this is unpresent. > Another thing that I think is present with mistake: > according to documentation I should give this command to get host-certificate: > > # ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM' > > and we can see that 'HOST' is capitalised, but it should in small letters. > > Thanks for reading! Thank you for bug reports! Could you please send patches which fix these problems? (Preferably separate patch for each problem.) Necessary links are here: http://www.freeipa.org/page/Contribute/Documentation If you do not want to fix it yourself please open a bug to make sure that documentation team will not forget to fix it: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=doc-Linux_Domain_Identity_Management_Guide Thank you and have a nice day! -- Petr^2 Spacek From lslebodn at redhat.com Mon May 11 14:47:01 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 11 May 2015 16:47:01 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> Message-ID: <20150511144700.GJ2628@mail.corp.redhat.com> On (11/05/15 14:57), Vangass wrote: >Hi, > >I try to access Cisco switch via ssh. Cisco has tacacs login configured. > ># tail /var/log/secure >May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= >user=bartosz >May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= >user=test > >User bartosz is added in HBAC rule as Specified Users and Groups. >User test exist in FreeIPA but isn't in HBAC rule and shouldn't be >autheniticated. > ># cat /etc/sssd/sssd.conf >[domain/test.example.com] >debug_level = 6 >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = test.example.com >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = freeipa.test.example.com >chpass_provider = ipa >ipa_server = freeipa.test.example.com >ipa_server_mode = True >ldap_tls_cacert = /etc/ipa/ca.crt > >[sssd] >services = nss, sudo, pam, ssh >config_file_version = 2 >domains = test.example.com > >[nss] >homedir_substring = /home > >[pam] >debug_level = 6 >domains = test.example.com > >[sudo] > >[autofs] > >[ssh] > >[pac] > >[ifp] > > >#cat /var/log/sssd/sssd_pam.log >(Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): Client >connected to privileged pipe! >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): >Received client version [3]. >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): >Offered version [3]. >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): >entering pam_cmd_authenticate >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains] >(0x0200): name 'test' matched without domain, user is test >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: >PAM_AUTHENTICATE >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: >not set >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: >tac_plus >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not >set >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: >not set >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: >not set >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok >type: 1 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): >newauthtok type: 0 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: >29218 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon >name: test >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400): >Issuing request for [0x7f4f20215ed0:3:test at test.example.com] >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): >Creating request for [test.example.com][3][1][name=test] >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): >Entering request [0x7f4f20215ed0:3:test at test.example.com] >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0100): >Requesting info for [test at test.example.com] >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0400): >Returning info for user [test at test.example.com] >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending >request with the following data: >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: >PAM_AUTHENTICATE >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: >test.example.com >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: >tac_plus >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not >set >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: >not set >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: >not set >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok >type: 1 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): >newauthtok type: 0 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: >29218 >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon >name: test >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): >pam_dp_send_req returned 0 >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): >Deleting request: [0x7f4f20215ed0:3:test at test.example.com] >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): >received: [0][test.example.com] >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply >called with result [0]. >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply >called with result [0]. >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 81 >(Mon May 11 14:40:28 2015) [sssd[pam]] [client_recv] (0x0200): Client >disconnected! > ># cat /var/log/sssd/sssd_test.example.com.log >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[be_get_account_info] (0x0200): Got request for [0x3][1][name=test] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] >(0x0400): Changing request domain from [test.example.com] to [ >test.example.com] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >domain SID from [(null)] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >domain SID from [(null)] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_initgr_next_base] (0x0400): Searching for users with base >[cn=accounts,dc=test,dc=example,dc=com] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with >[(&(uid=test)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no >errmsg set >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] >(0x0400): Save user >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_primary_name] (0x0400): Processing object test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] >(0x0400): Processing user test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >domain SID from [(null)] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] >(0x0400): Adding original memberOf attributes to [test]. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] >(0x0400): Adding user principal [test at TEST.EXAMPLE.COM] to attributes of >[test]. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] >(0x0400): Storing info for user test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_primary_name] (0x0400): Processing object test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with >[(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=ipausers,cn=groups,cn=accounts,dc=test,dc=example,dc=com]. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no >errmsg set >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_primary_name] (0x0400): Processing object ipausers >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >domain SID from [(null)] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_groups_next_base] (0x0400): Searching for groups with base >[cn=accounts,dc=test,dc=example,dc=com] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with >[(&(gidNumber=732000003)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no >errmsg set >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_groups_process] (0x0400): Search for groups, returned 1 results. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >domain SID from [(null)] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_nested_group_recv] (0x0400): 0 users found in the hash table >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_nested_group_recv] (0x0400): 1 groups found in the hash table >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_primary_name] (0x0400): Processing object test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] >(0x0400): Processing group test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse >domain SID from [(null)] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_process_ghost_members] (0x0400): The group has 0 members >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_process_ghost_members] (0x0400): Group has 0 members >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] >(0x0400): Storing info for group test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_primary_name] (0x0400): Processing object test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] >(0x0400): Processing group test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] >(0x0400): Failed to get group sid >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] >(0x0400): No members for group [test] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with >[(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:test.example.com:b8e22526-f4c0-11e4-8865-005056a8f368))][cn=Default >Trust View,cn=views,cn=accounts,dc=test,dc=example,dc=com]. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[sdap_get_generic_op_finished] (0x0400): Search result: No such object(32), >no errmsg set >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [acctinfo_callback] >(0x0100): Request processed. Returned 0,0,Success >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] >(0x0400): Changing request domain from [test.example.com] to [ >test.example.com] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_pam_handler] >(0x0100): Got request with the following data >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): command: PAM_AUTHENTICATE Here just authentication was performed. It coresponds to the line "auth required pam_sss.so" in your pam stack. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): domain: test.example.com >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): user: test >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): service: tac_plus >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): tty: >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): ruser: >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): rhost: >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): authtok type: 1 >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): newauthtok type: 0 >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): priv: 1 >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): cli_pid: 29218 >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] >(0x0100): logon name: not set >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[be_resolve_server_process] (0x0200): Found address for server >freeipa.test.example.com: [172.21.0.20] TTL 7200 >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[write_pipe_handler] (0x0400): All data has been sent! >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [child_sig_handler] >(0x0100): child [29226] finished successfully. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [read_pipe_handler] >(0x0400): EOF received, client finished >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[fo_set_port_status] (0x0100): Marking port 0 of server ' >freeipa.test.example.com' as 'working' >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[set_server_common_status] (0x0100): Marking server ' >freeipa.test.example.com' as 'working' >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[fo_set_port_status] (0x0400): Marking port 0 of duplicate server ' >freeipa.test.example.com' as 'working' >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) >[Success] ^^^^^^^^ Result of authentication is "Success" which means that password is correct. >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[be_pam_handler_callback] (0x0100): Sending result [0][test.example.com] >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] >[be_pam_handler_callback] (0x0100): Sent result [0][test.example.com] > I could not see authorisation phase; neither in sssd_pam log nor in sssd_$domain.log. It means that you either shared just part of log file or that your application did not reach/try line "account" in pam stack "account required pam_sss.so" In this case you would able to see PAM_ACCT_MGMT in log files. sssd seems to work as expected. LS From thibaut.pouzet at lyra-network.com Mon May 11 15:14:16 2015 From: thibaut.pouzet at lyra-network.com (Thibaut Pouzet) Date: Mon, 11 May 2015 17:14:16 +0200 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) Message-ID: <5550C748.3090903@lyra-network.com> Hi ! I am running into a weird problem with my IPA Server, and the certificates management. My setup is : CentOS 6.6 pki-ca-9.0.3-38.el6_6.noarch ipa-server-3.0.0-42.el6.centos.x86_64 Linux ipa_server 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux The server has been installed two years ago, and all the certificates on the master server expired this month. (2 year validity). Apparently, they were not properly tracked by certmonger, so they were not renewed. By doing some getcert stop-tracking, then getcert start-tracking xxxx, I was able to track 8 of the 9 certificates that I can display with getcert list on this server. There is one that remains expired, despite all the efforts I put into renewing it. This is the one used for the pki-ca administration pages reachable on ports 9443, 9444 and 9445. Here is its status after trying to resubmit it : getcert resubmit -i 20150511145941 -K HTTP/ipa_server getcert list -i 20150511145941 Number of certificates and requests being tracked: 9. Request ID '20150511145941': status: CA_UNREACHABLE ca-error: Server at https://ipa_server/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Invalid Request)). stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='1234' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ipa_domain subject: CN=ipa_server,O=ipa_domain expires: 2015-04-09 04:58:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes I tried to stop tracking it, and then tracking it again, with no luck : getcert start-tracking -d "/var/lib/pki-ca/alias" -n "subsystemCert cert-pki-ca" -t "NSS Certificate DB" -P 1234 -r -c IPA I changed the trust settings as well, still not working : sh-4.1# certutil -M -n "Server-Cert cert-pki-ca" -d /var/lib/pki-ca/alias -t u,u,Pu sh-4.1# certutil -L -d /var/lib/pki-ca/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,Pu However, I find this error in different places : ca-error: Server at "http://ipa_server:9180/ca/ee/ca/profileSubmit" replied: Invalid Request sh-4.1# ipa user-show admin ipa: ERROR: Missing or invalid HTTP Referer, https://ipa_server/ipa/xml Sometimes, I also get it with "ipa cert-show 1", sometimes I don't. Sometimes its status changes even though I don't think I've done anything : ca-error: Server at https://ipa_server/ipa/xml failed request, will retry: 911 (RPC failed at server. Missing or invalid HTTP Referer, https://ipa_server/ipa/xml). And I can find inside /var/log/pki-ca/debug these lines : [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10: signature verification enabled [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10 org.mozilla.jss.NoSuchTokenException [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10 restoring thread token Invalid Request at com.netscape.cms.profile.common.EnrollProfile.parsePKCS10(EnrollProfile.java:953) at com.netscape.cms.profile.common.EnrollProfile.createRequests(EnrollProfile.java:102) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:1001) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:501) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFilter.java:176) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:701) There is the BLOB inside the logs, containing the CSR, and I can read it with openssl so it is correctly formatted : Certificate Request: Data: Version: 0 (0x0) Subject: O=ipa_domain, CN=ipa_server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: 1b:fb Exponent: 65537 (0x10001) Attributes: friendlyName :unable to print attribute Requested Extensions: X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Subject Alternative Name: othername:, othername: X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: 2E:41:D7:91:F0:F4:AA:F6:3D:C0:0C:6B:89:DB:23:6C:90:DA:0E:C7 Signature Algorithm: sha256WithRSAEncryption 53:36:9a:b6:e8:90:a1:3f:99:cf:85:64:9d:1c:ff:40:ad:f4: 31:53:03:81:0c:37:5e:3d:d2:a2:c1:fb:1c:6c:68:f9:c8:cd: b9:45:38:be:b1:17:ac:63:7b:a7:46:ca:64:1a:d3:4a:c2:63: ca:64:ca:39:01:e4:5f:3b:6c:86:de:23:0e:12:04:be:2b:f7: 22:1c:ac:0f:91:56:87:b2:95:20:a6:2d:10:f9:98:e5:51:46: c8:b0:71:20:85:98:a3:35:c4:ef:fd:55:20:5e:a9:01:ed:3b: 99:5f:43:8a:85:b1:c7:3d:94:1d:d6:4b:87:3b:1a:72:c4:7b: 35:5c:65:11:e2:7f:ba:72:d8:63:ab:f6:a1:6f:b0:73:0b:c5: c7:ca:2a:da:eb:b3:d0:64:75:7d:c3:9a:f5:b3:e7:d1:7b:e2: b0:ab:68:87:a2:fd:71:19:92:49:b5:e0:72:32:d8:cd:b7:f3: c9:a2:92:0d:20:65:c7:4a:5a:e7:d4:2a:e5:50:f1:63:44:97: 2c:c5:27:c4:2e:38:be:4f:02:33:91:f5:7d:2d:ab:75:7b:09: f7:86:0d:ac:3b:b7:c9:5e:00:96:49:e4:b1:f5:19:d2:1b:e6: 68:d6:e9:51:5b:9b:ec:d4:b3:e6:fd:e3:ee:7f:84:c3:e6:9b: cb:11:d8:48 And here I am, with this expired certificate still being served on my server... If anyone has any clue on what's going on, I would be really grateful ! Cheers, -- Thibaut Pouzet Lyra Network Ing?nieur Syst?mes et R?seaux (+33) 5 31 22 40 08 www.lyra-network.com PS : I've tried to work with this link with no luck : https://www.freeipa.org/page/FreeIPAv2:Certificate_Authority From sbose at redhat.com Mon May 11 15:15:31 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 11 May 2015 17:15:31 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: <20150511144700.GJ2628@mail.corp.redhat.com> References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> <20150511144700.GJ2628@mail.corp.redhat.com> Message-ID: <20150511151531.GL6227@p.redhat.com> On Mon, May 11, 2015 at 04:47:01PM +0200, Lukas Slebodnik wrote: > On (11/05/15 14:57), Vangass wrote: > >Hi, > > > >I try to access Cisco switch via ssh. Cisco has tacacs login configured. > > > ># tail /var/log/secure > >May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= > >user=bartosz > >May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= > >user=test > > > >User bartosz is added in HBAC rule as Specified Users and Groups. > >User test exist in FreeIPA but isn't in HBAC rule and shouldn't be > >autheniticated. > > > ># cat /etc/sssd/sssd.conf > >[domain/test.example.com] > >debug_level = 6 > >cache_credentials = True > >krb5_store_password_if_offline = True > >ipa_domain = test.example.com > >id_provider = ipa > >auth_provider = ipa > >access_provider = ipa > >ipa_hostname = freeipa.test.example.com > >chpass_provider = ipa > >ipa_server = freeipa.test.example.com > >ipa_server_mode = True > >ldap_tls_cacert = /etc/ipa/ca.crt > > > >[sssd] > >services = nss, sudo, pam, ssh > >config_file_version = 2 > >domains = test.example.com > > > >[nss] > >homedir_substring = /home > > > >[pam] > >debug_level = 6 > >domains = test.example.com > > > >[sudo] > > > >[autofs] > > > >[ssh] > > > >[pac] > > > >[ifp] > > > > > >#cat /var/log/sssd/sssd_pam.log > >(Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): Client > >connected to privileged pipe! > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > >Received client version [3]. > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > >Offered version [3]. > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): > >entering pam_cmd_authenticate > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains] > >(0x0200): name 'test' matched without domain, user is test > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > >PAM_AUTHENTICATE > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > >not set > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > >tac_plus > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not > >set > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > >not set > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > >not set > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > >type: 1 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > >newauthtok type: 0 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > >29218 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon > >name: test > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400): > >Issuing request for [0x7f4f20215ed0:3:test at test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): > >Creating request for [test.example.com][3][1][name=test] > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): > >Entering request [0x7f4f20215ed0:3:test at test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > >Requesting info for [test at test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0400): > >Returning info for user [test at test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > >request with the following data: > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > >PAM_AUTHENTICATE > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > >test.example.com > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > >tac_plus > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not > >set > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > >not set > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > >not set > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > >type: 1 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > >newauthtok type: 0 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > >29218 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon > >name: test > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > >pam_dp_send_req returned 0 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): > >Deleting request: [0x7f4f20215ed0:3:test at test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > >received: [0][test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > >called with result [0]. > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > >called with result [0]. > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 81 > >(Mon May 11 14:40:28 2015) [sssd[pam]] [client_recv] (0x0200): Client > >disconnected! > > > ># cat /var/log/sssd/sssd_test.example.com.log > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[be_get_account_info] (0x0200): Got request for [0x3][1][name=test] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] > >(0x0400): Changing request domain from [test.example.com] to [ > >test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > >domain SID from [(null)] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > >domain SID from [(null)] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_initgr_next_base] (0x0400): Searching for users with base > >[cn=accounts,dc=test,dc=example,dc=com] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > >[(&(uid=test)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > >errmsg set > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > >(0x0400): Save user > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_primary_name] (0x0400): Processing object test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > >(0x0400): Processing user test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > >domain SID from [(null)] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > >(0x0400): Adding original memberOf attributes to [test]. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > >(0x0400): Adding user principal [test at TEST.EXAMPLE.COM] to attributes of > >[test]. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > >(0x0400): Storing info for user test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_primary_name] (0x0400): Processing object test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > >[(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=ipausers,cn=groups,cn=accounts,dc=test,dc=example,dc=com]. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > >errmsg set > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_primary_name] (0x0400): Processing object ipausers > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > >domain SID from [(null)] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_groups_next_base] (0x0400): Searching for groups with base > >[cn=accounts,dc=test,dc=example,dc=com] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > >[(&(gidNumber=732000003)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > >errmsg set > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_groups_process] (0x0400): Search for groups, returned 1 results. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > >domain SID from [(null)] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_nested_group_recv] (0x0400): 0 users found in the hash table > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_nested_group_recv] (0x0400): 1 groups found in the hash table > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_primary_name] (0x0400): Processing object test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] > >(0x0400): Processing group test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > >domain SID from [(null)] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_process_ghost_members] (0x0400): The group has 0 members > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_process_ghost_members] (0x0400): Group has 0 members > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] > >(0x0400): Storing info for group test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_primary_name] (0x0400): Processing object test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] > >(0x0400): Processing group test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] > >(0x0400): Failed to get group sid > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] > >(0x0400): No members for group [test] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > >[(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:test.example.com:b8e22526-f4c0-11e4-8865-005056a8f368))][cn=Default > >Trust View,cn=views,cn=accounts,dc=test,dc=example,dc=com]. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[sdap_get_generic_op_finished] (0x0400): Search result: No such object(32), > >no errmsg set > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [acctinfo_callback] > >(0x0100): Request processed. Returned 0,0,Success > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] > >(0x0400): Changing request domain from [test.example.com] to [ > >test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_pam_handler] > >(0x0100): Got request with the following data > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): command: PAM_AUTHENTICATE > Here just authentication was performed. > It coresponds to the line "auth required pam_sss.so" in your pam stack. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): domain: test.example.com > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): user: test > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): service: tac_plus > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): tty: > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): ruser: > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): rhost: > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): authtok type: 1 > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): newauthtok type: 0 > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): priv: 1 > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): cli_pid: 29218 > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > >(0x0100): logon name: not set > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[be_resolve_server_process] (0x0200): Found address for server > >freeipa.test.example.com: [172.21.0.20] TTL 7200 > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[write_pipe_handler] (0x0400): All data has been sent! > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [child_sig_handler] > >(0x0100): child [29226] finished successfully. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [read_pipe_handler] > >(0x0400): EOF received, client finished > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[fo_set_port_status] (0x0100): Marking port 0 of server ' > >freeipa.test.example.com' as 'working' > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[set_server_common_status] (0x0100): Marking server ' > >freeipa.test.example.com' as 'working' > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[fo_set_port_status] (0x0400): Marking port 0 of duplicate server ' > >freeipa.test.example.com' as 'working' > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) > >[Success] > ^^^^^^^^ > Result of authentication is "Success" which means that password is correct. > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[be_pam_handler_callback] (0x0100): Sending result [0][test.example.com] > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > >[be_pam_handler_callback] (0x0100): Sent result [0][test.example.com] > > > > I could not see authorisation phase; neither in sssd_pam log nor in > sssd_$domain.log. > > It means that you either shared just part of log file or that > your application did not reach/try line "account" in pam stack > "account required pam_sss.so" > In this case you would able to see PAM_ACCT_MGMT in log files. > > sssd seems to work as expected. I found the following on http://www.shrubbery.net/tac_plus/PAM_guide.txt: "Currently, tac_plus only allows authentication using pam (since pam is only used for authentication anyway). Authorizations are still configured within the conf file, no ldap groups allowed :(" So it is not expected that tac_plus does only authentication and not access control via PAM. HTH bye, Sumit > > LS > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From sbose at redhat.com Mon May 11 15:22:29 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 11 May 2015 17:22:29 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: <20150511151531.GL6227@p.redhat.com> References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> <20150511144700.GJ2628@mail.corp.redhat.com> <20150511151531.GL6227@p.redhat.com> Message-ID: <20150511152229.GM6227@p.redhat.com> On Mon, May 11, 2015 at 05:15:31PM +0200, Sumit Bose wrote: > On Mon, May 11, 2015 at 04:47:01PM +0200, Lukas Slebodnik wrote: > > On (11/05/15 14:57), Vangass wrote: > > >Hi, > > > > > >I try to access Cisco switch via ssh. Cisco has tacacs login configured. > > > > > ># tail /var/log/secure > > >May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): > > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= > > >user=bartosz > > >May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): > > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost= > > >user=test > > > > > >User bartosz is added in HBAC rule as Specified Users and Groups. > > >User test exist in FreeIPA but isn't in HBAC rule and shouldn't be > > >autheniticated. > > > > > ># cat /etc/sssd/sssd.conf > > >[domain/test.example.com] > > >debug_level = 6 > > >cache_credentials = True > > >krb5_store_password_if_offline = True > > >ipa_domain = test.example.com > > >id_provider = ipa > > >auth_provider = ipa > > >access_provider = ipa > > >ipa_hostname = freeipa.test.example.com > > >chpass_provider = ipa > > >ipa_server = freeipa.test.example.com > > >ipa_server_mode = True > > >ldap_tls_cacert = /etc/ipa/ca.crt > > > > > >[sssd] > > >services = nss, sudo, pam, ssh > > >config_file_version = 2 > > >domains = test.example.com > > > > > >[nss] > > >homedir_substring = /home > > > > > >[pam] > > >debug_level = 6 > > >domains = test.example.com > > > > > >[sudo] > > > > > >[autofs] > > > > > >[ssh] > > > > > >[pac] > > > > > >[ifp] > > > > > > > > >#cat /var/log/sssd/sssd_pam.log > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): Client > > >connected to privileged pipe! > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > > >Received client version [3]. > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > > >Offered version [3]. > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): > > >entering pam_cmd_authenticate > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains] > > >(0x0200): name 'test' matched without domain, user is test > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > > >PAM_AUTHENTICATE > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > > >not set > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > > >tac_plus > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not > > >set > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > > >not set > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > > >not set > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > > >type: 1 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > > >newauthtok type: 0 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > > >29218 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon > > >name: test > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400): > > >Issuing request for [0x7f4f20215ed0:3:test at test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): > > >Creating request for [test.example.com][3][1][name=test] > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): > > >Entering request [0x7f4f20215ed0:3:test at test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > > >Requesting info for [test at test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0400): > > >Returning info for user [test at test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > > >request with the following data: > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > > >PAM_AUTHENTICATE > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > > >test.example.com > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > > >tac_plus > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not > > >set > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > > >not set > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > > >not set > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > > >type: 1 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > > >newauthtok type: 0 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > > >29218 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon > > >name: test > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > > >pam_dp_send_req returned 0 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): > > >Deleting request: [0x7f4f20215ed0:3:test at test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > > >received: [0][test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > > >called with result [0]. > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > > >called with result [0]. > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 81 > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [client_recv] (0x0200): Client > > >disconnected! > > > > > ># cat /var/log/sssd/sssd_test.example.com.log > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[be_get_account_info] (0x0200): Got request for [0x3][1][name=test] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] > > >(0x0400): Changing request domain from [test.example.com] to [ > > >test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > >domain SID from [(null)] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > >domain SID from [(null)] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_initgr_next_base] (0x0400): Searching for users with base > > >[cn=accounts,dc=test,dc=example,dc=com] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > >[(&(uid=test)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > >errmsg set > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > > >(0x0400): Save user > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_primary_name] (0x0400): Processing object test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > > >(0x0400): Processing user test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > >domain SID from [(null)] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > > >(0x0400): Adding original memberOf attributes to [test]. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > > >(0x0400): Adding user principal [test at TEST.EXAMPLE.COM] to attributes of > > >[test]. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_user] > > >(0x0400): Storing info for user test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_primary_name] (0x0400): Processing object test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > >[(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=ipausers,cn=groups,cn=accounts,dc=test,dc=example,dc=com]. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > >errmsg set > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_primary_name] (0x0400): Processing object ipausers > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > >domain SID from [(null)] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_groups_next_base] (0x0400): Searching for groups with base > > >[cn=accounts,dc=test,dc=example,dc=com] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > >[(&(gidNumber=732000003)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > >errmsg set > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_groups_process] (0x0400): Search for groups, returned 1 results. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > >domain SID from [(null)] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_nested_group_recv] (0x0400): 0 users found in the hash table > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_nested_group_recv] (0x0400): 1 groups found in the hash table > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_primary_name] (0x0400): Processing object test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] > > >(0x0400): Processing group test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > >domain SID from [(null)] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_process_ghost_members] (0x0400): The group has 0 members > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_process_ghost_members] (0x0400): Group has 0 members > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_group] > > >(0x0400): Storing info for group test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_primary_name] (0x0400): Processing object test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] > > >(0x0400): Processing group test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] > > >(0x0400): Failed to get group sid > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [sdap_save_grpmem] > > >(0x0400): No members for group [test] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > >[(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:test.example.com:b8e22526-f4c0-11e4-8865-005056a8f368))][cn=Default > > >Trust View,cn=views,cn=accounts,dc=test,dc=example,dc=com]. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[sdap_get_generic_op_finished] (0x0400): Search result: No such object(32), > > >no errmsg set > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [acctinfo_callback] > > >(0x0100): Request processed. Returned 0,0,Success > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_req_set_domain] > > >(0x0400): Changing request domain from [test.example.com] to [ > > >test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [be_pam_handler] > > >(0x0100): Got request with the following data > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): command: PAM_AUTHENTICATE > > Here just authentication was performed. > > It coresponds to the line "auth required pam_sss.so" in your pam stack. > > > > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): domain: test.example.com > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): user: test > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): service: tac_plus > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): tty: > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): ruser: > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): rhost: > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): authtok type: 1 > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): newauthtok type: 0 > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): priv: 1 > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): cli_pid: 29218 > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [pam_print_data] > > >(0x0100): logon name: not set > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[be_resolve_server_process] (0x0200): Found address for server > > >freeipa.test.example.com: [172.21.0.20] TTL 7200 > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[write_pipe_handler] (0x0400): All data has been sent! > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [child_sig_handler] > > >(0x0100): child [29226] finished successfully. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] [read_pipe_handler] > > >(0x0400): EOF received, client finished > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[fo_set_port_status] (0x0100): Marking port 0 of server ' > > >freeipa.test.example.com' as 'working' > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[set_server_common_status] (0x0100): Marking server ' > > >freeipa.test.example.com' as 'working' > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[fo_set_port_status] (0x0400): Marking port 0 of duplicate server ' > > >freeipa.test.example.com' as 'working' > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) > > >[Success] > > ^^^^^^^^ > > Result of authentication is "Success" which means that password is correct. > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[be_pam_handler_callback] (0x0100): Sending result [0][test.example.com] > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > >[be_pam_handler_callback] (0x0100): Sent result [0][test.example.com] > > > > > > > I could not see authorisation phase; neither in sssd_pam log nor in > > sssd_$domain.log. > > > > It means that you either shared just part of log file or that > > your application did not reach/try line "account" in pam stack > > "account required pam_sss.so" > > In this case you would able to see PAM_ACCT_MGMT in log files. > > > > sssd seems to work as expected. > > I found the following on > http://www.shrubbery.net/tac_plus/PAM_guide.txt: > > "Currently, tac_plus only allows authentication using pam (since pam is > only used for authentication anyway). Authorizations are still > configured within the conf file, no ldap groups allowed :(" > > So it is not expected that tac_plus does only authentication and not > access control via PAM. I just checked the sources in tacacs-F4.0.4.28.tar.gz, only pam_authenticate is called and not pam_acct_mgmt. bye, Sumit > > HTH > > bye, > Sumit > > > > > LS > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -- > 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 From dpal at redhat.com Mon May 11 15:35:30 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 May 2015 11:35:30 -0400 Subject: [Freeipa-users] some documentation issues In-Reply-To: <5550B443.9080704@redhat.com> References: <1431348688.2040.3.camel@deus.pro> <5550B443.9080704@redhat.com> Message-ID: <5550CC42.2090204@redhat.com> On 05/11/2015 09:53 AM, Petr Spacek wrote: > On 11.5.2015 14:51, Arthur Fayzullin wrote: >> Have a nice day! >> >> I think that I have found somethings that are mispresent and unpresent in documentation. >> I have tried to configure debian jessie as a freeipa client. This has been done in 2 ways: >> >> * reference instalation: >> I have installed freeipa-client package from sid and configured host by running ipa-client-install command. >> >> * manual instalation: >> I have installed packages that've been installed as dependencies during reference installation. And I have done steps described here: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/linux-manual.html >> Evrything seems to work fine (and even sudo rules) exept 1 thing: I could not get host certificate by certmonger. >> comparing to reference installation I have found that ipa-client-install also makes 1 more config file: >> /etc/ipa/default.conf >> but this step is not described in documentation. so this is unpresent. >> Another thing that I think is present with mistake: >> according to documentation I should give this command to get host-certificate: >> >> # ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM' >> >> and we can see that 'HOST' is capitalised, but it should in small letters. >> >> Thanks for reading! > Thank you for bug reports! > > Could you please send patches which fix these problems? (Preferably separate > patch for each problem.) > > Necessary links are here: > http://www.freeipa.org/page/Contribute/Documentation > > If you do not want to fix it yourself please open a bug to make sure that > documentation team will not forget to fix it: > > https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=doc-Linux_Domain_Identity_Management_Guide > > Thank you and have a nice day! > AFAIR some time ago we stopped fetching host cert by default. There was no use of it so we decided not issue a cert that has not practical use. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From vangass at gazeta.pl Mon May 11 18:52:08 2015 From: vangass at gazeta.pl (Vangass) Date: Mon, 11 May 2015 20:52:08 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: <20150511152229.GM6227@p.redhat.com> References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> <20150511144700.GJ2628@mail.corp.redhat.com> <20150511151531.GL6227@p.redhat.com> <20150511152229.GM6227@p.redhat.com> Message-ID: OK. But the answer granted/declined comes from IPA. So why IPA doesn't check its own HBAC rules at all? Maybe the line 'account required pam_sss.so' isn't necessary/required. I just want to do authentication by IPA HBAC rules. Thanks, Bartek. 2015-05-11 17:22 GMT+02:00 Sumit Bose : > On Mon, May 11, 2015 at 05:15:31PM +0200, Sumit Bose wrote: > > On Mon, May 11, 2015 at 04:47:01PM +0200, Lukas Slebodnik wrote: > > > On (11/05/15 14:57), Vangass wrote: > > > >Hi, > > > > > > > >I try to access Cisco switch via ssh. Cisco has tacacs login > configured. > > > > > > > ># tail /var/log/secure > > > >May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): > > > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= > rhost= > > > >user=bartosz > > > >May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth): > > > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= > rhost= > > > >user=test > > > > > > > >User bartosz is added in HBAC rule as Specified Users and Groups. > > > >User test exist in FreeIPA but isn't in HBAC rule and shouldn't be > > > >autheniticated. > > > > > > > ># cat /etc/sssd/sssd.conf > > > >[domain/test.example.com] > > > >debug_level = 6 > > > >cache_credentials = True > > > >krb5_store_password_if_offline = True > > > >ipa_domain = test.example.com > > > >id_provider = ipa > > > >auth_provider = ipa > > > >access_provider = ipa > > > >ipa_hostname = freeipa.test.example.com > > > >chpass_provider = ipa > > > >ipa_server = freeipa.test.example.com > > > >ipa_server_mode = True > > > >ldap_tls_cacert = /etc/ipa/ca.crt > > > > > > > >[sssd] > > > >services = nss, sudo, pam, ssh > > > >config_file_version = 2 > > > >domains = test.example.com > > > > > > > >[nss] > > > >homedir_substring = /home > > > > > > > >[pam] > > > >debug_level = 6 > > > >domains = test.example.com > > > > > > > >[sudo] > > > > > > > >[autofs] > > > > > > > >[ssh] > > > > > > > >[pac] > > > > > > > >[ifp] > > > > > > > > > > > >#cat /var/log/sssd/sssd_pam.log > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): > Client > > > >connected to privileged pipe! > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > > > >Received client version [3]. > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > > > >Offered version [3]. > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] > (0x0100): > > > >entering pam_cmd_authenticate > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains] > > > >(0x0200): name 'test' matched without domain, user is test > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > command: > > > >PAM_AUTHENTICATE > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > domain: > > > >not set > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > user: test > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > service: > > > >tac_plus > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > tty: not > > > >set > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > ruser: > > > >not set > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > rhost: > > > >not set > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > authtok > > > >type: 1 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > > > >newauthtok type: 0 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > priv: 1 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > cli_pid: > > > >29218 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > logon > > > >name: test > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] > (0x0400): > > > >Issuing request for [0x7f4f20215ed0:3:test at test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] > (0x0400): > > > >Creating request for [test.example.com][3][1][name=test] > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] > (0x0400): > > > >Entering request [0x7f4f20215ed0:3:test at test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] > (0x0100): > > > >Requesting info for [test at test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] > (0x0400): > > > >Returning info for user [test at test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): > Sending > > > >request with the following data: > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > command: > > > >PAM_AUTHENTICATE > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > domain: > > > >test.example.com > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > user: test > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > service: > > > >tac_plus > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > tty: not > > > >set > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > ruser: > > > >not set > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > rhost: > > > >not set > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > authtok > > > >type: 1 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > > > >newauthtok type: 0 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > priv: 1 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > cli_pid: > > > >29218 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): > logon > > > >name: test > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > > > >pam_dp_send_req returned 0 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_req_destructor] > (0x0400): > > > >Deleting request: [0x7f4f20215ed0:3:test at test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_process_reply] > (0x0100): > > > >received: [0][test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > > > >called with result [0]. > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > > > >called with result [0]. > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 81 > > > >(Mon May 11 14:40:28 2015) [sssd[pam]] [client_recv] (0x0200): Client > > > >disconnected! > > > > > > > ># cat /var/log/sssd/sssd_test.example.com.log > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[be_get_account_info] (0x0200): Got request for [0x3][1][name=test] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [be_req_set_domain] > > > >(0x0400): Changing request domain from [test.example.com] to [ > > > >test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > > >domain SID from [(null)] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > > >domain SID from [(null)] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_initgr_next_base] (0x0400): Searching for users with base > > > >[cn=accounts,dc=test,dc=example,dc=com] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > > > >[(&(uid=test)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > > >errmsg set > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_user] > > > >(0x0400): Save user > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_primary_name] (0x0400): Processing object test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_user] > > > >(0x0400): Processing user test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > > >domain SID from [(null)] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_user] > > > >(0x0400): Adding original memberOf attributes to [test]. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_user] > > > >(0x0400): Adding user principal [test at TEST.EXAMPLE.COM] to > attributes of > > > >[test]. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_user] > > > >(0x0400): Storing info for user test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_primary_name] (0x0400): Processing object test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_has_deref_support] (0x0400): The server supports deref method > OpenLDAP > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > > > >[(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=ipausers,cn=groups,cn=accounts,dc=test,dc=example,dc=com]. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > > >errmsg set > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_primary_name] (0x0400): Processing object ipausers > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > > >domain SID from [(null)] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_groups_next_base] (0x0400): Searching for groups with base > > > >[cn=accounts,dc=test,dc=example,dc=com] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > > >[(&(gidNumber=732000003 > )(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=test,dc=example,dc=com]. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > > >errmsg set > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_groups_process] (0x0400): Search for groups, returned 1 > results. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_has_deref_support] (0x0400): The server supports deref method > OpenLDAP > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > > >domain SID from [(null)] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_nested_group_recv] (0x0400): 0 users found in the hash table > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_nested_group_recv] (0x0400): 1 groups found in the hash table > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_primary_name] (0x0400): Processing object test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_group] > > > >(0x0400): Processing group test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > > >domain SID from [(null)] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_process_ghost_members] (0x0400): The group has 0 members > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_process_ghost_members] (0x0400): Group has 0 members > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_group] > > > >(0x0400): Storing info for group test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_primary_name] (0x0400): Processing object test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_grpmem] > > > >(0x0400): Processing group test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_grpmem] > > > >(0x0400): Failed to get group sid > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [sdap_save_grpmem] > > > >(0x0400): No members for group [test] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > > > >[(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:test.example.com: > b8e22526-f4c0-11e4-8865-005056a8f368))][cn=Default > > > >Trust View,cn=views,cn=accounts,dc=test,dc=example,dc=com]. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[sdap_get_generic_op_finished] (0x0400): Search result: No such > object(32), > > > >no errmsg set > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [acctinfo_callback] > > > >(0x0100): Request processed. Returned 0,0,Success > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [be_req_set_domain] > > > >(0x0400): Changing request domain from [test.example.com] to [ > > > >test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [be_pam_handler] > > > >(0x0100): Got request with the following data > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): command: PAM_AUTHENTICATE > > > Here just authentication was performed. > > > It coresponds to the line "auth required pam_sss.so" in your pam > stack. > > > > > > > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): domain: test.example.com > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): user: test > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): service: tac_plus > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): tty: > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): ruser: > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): rhost: > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): authtok type: 1 > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): newauthtok type: 0 > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): priv: 1 > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): cli_pid: 29218 > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [pam_print_data] > > > >(0x0100): logon name: not set > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[be_resolve_server_process] (0x0200): Found address for server > > > >freeipa.test.example.com: [172.21.0.20] TTL 7200 > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[write_pipe_handler] (0x0400): All data has been sent! > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [child_sig_handler] > > > >(0x0100): child [29226] finished successfully. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > [read_pipe_handler] > > > >(0x0400): EOF received, client finished > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[fo_set_port_status] (0x0100): Marking port 0 of server ' > > > >freeipa.test.example.com' as 'working' > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[set_server_common_status] (0x0100): Marking server ' > > > >freeipa.test.example.com' as 'working' > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[fo_set_port_status] (0x0400): Marking port 0 of duplicate server ' > > > >freeipa.test.example.com' as 'working' > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) > > > >[Success] > > > ^^^^^^^^ > > > Result of authentication is "Success" which means that password is > correct. > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[be_pam_handler_callback] (0x0100): Sending result [0][ > test.example.com] > > > >(Mon May 11 14:40:28 2015) [sssd[be[test.example.com]]] > > > >[be_pam_handler_callback] (0x0100): Sent result [0][test.example.com] > > > > > > > > > > I could not see authorisation phase; neither in sssd_pam log nor in > > > sssd_$domain.log. > > > > > > It means that you either shared just part of log file or that > > > your application did not reach/try line "account" in pam stack > > > "account required pam_sss.so" > > > In this case you would able to see PAM_ACCT_MGMT in log files. > > > > > > sssd seems to work as expected. > > > > I found the following on > > http://www.shrubbery.net/tac_plus/PAM_guide.txt: > > > > "Currently, tac_plus only allows authentication using pam (since pam is > > only used for authentication anyway). Authorizations are still > > configured within the conf file, no ldap groups allowed :(" > > > > So it is not expected that tac_plus does only authentication and not > > access control via PAM. > > I just checked the sources in tacacs-F4.0.4.28.tar.gz, only > pam_authenticate is called and not pam_acct_mgmt. > > bye, > Sumit > > > > HTH > > > > bye, > > Sumit > > > > > > > > LS > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go to http://freeipa.org for more info on the project > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon May 11 19:04:14 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 May 2015 22:04:14 +0300 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> <20150511144700.GJ2628@mail.corp.redhat.com> <20150511151531.GL6227@p.redhat.com> <20150511152229.GM6227@p.redhat.com> Message-ID: <20150511190414.GE5152@redhat.com> On Mon, 11 May 2015, Vangass wrote: >OK. But the answer granted/declined comes from IPA. So why IPA doesn't >check its own HBAC rules at all? >Maybe the line 'account required pam_sss.so' isn't >necessary/required. I just want to do authentication by IPA HBAC rules. Authentication and account management stages are different in PAM. When authentication is performed, it is separate step. When account management is performed, it is a separate step as well. HBAC rules are checked at account management stage because this is where all such checks are done traditionally in PAM. If you read documentation[1], it states: ======================================================================= The pam_acct_mgmt function is used to determine if the users account is valid. It checks for authentication token and account expiration and verifies access restrictions. It is typically called after the user has been authenticated. ======================================================================= If application doesn't call into pam_acct_mgmt, it is not using PAM stack separation of duties properly. [1] http://linux.die.net/man/3/pam_acct_mgmt -- / Alexander Bokovoy From john.obaterspok at gmail.com Mon May 11 19:42:17 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 11 May 2015 21:42:17 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: <20150510170228.GM38847@Jakubs-MacBook-Pro.local> References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> <20150510170228.GM38847@Jakubs-MacBook-Pro.local> Message-ID: I have about the same setup: This is the setup (everything is up-to-date): - ipa-server: F21, ipa-server 4.1, samba 4.1 - win-client: Windows 7 Home Premium I tried to enroll the win-client in the domain but failed on the windows side due to home editions not being able to join a domain. But I can still access shares from the win-client by user/pwd The only difference in my setup is that I use samba server on the ipa-server itself. -- john 2015-05-10 19:02 GMT+02:00 Jakub Hrozek : > On Thu, May 07, 2015 at 03:30:06PM +0100, Dylan Evans wrote: > > By coincidence I posted a very similar question yesterday - > > https://www.redhat.com/archives/freeipa-users/2015-May/msg00103.html. > > > > +1 for the necessary support for out-of-domain Windows clients and > NTLMSSP. > > > > Is there a time-table for this? > > It is a nice-to-have feature for the next SSSD version (1.13, this > summber), > but my hopes are not high that we're going to make it. I think 1.14 is more > realistic. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur at deus.pro Tue May 12 04:20:16 2015 From: arthur at deus.pro (Arthur Fayzullin) Date: Tue, 12 May 2015 09:20:16 +0500 Subject: [Freeipa-users] some documentation issues In-Reply-To: <5550CC42.2090204@redhat.com> References: <1431348688.2040.3.camel@deus.pro> <5550B443.9080704@redhat.com> <5550CC42.2090204@redhat.com> Message-ID: <1431404416.2040.4.camel@deus.pro> ? ??, 11/05/2015 ? 11:35 -0400, Dmitri Pal ?????: > AFAIR some time ago we stopped fetching host cert by default. There was > no use of it so we decided not issue a cert that has not practical use. > > -- > Thank you, > Dmitri Pal > > Director of Engineering for IdM portfolio > Red Hat, Inc. > Yes, I have noticed it from reference debian instalation and from EL7&fedora instalation. But this step is present in documentation, and it containes mistake. Also, I have one question about /etc/ipa/default.conf file. it looks something like this: [global] basedn = dc=,dc= realm = domain = server = . xmlrpc_uri = https://./ipa/xml enable_ra = True is there any way to configure it for HA? in case I will get one freeipa server replica down. From abokovoy at redhat.com Tue May 12 05:41:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 08:41:22 +0300 Subject: [Freeipa-users] some documentation issues In-Reply-To: <1431404416.2040.4.camel@deus.pro> References: <1431348688.2040.3.camel@deus.pro> <5550B443.9080704@redhat.com> <5550CC42.2090204@redhat.com> <1431404416.2040.4.camel@deus.pro> Message-ID: <20150512054122.GG5152@redhat.com> On Tue, 12 May 2015, Arthur Fayzullin wrote: >? ??, 11/05/2015 ? 11:35 -0400, Dmitri Pal ?????: >> AFAIR some time ago we stopped fetching host cert by default. There was >> no use of it so we decided not issue a cert that has not practical use. >> >> -- >> Thank you, >> Dmitri Pal >> >> Director of Engineering for IdM portfolio >> Red Hat, Inc. >> > >Yes, I have noticed it from reference debian instalation and from >EL7&fedora instalation. But this step is present in documentation, and >it containes mistake. Please file a documentation bug. >Also, I have one question about >/etc/ipa/default.conf >file. > >it looks something like this: >[global] >basedn = dc=,dc= >realm = >domain = >server = . >xmlrpc_uri = https://./ipa/xml >enable_ra = True > >is there any way to configure it for HA? in case I will get one freeipa >server replica down. IPA command line tools are using SRV records for _ldap._tcp.$DOMAIN to find out list of servers to talk to. The server specified in default.conf is used first but if it fails, connection attempts continue through the list of servers discovered via SRV records. So, you don't need to change anything. -- / Alexander Bokovoy From mkosek at redhat.com Tue May 12 06:23:04 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 May 2015 08:23:04 +0200 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <5550C748.3090903@lyra-network.com> References: <5550C748.3090903@lyra-network.com> Message-ID: <55519C48.1010904@redhat.com> On 05/11/2015 05:14 PM, Thibaut Pouzet wrote: > Hi ! > > I am running into a weird problem with my IPA Server, and the > certificates management. My setup is : > CentOS 6.6 > pki-ca-9.0.3-38.el6_6.noarch > ipa-server-3.0.0-42.el6.centos.x86_64 > Linux ipa_server 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > The server has been installed two years ago, and all the certificates on > the master server expired this month. (2 year validity). Apparently, > they were not properly tracked by certmonger, so they were not renewed. > > By doing some getcert stop-tracking, then getcert start-tracking xxxx, I > was able to track 8 of the 9 certificates that I can display with > getcert list on this server. > > There is one that remains expired, despite all the efforts I put into > renewing it. This is the one used for the pki-ca administration pages > reachable on ports 9443, 9444 and 9445. Here is its status after trying > to resubmit it : > getcert resubmit -i 20150511145941 -K HTTP/ipa_server > getcert list -i 20150511145941 > > Number of certificates and requests being tracked: 9. > Request ID '20150511145941': > status: CA_UNREACHABLE > ca-error: Server at https://ipa_server/ipa/xml failed request, > will retry: 4301 (RPC failed at server. Certificate operation cannot be > completed: FAILURE (Invalid Request)). > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin='1234' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=ipa_domain > subject: CN=ipa_server,O=ipa_domain > expires: 2015-04-09 04:58:33 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > I tried to stop tracking it, and then tracking it again, with no luck : > getcert start-tracking -d "/var/lib/pki-ca/alias" -n "subsystemCert > cert-pki-ca" -t "NSS Certificate DB" -P 1234 -r -c IPA > > I changed the trust settings as well, still not working : > sh-4.1# certutil -M -n "Server-Cert cert-pki-ca" -d > /var/lib/pki-ca/alias -t u,u,Pu > > sh-4.1# certutil -L -d /var/lib/pki-ca/alias > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > ocspSigningCert cert-pki-ca u,u,u > subsystemCert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > caSigningCert cert-pki-ca CTu,Cu,Cu > Server-Cert cert-pki-ca u,u,Pu > > However, I find this error in different places : > ca-error: Server at "http://ipa_server:9180/ca/ee/ca/profileSubmit" > replied: Invalid Request > > sh-4.1# ipa user-show admin > ipa: ERROR: Missing or invalid HTTP Referer, https://ipa_server/ipa/xml > > Sometimes, I also get it with "ipa cert-show 1", sometimes I don't. > > Sometimes its status changes even though I don't think I've done anything : > ca-error: Server at https://ipa_server/ipa/xml failed request, will > retry: 911 (RPC failed at server. Missing or invalid HTTP Referer, > https://ipa_server/ipa/xml). > > And I can find inside /var/log/pki-ca/debug these lines : > [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10: > signature verification enabled > [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10 > org.mozilla.jss.NoSuchTokenException > [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10 > restoring thread token > Invalid Request > at > com.netscape.cms.profile.common.EnrollProfile.parsePKCS10(EnrollProfile.java:953) > at > com.netscape.cms.profile.common.EnrollProfile.createRequests(EnrollProfile.java:102) > at > com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:1001) > at > com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:501) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFilter.java:176) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:701) > > > There is the BLOB inside the logs, containing the CSR, and I can read it > with openssl so it is correctly formatted : > > Certificate Request: > Data: > Version: 0 (0x0) > Subject: O=ipa_domain, CN=ipa_server > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: > 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: > 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: > 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: > 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: > 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: > 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: > d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: > 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: > 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: > f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: > c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: > 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: > b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: > 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: > 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: > 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: > 1b:fb > Exponent: 65537 (0x10001) > Attributes: > friendlyName :unable to print attribute > Requested Extensions: > X509v3 Key Usage: > Digital Signature, Non Repudiation, Key Encipherment, > Data Encipherment > X509v3 Subject Alternative Name: > othername:, othername: > X509v3 Extended Key Usage: > TLS Web Server Authentication > X509v3 Basic Constraints: critical > CA:FALSE > X509v3 Subject Key Identifier: > 2E:41:D7:91:F0:F4:AA:F6:3D:C0:0C:6B:89:DB:23:6C:90:DA:0E:C7 > Signature Algorithm: sha256WithRSAEncryption > 53:36:9a:b6:e8:90:a1:3f:99:cf:85:64:9d:1c:ff:40:ad:f4: > 31:53:03:81:0c:37:5e:3d:d2:a2:c1:fb:1c:6c:68:f9:c8:cd: > b9:45:38:be:b1:17:ac:63:7b:a7:46:ca:64:1a:d3:4a:c2:63: > ca:64:ca:39:01:e4:5f:3b:6c:86:de:23:0e:12:04:be:2b:f7: > 22:1c:ac:0f:91:56:87:b2:95:20:a6:2d:10:f9:98:e5:51:46: > c8:b0:71:20:85:98:a3:35:c4:ef:fd:55:20:5e:a9:01:ed:3b: > 99:5f:43:8a:85:b1:c7:3d:94:1d:d6:4b:87:3b:1a:72:c4:7b: > 35:5c:65:11:e2:7f:ba:72:d8:63:ab:f6:a1:6f:b0:73:0b:c5: > c7:ca:2a:da:eb:b3:d0:64:75:7d:c3:9a:f5:b3:e7:d1:7b:e2: > b0:ab:68:87:a2:fd:71:19:92:49:b5:e0:72:32:d8:cd:b7:f3: > c9:a2:92:0d:20:65:c7:4a:5a:e7:d4:2a:e5:50:f1:63:44:97: > 2c:c5:27:c4:2e:38:be:4f:02:33:91:f5:7d:2d:ab:75:7b:09: > f7:86:0d:ac:3b:b7:c9:5e:00:96:49:e4:b1:f5:19:d2:1b:e6: > 68:d6:e9:51:5b:9b:ec:d4:b3:e6:fd:e3:ee:7f:84:c3:e6:9b: > cb:11:d8:48 > > And here I am, with this expired certificate still being served on my > server... > > If anyone has any clue on what's going on, I would be really grateful ! > > Cheers, > Thanks for the report. This is out of my expertise unfortunately, I am CCing developers from Dogtag, hoping they can help. From jpazdziora at redhat.com Tue May 12 07:39:49 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 12 May 2015 09:39:49 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> <20150511144700.GJ2628@mail.corp.redhat.com> <20150511151531.GL6227@p.redhat.com> <20150511152229.GM6227@p.redhat.com> Message-ID: <20150512073949.GJ6587@redhat.com> On Mon, May 11, 2015 at 08:52:08PM +0200, Vangass wrote: > OK. But the answer granted/declined comes from IPA. So why IPA doesn't > check its own HBAC rules at all? > Maybe the line 'account required pam_sss.so' isn't > necessary/required. I just want to do authentication by IPA HBAC rules. Note that you can have setups when you don't authenticate via PAM at all (for example when using Kerberos) yet you do authorization (access control) using PAM. Authentication is not the correct place to process HBAC rules. In your case, nobody is arguing that the password used was correct -- authentication passed, the identity of the client was validated. The application (tacacs) is supposed to do additional step, now that it knows what user is attempting to log in -- verify authorization, fact that the known user should be allowed in, with pam_acct_mgmt. That's the why. You could in theory force it to work by writing a wrapper PAM module which would call both pam_sss's pam_sm_authenticate *and* pam_sm_acct_mgmt for its pam_sm_authenticate call. But it would be a hack, possibly with unexpected side effects. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From devans01 at gmail.com Tue May 12 11:03:07 2015 From: devans01 at gmail.com (Dylan Evans) Date: Tue, 12 May 2015 12:03:07 +0100 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> <20150510170228.GM38847@Jakubs-MacBook-Pro.local> Message-ID: Hi Jakub, It's good to know it's going to happen, let's hope it gets into 1.13 and everyone has a very productive summer! I've been watching IPA for a couple of years and this is the last thing that's preventing it from being implemented in our production environment. Thanks, Dylan. On 11 May 2015 at 20:42, John Obaterspok wrote: > I have about the same setup: > > This is the setup (everything is up-to-date): > - ipa-server: F21, ipa-server 4.1, samba 4.1 > - win-client: Windows 7 Home Premium > > I tried to enroll the win-client in the domain but failed on the windows > side due to home editions not being able to join a domain. > But I can still access shares from the win-client by user/pwd > > The only difference in my setup is that I use samba server on the ipa-server > itself. > > -- john > > 2015-05-10 19:02 GMT+02:00 Jakub Hrozek : >> >> On Thu, May 07, 2015 at 03:30:06PM +0100, Dylan Evans wrote: >> > By coincidence I posted a very similar question yesterday - >> > https://www.redhat.com/archives/freeipa-users/2015-May/msg00103.html. >> > >> > +1 for the necessary support for out-of-domain Windows clients and >> > NTLMSSP. >> > >> > Is there a time-table for this? >> >> It is a nice-to-have feature for the next SSSD version (1.13, this >> summber), >> but my hopes are not high that we're going to make it. I think 1.14 is >> more >> realistic. >> >> -- >> 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 > > From box31978 at gmail.com Tue May 12 13:39:42 2015 From: box31978 at gmail.com (box 31978) Date: Tue, 12 May 2015 15:39:42 +0200 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> <20150510170228.GM38847@Jakubs-MacBook-Pro.local> Message-ID: Hi all, Thank you very much for all your feedback. John, I've already tried your setup and it works nicely ... but I still need to split services among VMs, so no chance anyway. And I agree with you: it's a must-have feature. As Dylan, it's the last thing that keeps me from moving it to production (and I want it to ;-), but I must admit that design/implementation seems complex as Alexander said. I hope it will be solved ASAP. Thanks! Regards, A. 2015-05-12 13:03 GMT+02:00 Dylan Evans : > Hi Jakub, > > It's good to know it's going to happen, let's hope it gets into 1.13 > and everyone has a very productive summer! > > I've been watching IPA for a couple of years and this is the last > thing that's preventing it from being implemented in our production > environment. > > Thanks, > > Dylan. > > On 11 May 2015 at 20:42, John Obaterspok > wrote: > > I have about the same setup: > > > > This is the setup (everything is up-to-date): > > - ipa-server: F21, ipa-server 4.1, samba 4.1 > > - win-client: Windows 7 Home Premium > > > > I tried to enroll the win-client in the domain but failed on the windows > > side due to home editions not being able to join a domain. > > But I can still access shares from the win-client by user/pwd > > > > The only difference in my setup is that I use samba server on the > ipa-server > > itself. > > > > -- john > > > > 2015-05-10 19:02 GMT+02:00 Jakub Hrozek : > >> > >> On Thu, May 07, 2015 at 03:30:06PM +0100, Dylan Evans wrote: > >> > By coincidence I posted a very similar question yesterday - > >> > https://www.redhat.com/archives/freeipa-users/2015-May/msg00103.html. > >> > > >> > +1 for the necessary support for out-of-domain Windows clients and > >> > NTLMSSP. > >> > > >> > Is there a time-table for this? > >> > >> It is a nice-to-have feature for the next SSSD version (1.13, this > >> summber), > >> but my hopes are not high that we're going to make it. I think 1.14 is > >> more > >> realistic. > >> > >> -- > >> 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue May 12 16:09:52 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 12 May 2015 12:09:52 -0400 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <5550C748.3090903@lyra-network.com> References: <5550C748.3090903@lyra-network.com> Message-ID: <20150512160952.GA23769@redhat.com> On Mon, May 11, 2015 at 05:14:16PM +0200, Thibaut Pouzet wrote: > There is one that remains expired, despite all the efforts I put into > renewing it. This is the one used for the pki-ca administration pages > reachable on ports 9443, 9444 and 9445. Here is its status after trying > to resubmit it : > getcert resubmit -i 20150511145941 -K HTTP/ipa_server > getcert list -i 20150511145941 > > Number of certificates and requests being tracked: 9. > Request ID '20150511145941': > status: CA_UNREACHABLE > ca-error: Server at https://ipa_server/ipa/xml failed request, > will retry: 4301 (RPC failed at server. Certificate operation cannot be > completed: FAILURE (Invalid Request)). > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin='1234' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=ipa_domain > subject: CN=ipa_server,O=ipa_domain > expires: 2015-04-09 04:58:33 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes The request settings you've got there don't quite look like the settings for the certificate I have in the same place on my system. The CA we use for that one is usually 'dogtag-ipa-renew-agent', and since it's a CA-specific certificate (i.e., internal to Dogtag) rather than a full-blown IPA-managed service, I wouldn't expect it to have a Kerberos principal name associated with it. Can you try getcert resubmit -d /var/lib/pki-ca/alias -n 'Server-Cert cert-pki-ca' -c dogtag-ipa-renew-agent -K "" to change both the CA which is used, and to remove the principal name from the signing request? My IPA server (the same version of both it and Dogtag that you're running) didn't complain when I tried it the way you're doing it, so if the "invalid token" exception is being caused by something else, then this might not help. But we can at least rule these things out. One other thing I would check is if the PIN that certmonger has for the certificate's private key matches the value listed for "internal" (not "internaldb") in /var/lib/pki-ca/conf/password.conf, and that supplying that value when "certutil -K -d /var/lib/pki-ca/alias" asks for one allows the database to be decrypted so that its contents can be listed. If they don't agree, or certutil fails to list the database's contents, then one or both of them is incorrect about the database's password. HTH, Nalin From thibaut.pouzet at lyra-network.com Tue May 12 16:39:13 2015 From: thibaut.pouzet at lyra-network.com (Thibaut Pouzet) Date: Tue, 12 May 2015 18:39:13 +0200 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <20150512160952.GA23769@redhat.com> References: <5550C748.3090903@lyra-network.com> <20150512160952.GA23769@redhat.com> Message-ID: <55522CB1.2090805@lyra-network.com> Le 12/05/2015 18:09, Nalin Dahyabhai a ?crit : > On Mon, May 11, 2015 at 05:14:16PM +0200, Thibaut Pouzet wrote: >> There is one that remains expired, despite all the efforts I put into >> renewing it. This is the one used for the pki-ca administration pages >> reachable on ports 9443, 9444 and 9445. Here is its status after trying >> to resubmit it : >> getcert resubmit -i 20150511145941 -K HTTP/ipa_server >> getcert list -i 20150511145941 >> >> Number of certificates and requests being tracked: 9. >> Request ID '20150511145941': >> status: CA_UNREACHABLE >> ca-error: Server at https://ipa_server/ipa/xml failed request, >> will retry: 4301 (RPC failed at server. Certificate operation cannot be >> completed: FAILURE (Invalid Request)). >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB',pin='1234' >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=ipa_domain >> subject: CN=ipa_server,O=ipa_domain >> expires: 2015-04-09 04:58:33 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes > > The request settings you've got there don't quite look like the settings > for the certificate I have in the same place on my system. > > The CA we use for that one is usually 'dogtag-ipa-renew-agent', and > since it's a CA-specific certificate (i.e., internal to Dogtag) rather > than a full-blown IPA-managed service, I wouldn't expect it to have a > Kerberos principal name associated with it. > > Can you try > > getcert resubmit -d /var/lib/pki-ca/alias -n 'Server-Cert cert-pki-ca' -c dogtag-ipa-renew-agent -K "" After running this request for the first time, I have this output : Request ID '20150511145941': status: NEED_TO_SUBMIT ca-error: Error 7 connecting to http://ipa_server:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='1234' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=ipa_domain subject: CN=ipa_server,O=ipa_domain expires: 2015-04-09 04:58:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes > > to change both the CA which is used, and to remove the principal name > from the signing request? > After this, I tried to resubmit it, and got this status : Request ID '20150511145941': status: MONITORING ca-error: Server at "http://ipa_server:9180/ca/ee/ca/profileSubmit" replied: Invalid Request stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='1234' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=ipa_domain subject: CN=ipa_server,O=ipa_domain expires: 2015-04-09 04:58:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes I ran your command a second time ('just to be sure'), and did not got the "Couldn't connect to server" error message, only the "Invalid Request" one in the status of the certificate. > My IPA server (the same version of both it and Dogtag that you're > running) didn't complain when I tried it the way you're doing it, so if > the "invalid token" exception is being caused by something else, then > this might not help. But we can at least rule these things out. > > One other thing I would check is if the PIN that certmonger has for the > certificate's private key matches the value listed for "internal" (not > "internaldb") in /var/lib/pki-ca/conf/password.conf, and that supplying > that value when "certutil -K -d /var/lib/pki-ca/alias" asks for one > allows the database to be decrypted so that its contents can be listed. > If they don't agree, or certutil fails to list the database's contents, > then one or both of them is incorrect about the database's password. > I can read the content of the database using the pin that is inside this file (which is the same pin as the one inside certmonger) > HTH, > > Nalin > After doing what you recommended, the CSR have changed in the debug log : Certificate Request: Data: Version: 0 (0x0) Subject: O=ipa_domain, CN=ipa_server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: 1b:fb Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption 10:ef:cf:ff:6c:63:72:61:c3:b5:5e:8e:b0:20:f0:63:13:43: bb:3b:63:c8:4e:6f:34:63:33:cc:47:af:8a:dc:2d:13:2a:58: 87:7c:d7:5e:e9:b3:e7:f4:47:b7:7b:eb:77:0b:7c:0e:58:20: dd:62:a8:a0:8b:31:1e:54:f0:dd:3f:44:4a:e7:a2:a6:64:85: 9f:10:0e:06:75:33:94:82:f3:8f:89:66:e1:7f:65:21:85:b8: 69:6d:e7:35:a5:a7:08:1d:51:55:48:13:b8:e3:2d:6f:99:c1: ce:1e:81:e3:fb:93:3a:f0:86:0d:43:96:31:93:fb:87:fb:53: 46:02:e1:dd:05:55:85:72:35:fa:72:6d:c6:35:d4:6d:9e:be: db:ee:e6:8c:7b:b1:5a:cd:4d:cc:8e:3e:10:4e:a7:d3:61:36: ae:86:59:df:51:a3:0f:38:79:b8:e0:bd:eb:25:44:a4:43:b0: 93:7f:1e:43:aa:d5:30:d3:e3:a0:bd:ee:08:b7:88:9a:cd:a0: 8c:ac:2a:8f:71:ec:64:70:72:91:f8:d2:e8:55:5b:22:1f:2e: 60:6c:a4:be:ee:42:09:a6:71:25:ec:37:43:a1:e6:15:63:8f: 05:97:61:1d:8e:25:5d:76:df:8b:66:7f:85:27:8b:93:98:a9: 3e:cc:cb:d8 There is no more this weird "friendlyName :unable to print attribute" thing, but the NoSuchTokenException is still in the debug log of pki-ca Thank you for you answer though, we've still made some progress in identifying that I messed the CA used for this certificate ! Cheers -- Thibaut Pouzet Lyra Network Ing?nieur Syst?mes et R?seaux (+33) 5 31 22 40 08 www.lyra-network.com From dpal at redhat.com Tue May 12 16:47:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 May 2015 12:47:58 -0400 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> <20150510170228.GM38847@Jakubs-MacBook-Pro.local> Message-ID: <55522EBE.2000401@redhat.com> On 05/12/2015 07:03 AM, Dylan Evans wrote: > Hi Jakub, > > It's good to know it's going to happen, let's hope it gets into 1.13 > and everyone has a very productive summer! > > I've been watching IPA for a couple of years and this is the last > thing that's preventing it from being implemented in our production > environment. So is this use case the main reason of needing NTLMSSP support or there are some other use cases that drive this requirement? Can you please share them? > Thanks, > > Dylan. > > On 11 May 2015 at 20:42, John Obaterspok wrote: >> I have about the same setup: >> >> This is the setup (everything is up-to-date): >> - ipa-server: F21, ipa-server 4.1, samba 4.1 >> - win-client: Windows 7 Home Premium >> >> I tried to enroll the win-client in the domain but failed on the windows >> side due to home editions not being able to join a domain. >> But I can still access shares from the win-client by user/pwd >> >> The only difference in my setup is that I use samba server on the ipa-server >> itself. >> >> -- john >> >> 2015-05-10 19:02 GMT+02:00 Jakub Hrozek : >>> On Thu, May 07, 2015 at 03:30:06PM +0100, Dylan Evans wrote: >>>> By coincidence I posted a very similar question yesterday - >>>> https://www.redhat.com/archives/freeipa-users/2015-May/msg00103.html. >>>> >>>> +1 for the necessary support for out-of-domain Windows clients and >>>> NTLMSSP. >>>> >>>> Is there a time-table for this? >>> It is a nice-to-have feature for the next SSSD version (1.13, this >>> summber), >>> but my hopes are not high that we're going to make it. I think 1.14 is >>> more >>> realistic. >>> >>> -- >>> 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 >> -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From edewata at redhat.com Tue May 12 17:26:46 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 May 2015 12:26:46 -0500 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <55522CB1.2090805@lyra-network.com> References: <5550C748.3090903@lyra-network.com> <20150512160952.GA23769@redhat.com> <55522CB1.2090805@lyra-network.com> Message-ID: <555237D6.4000209@redhat.com> On 5/12/2015 11:39 AM, Thibaut Pouzet wrote: > There is no more this weird "friendlyName :unable to print > attribute" thing, but the NoSuchTokenException is still in the debug log > of pki-ca Hi, Could you post or email me the CS.cfg and the log files of the CA? Thanks. -- Endi S. Dewata From Joshua.Gould at osumc.edu Tue May 12 17:50:12 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 12 May 2015 13:50:12 -0400 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX Message-ID: We?re using IPA Server 4.1.0-18. We have a trust between IPA and AD with SID mapping. In our setup, AD would be example.com and IPA would be say ipa.example.com. I?m having some issues configuring both RHEL5 and AIX to work with the compat tree. In both cases, kerberos works with IPA and AD users but LDAP only works with IPA users and not AD users. Should AD users be returned if I search uid=AD_user under cn=users,cn=compat,dc=ipa,dc=example,dc=com? Is this where my RHEL5 and AIX clients should be searching? I?m not getting any matches and I?ve verified that the compat plugin is enabled on our servers. I need a little more to go on as far as if I?m looking in the wrong sub-tree or going about this the wrong way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue May 12 18:11:42 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 12 May 2015 14:11:42 -0400 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <55522CB1.2090805@lyra-network.com> References: <5550C748.3090903@lyra-network.com> <20150512160952.GA23769@redhat.com> <55522CB1.2090805@lyra-network.com> Message-ID: <20150512181142.GB23769@redhat.com> On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote: > After doing what you recommended, the CSR have changed in the debug log : > > Certificate Request: > Data: > Version: 0 (0x0) > Subject: O=ipa_domain, CN=ipa_server > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: > 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: > 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: > 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: > 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: > 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: > 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: > d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: > 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: > 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: > f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: > c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: > 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: > b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: > 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: > 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: > 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: > 1b:fb > Exponent: 65537 (0x10001) > Attributes: > a0:00 > Signature Algorithm: sha256WithRSAEncryption > 10:ef:cf:ff:6c:63:72:61:c3:b5:5e:8e:b0:20:f0:63:13:43: > bb:3b:63:c8:4e:6f:34:63:33:cc:47:af:8a:dc:2d:13:2a:58: > 87:7c:d7:5e:e9:b3:e7:f4:47:b7:7b:eb:77:0b:7c:0e:58:20: > dd:62:a8:a0:8b:31:1e:54:f0:dd:3f:44:4a:e7:a2:a6:64:85: > 9f:10:0e:06:75:33:94:82:f3:8f:89:66:e1:7f:65:21:85:b8: > 69:6d:e7:35:a5:a7:08:1d:51:55:48:13:b8:e3:2d:6f:99:c1: > ce:1e:81:e3:fb:93:3a:f0:86:0d:43:96:31:93:fb:87:fb:53: > 46:02:e1:dd:05:55:85:72:35:fa:72:6d:c6:35:d4:6d:9e:be: > db:ee:e6:8c:7b:b1:5a:cd:4d:cc:8e:3e:10:4e:a7:d3:61:36: > ae:86:59:df:51:a3:0f:38:79:b8:e0:bd:eb:25:44:a4:43:b0: > 93:7f:1e:43:aa:d5:30:d3:e3:a0:bd:ee:08:b7:88:9a:cd:a0: > 8c:ac:2a:8f:71:ec:64:70:72:91:f8:d2:e8:55:5b:22:1f:2e: > 60:6c:a4:be:ee:42:09:a6:71:25:ec:37:43:a1:e6:15:63:8f: > 05:97:61:1d:8e:25:5d:76:df:8b:66:7f:85:27:8b:93:98:a9: > 3e:cc:cb:d8 > > There is no more this weird "friendlyName :unable to print > attribute" thing, but the NoSuchTokenException is still in the debug log > of pki-ca > > Thank you for you answer though, we've still made some progress in > identifying that I messed the CA used for this certificate ! Hmm, so what you've got there looks pretty normal for a renewal request. Just to rule out a problem with the request's signature or the encoding of the subject name in the request (the latter is a bug in versions of certmonger before 0.72), can you check the version of the certmonger package and show us the base64-encoded form of the signing request? I'm just about grasping at straws here, but the NoSuchTokenException exception appears to be coming from the jss library, and is thrown when it can't find the software module that is used for accessing the server's keys. Can you verify that your /etc/pki-ca/CS.cfg file contains these lines? jss.configDir=/var/lib/pki-ca/alias/ jss.enable=true jss.secmodName=secmod.db Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg? I don't have one. The Dogtag logic looks like it would try to use one set there rather than the default, but letting it use the default looks like the intended way of doing things. Which version of the jss and tomcatjss packages are installed? I'm using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here. If none of this turns up anything, then I'm going to have to defer to the Dogtag team, too. Nalin From abokovoy at redhat.com Tue May 12 18:14:54 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 21:14:54 +0300 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: References: Message-ID: <20150512181454.GQ5152@redhat.com> On Tue, 12 May 2015, Gould, Joshua wrote: >We?re using IPA Server 4.1.0-18. We have a trust between IPA and AD >with SID mapping. In our setup, AD would be example.com and IPA would >be say ipa.example.com. > >I?m having some issues configuring both RHEL5 and AIX to work with the >compat tree. In both cases, kerberos works with IPA and AD users but >LDAP only works with IPA users and not AD users. > >Should AD users be returned if I search uid=AD_user under >cn=users,cn=compat,dc=ipa,dc=example,dc=com? Is this where my RHEL5 and >AIX clients should be searching? I?m not getting any matches and I?ve >verified that the compat plugin is enabled on our servers. I need a >little more to go on as far as if I?m looking in the wrong sub-tree or >going about this the wrong way. Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a base cn=compat,dc=ipa,dc=example,dc=com. Simple ldapsearch needs to include proper filter, like what SSSD or nss_ldap are using. slapi-nis is programmed to specifically respond to their queries, not to any request over compat tree. If you want to check from the command line, use a filter like (&(uid=AD_user)(objectclass=posixaccount)) -- / Alexander Bokovoy From edewata at redhat.com Tue May 12 19:51:41 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 May 2015 14:51:41 -0500 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <20150512181142.GB23769@redhat.com> References: <5550C748.3090903@lyra-network.com> <20150512160952.GA23769@redhat.com> <55522CB1.2090805@lyra-network.com> <20150512181142.GB23769@redhat.com> Message-ID: <555259CD.9010403@redhat.com> On 5/12/2015 1:11 PM, Nalin Dahyabhai wrote: > On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote: >> There is no more this weird "friendlyName :unable to print >> attribute" thing, but the NoSuchTokenException is still in the debug log >> of pki-ca >> >> Thank you for you answer though, we've still made some progress in >> identifying that I messed the CA used for this certificate ! > > Hmm, so what you've got there looks pretty normal for a renewal request. > Just to rule out a problem with the request's signature or the encoding > of the subject name in the request (the latter is a bug in versions of > certmonger before 0.72), can you check the version of the certmonger > package and show us the base64-encoded form of the signing request? > > I'm just about grasping at straws here, but the NoSuchTokenException > exception appears to be coming from the jss library, and is thrown when > it can't find the software module that is used for accessing the > server's keys. Can you verify that your /etc/pki-ca/CS.cfg file > contains these lines? > > jss.configDir=/var/lib/pki-ca/alias/ > jss.enable=true > jss.secmodName=secmod.db > > Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg? I > don't have one. The Dogtag logic looks like it would try to use one set > there rather than the default, but letting it use the default looks like > the intended way of doing things. > > Which version of the jss and tomcatjss packages are installed? I'm > using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here. > > If none of this turns up anything, then I'm going to have to defer to > the Dogtag team, too. > > Nalin I think you're on to something. The "Invalid Request" message is misleading. The actual error is NoSuchTokenException and it happens before the PKCS10 request is parsed. So yes, we need to check the ca.requestVerify.token parameter. -- Endi S. Dewata From APtashnik at cccis.com Tue May 12 20:44:56 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Tue, 12 May 2015 20:44:56 +0000 Subject: [Freeipa-users] Allow user or group to switch user without password and not becoming root Message-ID: <812E1DF1-22C5-49F2-9AB4-9E2E765E1977@cccis.com> Hello Team, We have RHEL 7.1 and IPA server 4.1.0 in our environment as well as stack of Oracle software that require existence of local passwordless users like weblogic and oracle. Users log in to servers via domain accounts at IPA server. I?m trying to configure Sudo policy in IPA server that will allow users in the company to log in to servers in IPA domain and switch to weblogic or oracle user without having to enter any passwords, but also without increasing their privileges to root. Using plain /etc/sudoers file it can be accomplished something like below: %users ALL = (root) NOPASSWD: /bin/su ? oracle How can I configure this behavior in IPA server? Regards, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Tue May 12 20:48:30 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 12 May 2015 16:48:30 -0400 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: <20150512181454.GQ5152@redhat.com> References: <20150512181454.GQ5152@redhat.com> Message-ID: Hopefully I?m missing something simple. For an IPA user: $ ldapsearch -x ?(&(uid=ipa_user)(objectclass=posixAccount))? -b dc=ipa,dc=example,dc=com This returns a match. For an AD user: $ ldapsearch -x ?(&(uid=ad_user)(objectclass=posixAccount))? -b cn=compat,dc=ipa,dc=example,dc=com Does not return any matches. I verified that all my IPA servers have the compatibility plugin enabled. # ipa-compat-manage status Directory Manager password: Plugin Enabled # On 5/12/15, 2:14 PM, "Alexander Bokovoy" wrote: >Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a >base cn=compat,dc=ipa,dc=example,dc=com. > >Simple ldapsearch needs to include proper filter, like what SSSD or >nss_ldap are using. slapi-nis is programmed to specifically respond to >their queries, not to any request over compat tree. > >If you want to check from the command line, use a filter like > > (&(uid=AD_user)(objectclass=posixaccount)) > > >-- >/ Alexander Bokovoy [(&(uid=goul09)(objectclass=posixAccount))][cn=accounts,dc=unix,dc=osumc,dc =edu] > From dpal at redhat.com Tue May 12 21:24:27 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 May 2015 17:24:27 -0400 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: References: <20150512181454.GQ5152@redhat.com> Message-ID: <55526F8B.3040706@redhat.com> On 05/12/2015 04:48 PM, Gould, Joshua wrote: > Hopefully I?m missing something simple. > > For an IPA user: > $ ldapsearch -x ?(&(uid=ipa_user)(objectclass=posixAccount))? -b > dc=ipa,dc=example,dc=com > > This returns a match. > > For an AD user: > $ ldapsearch -x ?(&(uid=ad_user)(objectclass=posixAccount))? -b > cn=compat,dc=ipa,dc=example,dc=com > > Does not return any matches. > > I verified that all my IPA servers have the compatibility plugin enabled. > > # ipa-compat-manage status > Directory Manager password: > > Plugin Enabled > # Can you log into a server as an IPA user and then su to an AD user with authentication? If that works it means that trust is actually working. I would start with confirming that part. If we know that the trust is actually working we can move to debugging the compat-plugin. If it is not working we would know why nothing is showing up in the tree. Looking at SSSD trace on IPA server that corresponds to the time when you run the LDAP search might shed some light on what is going on. > > On 5/12/15, 2:14 PM, "Alexander Bokovoy" wrote: > >> Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a >> base cn=compat,dc=ipa,dc=example,dc=com. >> >> Simple ldapsearch needs to include proper filter, like what SSSD or >> nss_ldap are using. slapi-nis is programmed to specifically respond to >> their queries, not to any request over compat tree. >> >> If you want to check from the command line, use a filter like >> >> (&(uid=AD_user)(objectclass=posixaccount)) >> >> >> -- >> / Alexander Bokovoy > [(&(uid=goul09)(objectclass=posixAccount))][cn=accounts,dc=unix,dc=osumc,dc > =edu] > > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue May 12 21:32:22 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 May 2015 17:32:22 -0400 Subject: [Freeipa-users] Allow user or group to switch user without password and not becoming root In-Reply-To: <812E1DF1-22C5-49F2-9AB4-9E2E765E1977@cccis.com> References: <812E1DF1-22C5-49F2-9AB4-9E2E765E1977@cccis.com> Message-ID: <55527166.3020802@redhat.com> On 05/12/2015 04:44 PM, Andrey Ptashnik wrote: > Hello Team, > > We have RHEL 7.1 and IPA server 4.1.0 in our environment as well as > stack of Oracle software that require existence of local passwordless > users like weblogic and oracle. > Users log in to servers via domain accounts at IPA server. > > I'm trying to configure Sudo policy in IPA server that will allow > users in the company to log in to servers in IPA domain and switch to > weblogic or oracle user without having to enter any passwords, but > also without increasing their privileges to root. > Using plain /etc/sudoers file it can be accomplished something like below: > > %users ALL = (root) Users will be who of the IPA sudo rule > NOPASSWD: This will be an option that you would put into the sudo rule > /bin/su -- oracle This will be the command. You create a command and then reference it in the rule. At least this is what I would try. > > How can I configure this behavior in IPA server? > > Regards, > > Andrey > > > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Wed May 13 02:41:48 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 12 May 2015 22:41:48 -0400 Subject: [Freeipa-users] Allow user or group to switch user without password and not becoming root In-Reply-To: <55527166.3020802@redhat.com> References: <812E1DF1-22C5-49F2-9AB4-9E2E765E1977@cccis.com> <55527166.3020802@redhat.com> Message-ID: For the NOPASSWD option, I found that using !authenticate in the sudo option is what IPA wants instead. $ ipa sudorule-add-option readfiles Sudo Option: !authenticate ----------------------------------------------------- Added option "!authenticate" to Sudo rule "readfiles" ----------------------------------------------------- From: Dmitri Pal > Organization: Red Hat Reply-To: "dpal at redhat.com" > Date: Tuesday, May 12, 2015 at 5:32 PM To: "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Allow user or group to switch user without password and not becoming root On 05/12/2015 04:44 PM, Andrey Ptashnik wrote: Hello Team, We have RHEL 7.1 and IPA server 4.1.0 in our environment as well as stack of Oracle software that require existence of local passwordless users like weblogic and oracle. Users log in to servers via domain accounts at IPA server. I?m trying to configure Sudo policy in IPA server that will allow users in the company to log in to servers in IPA domain and switch to weblogic or oracle user without having to enter any passwords, but also without increasing their privileges to root. Using plain /etc/sudoers file it can be accomplished something like below: %users ALL = (root) Users will be who of the IPA sudo rule NOPASSWD: This will be an option that you would put into the sudo rule /bin/su ? oracle This will be the command. You create a command and then reference it in the rule. At least this is what I would try. How can I configure this behavior in IPA server? Regards, Andrey -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vangass at gazeta.pl Wed May 13 07:38:10 2015 From: vangass at gazeta.pl (Vangass) Date: Wed, 13 May 2015 09:38:10 +0200 Subject: [Freeipa-users] HBAC rules don't work with PAM - problem In-Reply-To: <20150512073949.GJ6587@redhat.com> References: <20150511115738.GP3722@hendrix.payandsurf.com> <20150511120515.GY6587@redhat.com> <20150511144700.GJ2628@mail.corp.redhat.com> <20150511151531.GL6227@p.redhat.com> <20150511152229.GM6227@p.redhat.com> <20150512073949.GJ6587@redhat.com> Message-ID: OK. I understand. Thank You for an answer. 2015-05-12 9:39 GMT+02:00 Jan Pazdziora : > On Mon, May 11, 2015 at 08:52:08PM +0200, Vangass wrote: > > OK. But the answer granted/declined comes from IPA. So why IPA doesn't > > check its own HBAC rules at all? > > Maybe the line 'account required pam_sss.so' isn't > > necessary/required. I just want to do authentication by IPA HBAC rules. > > Note that you can have setups when you don't authenticate via PAM > at all (for example when using Kerberos) yet you do authorization > (access control) using PAM. Authentication is not the correct place to > process HBAC rules. > > In your case, nobody is arguing that the password used was correct -- > authentication passed, the identity of the client was validated. The > application (tacacs) is supposed to do additional step, now that it > knows what user is attempting to log in -- verify authorization, fact > that the known user should be allowed in, with pam_acct_mgmt. > > That's the why. > > You could in theory force it to work by writing a wrapper PAM module > which would call both pam_sss's pam_sm_authenticate *and* > pam_sm_acct_mgmt for its pam_sm_authenticate call. But it would be > a hack, possibly with unexpected side effects. > > -- > Jan Pazdziora > Senior Principal Software Engineer, Identity Management Engineering, Red > Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thibaut.pouzet at lyra-network.com Wed May 13 08:15:58 2015 From: thibaut.pouzet at lyra-network.com (Thibaut Pouzet) Date: Wed, 13 May 2015 10:15:58 +0200 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <20150512181142.GB23769@redhat.com> References: <5550C748.3090903@lyra-network.com> <20150512160952.GA23769@redhat.com> <55522CB1.2090805@lyra-network.com> <20150512181142.GB23769@redhat.com> Message-ID: <5553083E.3050203@lyra-network.com> Le 12/05/2015 20:11, Nalin Dahyabhai a ?crit : > On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote: >> After doing what you recommended, the CSR have changed in the debug log : >> >> Certificate Request: >> Data: >> Version: 0 (0x0) >> Subject: O=ipa_domain, CN=ipa_server >> Subject Public Key Info: >> Public Key Algorithm: rsaEncryption >> Public-Key: (2048 bit) >> Modulus: >> 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: >> 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: >> 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: >> 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: >> 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: >> 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: >> 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: >> d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: >> 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: >> 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: >> f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: >> c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: >> 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: >> b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: >> 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: >> 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: >> 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: >> 1b:fb >> Exponent: 65537 (0x10001) >> Attributes: >> a0:00 >> Signature Algorithm: sha256WithRSAEncryption >> 10:ef:cf:ff:6c:63:72:61:c3:b5:5e:8e:b0:20:f0:63:13:43: >> bb:3b:63:c8:4e:6f:34:63:33:cc:47:af:8a:dc:2d:13:2a:58: >> 87:7c:d7:5e:e9:b3:e7:f4:47:b7:7b:eb:77:0b:7c:0e:58:20: >> dd:62:a8:a0:8b:31:1e:54:f0:dd:3f:44:4a:e7:a2:a6:64:85: >> 9f:10:0e:06:75:33:94:82:f3:8f:89:66:e1:7f:65:21:85:b8: >> 69:6d:e7:35:a5:a7:08:1d:51:55:48:13:b8:e3:2d:6f:99:c1: >> ce:1e:81:e3:fb:93:3a:f0:86:0d:43:96:31:93:fb:87:fb:53: >> 46:02:e1:dd:05:55:85:72:35:fa:72:6d:c6:35:d4:6d:9e:be: >> db:ee:e6:8c:7b:b1:5a:cd:4d:cc:8e:3e:10:4e:a7:d3:61:36: >> ae:86:59:df:51:a3:0f:38:79:b8:e0:bd:eb:25:44:a4:43:b0: >> 93:7f:1e:43:aa:d5:30:d3:e3:a0:bd:ee:08:b7:88:9a:cd:a0: >> 8c:ac:2a:8f:71:ec:64:70:72:91:f8:d2:e8:55:5b:22:1f:2e: >> 60:6c:a4:be:ee:42:09:a6:71:25:ec:37:43:a1:e6:15:63:8f: >> 05:97:61:1d:8e:25:5d:76:df:8b:66:7f:85:27:8b:93:98:a9: >> 3e:cc:cb:d8 >> >> There is no more this weird "friendlyName :unable to print >> attribute" thing, but the NoSuchTokenException is still in the debug log >> of pki-ca >> >> Thank you for you answer though, we've still made some progress in >> identifying that I messed the CA used for this certificate ! > > Hmm, so what you've got there looks pretty normal for a renewal request. > Just to rule out a problem with the request's signature or the encoding > of the subject name in the request (the latter is a bug in versions of > certmonger before 0.72), can you check the version of the certmonger > package and show us the base64-encoded form of the signing request? Before going further and asking the ML, I got these packages updated 'just in case' : rpm -qa | egrep "certmonger|jss" tomcatjss-2.1.0-3.el6.noarch certmonger-0.75.13-1.el6.x86_64 jss-4.2.6-24.el6.x86_64 > > I'm just about grasping at straws here, but the NoSuchTokenException > exception appears to be coming from the jss library, and is thrown when > it can't find the software module that is used for accessing the > server's keys. Can you verify that your /etc/pki-ca/CS.cfg file > contains these lines? > > jss.configDir=/var/lib/pki-ca/alias/ > jss.enable=true > jss.secmodName=secmod.db > These lines are exactly as is inside the CS.cfg file > Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg? I > don't have one. The Dogtag logic looks like it would try to use one set > there rather than the default, but letting it use the default looks like > the intended way of doing things. I cannot find this line, this is all I've got that seems somehow related to a token notion : fgrep token /etc/pki-ca/CS.cfg ca.audit_signing.tokenname=Internal Key Storage Token ca.ocsp_signing.tokenname=Internal Key Storage Token ca.signing.tokenname=Internal Key Storage Token ca.sslserver.tokenname=Internal Key Storage Token ca.subsystem.tokenname=Internal Key Storage Token cloning.module.token=Internal Key Storage Token > > Which version of the jss and tomcatjss packages are installed? I'm > using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here. > > If none of this turns up anything, then I'm going to have to defer to > the Dogtag team, too. > > Nalin > I do not wish to give away too much information on this ML, so I will send the base64 CSR and CS.cfg file to you personally. I am sorry for the other people watching this discussions... I will take care to submit relevant information if anything is found with this. Cheers, -- Thibaut Pouzet Lyra Network Ing?nieur Syst?mes et R?seaux (+33) 5 31 22 40 08 www.lyra-network.com From mkosek at redhat.com Wed May 13 13:16:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 May 2015 15:16:01 +0200 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: References: <20150512181454.GQ5152@redhat.com> Message-ID: <55534E91.3010300@redhat.com> On 05/12/2015 10:48 PM, Gould, Joshua wrote: > Hopefully I?m missing something simple. > > For an IPA user: > $ ldapsearch -x ?(&(uid=ipa_user)(objectclass=posixAccount))? -b > dc=ipa,dc=example,dc=com > > This returns a match. > > For an AD user: > $ ldapsearch -x ?(&(uid=ad_user)(objectclass=posixAccount))? -b > cn=compat,dc=ipa,dc=example,dc=com > > Does not return any matches. > > I verified that all my IPA servers have the compatibility plugin enabled. > > # ipa-compat-manage status > Directory Manager password: > > Plugin Enabled > # I may be asking the obvious, but "ad_user" is fully qualified, right? I.e. aduser at my.ad.domain.test? Testing the log in on the server system as Dmitri advised is also a good test to make. > > > On 5/12/15, 2:14 PM, "Alexander Bokovoy" wrote: > >> Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a >> base cn=compat,dc=ipa,dc=example,dc=com. >> >> Simple ldapsearch needs to include proper filter, like what SSSD or >> nss_ldap are using. slapi-nis is programmed to specifically respond to >> their queries, not to any request over compat tree. >> >> If you want to check from the command line, use a filter like >> >> (&(uid=AD_user)(objectclass=posixaccount)) >> >> >> -- >> / Alexander Bokovoy > > [(&(uid=goul09)(objectclass=posixAccount))][cn=accounts,dc=unix,dc=osumc,dc > =edu] >> > > > From Joshua.Gould at osumc.edu Wed May 13 13:22:10 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 13 May 2015 09:22:10 -0400 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: <55526F8B.3040706@redhat.com> References: <20150512181454.GQ5152@redhat.com> <55526F8B.3040706@redhat.com> Message-ID: I can login to a RHEL6/7 server as an IPA user and SU to an AD user and it works fine. I can also login directly as an AD user as well. For my RHEL5 system, I can login as a IPA user but can not su - or login as a AD user. -sh-3.2$ su - ad_user su: user goul09 does not exist As I mentioned before, queries to the compat part of the tree do not return any matches either. On my RHEL6 client, I saw this, which indicates there?s a different approach used. (Tue May 12 12:10:10 2015) [sssd[be[unix.osumc.edu]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=ad_user)(objectclass=user)(sAMAccountName=*)(objectSID=* ))][dc=example,dc=com]. On 5/12/15, 5:24 PM, "Dmitri Pal" wrote: >On 05/12/2015 04:48 PM, Gould, Joshua wrote: >>Hopefully I?m missing something simple. >> >>For an IPA user: >>$ ldapsearch -x ?(&(uid=ipa_user)(objectclass=posixAccount))? -b >>dc=ipa,dc=example,dc=com >> >>This returns a match. >> >>For an AD user: >>$ ldapsearch -x ?(&(uid=ad_user)(objectclass=posixAccount))? -b >>cn=compat,dc=ipa,dc=example,dc=com >> >>Does not return any matches. >> >>I verified that all my IPA servers have the compatibility plugin enabled. >> >># ipa-compat-manage status >>Directory Manager password: >> >>Plugin Enabled >># > > >Can you log into a server as an IPA user and then su to an AD user with >authentication? >If that works it means that trust is actually working. I would start >with confirming that part. >If we know that the trust is actually working we can move to debugging >the compat-plugin. If it is not working we would know why nothing is >showing up in the tree. >Looking at SSSD trace on IPA server that corresponds to the time when >you run the LDAP search might shed some light on what is going on. From Joshua.Gould at osumc.edu Wed May 13 13:24:45 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 13 May 2015 09:24:45 -0400 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: <55534E91.3010300@redhat.com> References: <20150512181454.GQ5152@redhat.com> <55534E91.3010300@redhat.com> Message-ID: I have default_domain_suffix = example.com in my [sssd] section of sssd.conf. On RHEL6/7 systems, I?m able to login or issue any other command without the suffix. Is it safe to assume it works the same in RHEL5? I also tried with domain in all lower case and all upper case as well. On 5/13/15, 9:16 AM, "Martin Kosek" wrote: >On 05/12/2015 10:48 PM, Gould, Joshua wrote: >> Hopefully I?m missing something simple. >> >> For an IPA user: >> $ ldapsearch -x ?(&(uid=ipa_user)(objectclass=posixAccount))? -b >> dc=ipa,dc=example,dc=com >> >> This returns a match. >> >> For an AD user: >> $ ldapsearch -x ?(&(uid=ad_user)(objectclass=posixAccount))? -b >> cn=compat,dc=ipa,dc=example,dc=com >> >> Does not return any matches. >> >> I verified that all my IPA servers have the compatibility plugin >>enabled. >> >> # ipa-compat-manage status >> Directory Manager password: >> >> Plugin Enabled >> # > >I may be asking the obvious, but "ad_user" is fully qualified, right? I.e. >aduser at my.ad.domain.test? > >Testing the log in on the server system as Dmitri advised is also a good >test >to make. > >> >> >> On 5/12/15, 2:14 PM, "Alexander Bokovoy" wrote: >> >>> Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a >>> base cn=compat,dc=ipa,dc=example,dc=com. >>> >>> Simple ldapsearch needs to include proper filter, like what SSSD or >>> nss_ldap are using. slapi-nis is programmed to specifically respond to >>> their queries, not to any request over compat tree. >>> >>> If you want to check from the command line, use a filter like >>> >>> (&(uid=AD_user)(objectclass=posixaccount)) >>> >>> >>> -- >>> / Alexander Bokovoy >> >> >>[(&(uid=goul09)(objectclass=posixAccount))][cn=accounts,dc=unix,dc=osumc, >>dc >> =edu] >>> >> >> >> > From abokovoy at redhat.com Wed May 13 13:31:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 13 May 2015 16:31:43 +0300 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: References: <20150512181454.GQ5152@redhat.com> <55526F8B.3040706@redhat.com> Message-ID: <20150513133143.GT5152@redhat.com> On Wed, 13 May 2015, Gould, Joshua wrote: >I can login to a RHEL6/7 server as an IPA user and SU to an AD user and it >works fine. I can also login directly as an AD user as well. > >For my RHEL5 system, I can login as a IPA user but can not su - or login >as a AD user. > >-sh-3.2$ su - ad_user >su: user goul09 does not exist Have you actually read the definitive guide we have? http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf, linked from http://www.freeipa.org/page/Documentation It looks like you have missed it, given your answers and attempts to use non-fully qualified user names. -- / Alexander Bokovoy From dpal at redhat.com Wed May 13 14:13:31 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 May 2015 10:13:31 -0400 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: References: <20150512181454.GQ5152@redhat.com> <55534E91.3010300@redhat.com> Message-ID: <55535C0B.4010502@redhat.com> On 05/13/2015 09:24 AM, Gould, Joshua wrote: > I have default_domain_suffix = example.com in my [sssd] section of > sssd.conf. On RHEL6/7 systems, I?m able to login or issue any other > command without the suffix. Is it safe to assume it works the same in > RHEL5? I also tried with domain in all lower case and all upper case as > well. I think you have to use fully qualified names with legacy versions against compat tree. Can you try a FQ name from RHEL5? > > On 5/13/15, 9:16 AM, "Martin Kosek" wrote: > >> On 05/12/2015 10:48 PM, Gould, Joshua wrote: >>> Hopefully I?m missing something simple. >>> >>> For an IPA user: >>> $ ldapsearch -x ?(&(uid=ipa_user)(objectclass=posixAccount))? -b >>> dc=ipa,dc=example,dc=com >>> >>> This returns a match. >>> >>> For an AD user: >>> $ ldapsearch -x ?(&(uid=ad_user)(objectclass=posixAccount))? -b >>> cn=compat,dc=ipa,dc=example,dc=com >>> >>> Does not return any matches. >>> >>> I verified that all my IPA servers have the compatibility plugin >>> enabled. >>> >>> # ipa-compat-manage status >>> Directory Manager password: >>> >>> Plugin Enabled >>> # >> I may be asking the obvious, but "ad_user" is fully qualified, right? I.e. >> aduser at my.ad.domain.test? >> >> Testing the log in on the server system as Dmitri advised is also a good >> test >> to make. >> >>> >>> On 5/12/15, 2:14 PM, "Alexander Bokovoy" wrote: >>> >>>> Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a >>>> base cn=compat,dc=ipa,dc=example,dc=com. >>>> >>>> Simple ldapsearch needs to include proper filter, like what SSSD or >>>> nss_ldap are using. slapi-nis is programmed to specifically respond to >>>> their queries, not to any request over compat tree. >>>> >>>> If you want to check from the command line, use a filter like >>>> >>>> (&(uid=AD_user)(objectclass=posixaccount)) >>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>> >>> [(&(uid=goul09)(objectclass=posixAccount))][cn=accounts,dc=unix,dc=osumc, >>> dc >>> =edu] >>> >>> > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From bahmer at lanl.gov Wed May 13 14:44:46 2015 From: bahmer at lanl.gov (Bahmer, Eric Vaughn) Date: Wed, 13 May 2015 14:44:46 +0000 Subject: [Freeipa-users] ipa spamming radius with otp token? Message-ID: Institutionally we have a hardware token set up, you use a pin to unlock the device and it spits out a passcode. The passcode allows access through kerberos, radius, or ldap binds to linux servers, or with a custom apache module to websites. I have an out-of-band private network set up that attaches to our intranet using a firewall/gateway server which does some port forwarding for various things like SSH, RDP. I?m attempting to set up RADIUS on this firewall/gateway to be used as a proxy for freeipa to our token system which I?d like to be able to use behind the firewall. However I seem to be getting nearly a dozen requests into the radius server, about half are dropped as duplicate, but usually 3-6 get through and since it?s a single use token the first attempt succeeds, but the rest fail and cause the hardware token to be blacklisted. Is there a way to specify that the user radius login is a one-time token or is this something that sssd or pam is causing? Or does the OTP support just not work in the way I need it to? I have this issue with both the inbox 4.1.0 in RHEL7.1 or the upstream 4.1.4 rpms. My only alternative is probably to set up a KDC on the firewall to trust the institutional realm and have the IdM kerberos realm trust that. This is also a mixed linux/windows environment behind the firewall, I?ve enabled unix attributes in my AD and I?m using a script to sync uid/gid with the external ldap. -------------- next part -------------- An HTML attachment was scrubbed... URL: From devans01 at gmail.com Wed May 13 15:16:24 2015 From: devans01 at gmail.com (Dylan Evans) Date: Wed, 13 May 2015 16:16:24 +0100 Subject: [Freeipa-users] freeipa-samba integration and windows clients In-Reply-To: <55522EBE.2000401@redhat.com> References: <20150507052805.GY11785@redhat.com> <20150507074806.GZ11785@redhat.com> <20150510170228.GM38847@Jakubs-MacBook-Pro.local> <55522EBE.2000401@redhat.com> Message-ID: Hi Dimitri & Jakub, Yes for us it is use case. Non-domain logins / NTLMSSP support in SSSD is the final component we seem to need to allow Windows clients from a non-trusted AD domain to access Samba shares using a username and password combination, without having to use Kerberos. IPA and SSSD is a phenomenal body of work that has huge potential, all your work is much appreciated. Thanks, Dylan. On 12 May 2015 at 17:47, Dmitri Pal wrote: > On 05/12/2015 07:03 AM, Dylan Evans wrote: >> >> Hi Jakub, >> >> It's good to know it's going to happen, let's hope it gets into 1.13 >> and everyone has a very productive summer! >> >> I've been watching IPA for a couple of years and this is the last >> thing that's preventing it from being implemented in our production >> environment. > > > So is this use case the main reason of needing NTLMSSP support or there are > some other use cases that drive this requirement? > Can you please share them? > > >> Thanks, >> >> Dylan. >> >> On 11 May 2015 at 20:42, John Obaterspok >> wrote: >>> >>> I have about the same setup: >>> >>> This is the setup (everything is up-to-date): >>> - ipa-server: F21, ipa-server 4.1, samba 4.1 >>> - win-client: Windows 7 Home Premium >>> >>> I tried to enroll the win-client in the domain but failed on the windows >>> side due to home editions not being able to join a domain. >>> But I can still access shares from the win-client by user/pwd >>> >>> The only difference in my setup is that I use samba server on the >>> ipa-server >>> itself. >>> >>> -- john >>> >>> 2015-05-10 19:02 GMT+02:00 Jakub Hrozek : >>>> >>>> On Thu, May 07, 2015 at 03:30:06PM +0100, Dylan Evans wrote: >>>>> >>>>> By coincidence I posted a very similar question yesterday - >>>>> https://www.redhat.com/archives/freeipa-users/2015-May/msg00103.html. >>>>> >>>>> +1 for the necessary support for out-of-domain Windows clients and >>>>> NTLMSSP. >>>>> >>>>> Is there a time-table for this? >>>> >>>> It is a nice-to-have feature for the next SSSD version (1.13, this >>>> summber), >>>> but my hopes are not high that we're going to make it. I think 1.14 is >>>> more >>>> realistic. >>>> >>>> -- >>>> 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 >>> >>> > > > -- > Thank you, > Dmitri Pal > > Director of Engineering for 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 From janellenicole80 at gmail.com Wed May 13 15:40:16 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 13 May 2015 08:40:16 -0700 Subject: [Freeipa-users] more replication issues Message-ID: <55537060.2060502@gmail.com> Recently I started seeing these crop up across my servers: slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) more and more and more. When it happens, I have to re-initialize from one of the good servers and go around in a circle (I have replication in a ring, as shown in documentation examples). The list-ruv on every server matches. And yet, out of 18 masters, thisis occuring now on about half of them. Once again I am beginning to question the robustness of 389-ds and the replication problems that many of us continue to report. How do we get this to be more solid? I love this product. It really is something that RH can push, but it really needs to be rock solid and with all the replication issues, well, it seems like it is not commercially ready? Any ideas/thoughts/comments? thank you Janelle From rmeggins at redhat.com Wed May 13 15:49:01 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 13 May 2015 09:49:01 -0600 Subject: [Freeipa-users] more replication issues In-Reply-To: <55537060.2060502@gmail.com> References: <55537060.2060502@gmail.com> Message-ID: <5553726D.70505@redhat.com> On 05/13/2015 09:40 AM, Janelle wrote: > Recently I started seeing these crop up across my servers: > > slapi_ldap_bind - Error: could not bind id [cn=Replication Manager > masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] > authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 > (Success) Does that entry exist? ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b "cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" Does the parent exist? ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b "ou=csusers,cn=config" > > more and more and more. When it happens, I have to re-initialize from > one of the good servers and go around in a circle (I have replication > in a ring, as shown in documentation examples). The list-ruv on every > server matches. And yet, out of 18 masters, thisis occuring now on > about half of them. > > Once again I am beginning to question the robustness of 389-ds and the > replication problems that many of us continue to report. How do we get > this to be more solid? I love this product. It really is something > that RH can push, but it really needs to be rock solid and with all > the replication issues, well, it seems like it is not commercially ready? > > Any ideas/thoughts/comments? > > thank you > Janelle > From janellenicole80 at gmail.com Wed May 13 16:04:53 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 13 May 2015 09:04:53 -0700 Subject: [Freeipa-users] more replication issues In-Reply-To: <5553726D.70505@redhat.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> Message-ID: <55537625.4070701@gmail.com> On 5/13/15 8:49 AM, Rich Megginson wrote: > On 05/13/2015 09:40 AM, Janelle wrote: >> Recently I started seeing these crop up across my servers: >> >> slapi_ldap_bind - Error: could not bind id [cn=Replication Manager >> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] >> authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 >> (Success) > > Does that entry exist? > > ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base > -b "cn=Replication Manager > masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" > > Does the parent exist? > > ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base > -b "ou=csusers,cn=config" I am finding that there does seem to be a relation to the above error and a possible CSN issue: Can't locate CSN 555131e5000200190000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. I guess what concerns me is what could be causing this. We don't do a lot of changes all the time. And in answer to the question above - we seem to have last the agreement somehow: No such object (32) results from the first ldapsearch. however, the parent is there: dn: ou=csusers,cn=config objectClass: top objectClass: organizationalUnit ou: csusers From rmeggins at redhat.com Wed May 13 16:13:11 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 13 May 2015 10:13:11 -0600 Subject: [Freeipa-users] more replication issues In-Reply-To: <55537625.4070701@gmail.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> Message-ID: <55537817.9010904@redhat.com> On 05/13/2015 10:04 AM, Janelle wrote: > On 5/13/15 8:49 AM, Rich Megginson wrote: >> On 05/13/2015 09:40 AM, Janelle wrote: >>> Recently I started seeing these crop up across my servers: >>> >>> slapi_ldap_bind - Error: could not bind id [cn=Replication Manager >>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] >>> authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 >>> (Success) >> >> Does that entry exist? >> >> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >> base -b "cn=Replication Manager >> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >> >> Does the parent exist? >> >> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >> base -b "ou=csusers,cn=config" > > I am finding that there does seem to be a relation to the above error > and a possible CSN issue: > > Can't locate CSN 555131e5000200190000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > > I guess what concerns me is what could be causing this. We don't do a > lot of changes all the time. > > And in answer to the question above - we seem to have last the > agreement somehow: > > No such object (32) > Is there a DEL operation in the access log for "cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? maybe something like # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication Manager" > results from the first ldapsearch. > > however, the parent is there: > dn: ou=csusers,cn=config > objectClass: top > objectClass: organizationalUnit > ou: csusers > > From janellenicole80 at gmail.com Wed May 13 16:34:24 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 13 May 2015 09:34:24 -0700 Subject: [Freeipa-users] more replication issues In-Reply-To: <55537817.9010904@redhat.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> <55537817.9010904@redhat.com> Message-ID: <55537D10.4000208@gmail.com> On 5/13/15 9:13 AM, Rich Megginson wrote: > On 05/13/2015 10:04 AM, Janelle wrote: >> On 5/13/15 8:49 AM, Rich Megginson wrote: >>> On 05/13/2015 09:40 AM, Janelle wrote: >>>> Recently I started seeing these crop up across my servers: >>>> >>>> slapi_ldap_bind - Error: could not bind id [cn=Replication Manager >>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] >>>> authentication mechanism [SIMPLE]: error 32 (No such object) errno >>>> 0 (Success) >>> >>> Does that entry exist? >>> >>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>> base -b "cn=Replication Manager >>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >>> >>> Does the parent exist? >>> >>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>> base -b "ou=csusers,cn=config" >> >> I am finding that there does seem to be a relation to the above error >> and a possible CSN issue: >> >> Can't locate CSN 555131e5000200190000 in the changelog (DB >> rc=-30988). If replication stops, the consumer may need to be >> reinitialized. >> >> I guess what concerns me is what could be causing this. We don't do a >> lot of changes all the time. >> >> And in answer to the question above - we seem to have last the >> agreement somehow: >> >> No such object (32) >> > > Is there a DEL operation in the access log for "cn=Replication Manager > masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? > > maybe something like > > # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication > Manager" > nope -- none of the servers have it. From APtashnik at cccis.com Wed May 13 17:12:21 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Wed, 13 May 2015 17:12:21 +0000 Subject: [Freeipa-users] Allow user or group to switch user without password and not becoming root In-Reply-To: References: <812E1DF1-22C5-49F2-9AB4-9E2E765E1977@cccis.com> <55527166.3020802@redhat.com> Message-ID: Thank you everyone for your help! I found two ways to implement it in IPA server and tested it. So both methods work in my current setup RHEL 7.1 and IPA server 4.1.0. First method allows user to run default terminal as a target user (bash in my case). Second method is using SU command, but runs it as a root user. So depending on security preferences either one could satisfy admins. =================================== Options: !authenticate Who: user1 Access this Host: webserver Run Commands: /usr/bin/sudo /bin/bash As Whom: oracle (external user type is oracle is created locally only) How is it working: [user1 at webserver ~]$ sudo -u oracle bash -i [oracle at webserver user1]$ =================================== Options: !authenticate Who: user1 Access this Host: webserver Run Commands: /usr/bin/sudo /bin/su - oracle As Whom: root How is it working: [user1 at webserver ~]$ sudo su - oracle Last login: Wed May 13 11:41:52 CDT 2015 on pts/0 [oracle at webserver ~]$ =================================== For some reason NOPASSWD: option was not recognized correctly by IPA server. This is the output I was getting: [user1 at webserver ~]$ sudo su - oracle sudo: unknown defaults entry `NOPASSWD:' Last login: Tue May 12 15:00:31 CDT 2015 on pts/1 Last failed login: Wed May 13 10:46:52 CDT 2015 on pts/0 There were 7 failed login attempts since the last successful login. [oracle at webserver ~]$ Regards, Andrey Ptashnik From: , Joshua > Date: Tuesday, May 12, 2015 at 9:41 PM To: "dpal at redhat.com" >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Allow user or group to switch user without password and not becoming root For the NOPASSWD option, I found that using !authenticate in the sudo option is what IPA wants instead. $ ipa sudorule-add-option readfiles Sudo Option: !authenticate ----------------------------------------------------- Added option "!authenticate" to Sudo rule "readfiles" ----------------------------------------------------- From: Dmitri Pal > Organization: Red Hat Reply-To: "dpal at redhat.com" > Date: Tuesday, May 12, 2015 at 5:32 PM To: "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Allow user or group to switch user without password and not becoming root On 05/12/2015 04:44 PM, Andrey Ptashnik wrote: Hello Team, We have RHEL 7.1 and IPA server 4.1.0 in our environment as well as stack of Oracle software that require existence of local passwordless users like weblogic and oracle. Users log in to servers via domain accounts at IPA server. I?m trying to configure Sudo policy in IPA server that will allow users in the company to log in to servers in IPA domain and switch to weblogic or oracle user without having to enter any passwords, but also without increasing their privileges to root. Using plain /etc/sudoers file it can be accomplished something like below: %users ALL = (root) Users will be who of the IPA sudo rule NOPASSWD: This will be an option that you would put into the sudo rule /bin/su ? oracle This will be the command. You create a command and then reference it in the rule. At least this is what I would try. How can I configure this behavior in IPA server? Regards, Andrey -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed May 13 17:31:51 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 May 2015 13:31:51 -0400 Subject: [Freeipa-users] Allow user or group to switch user without password and not becoming root In-Reply-To: References: <812E1DF1-22C5-49F2-9AB4-9E2E765E1977@cccis.com> <55527166.3020802@redhat.com> Message-ID: <55538A87.7060601@redhat.com> On 05/13/2015 01:12 PM, Andrey Ptashnik wrote: > Thank you everyone for your help! > > I found two ways to implement it in IPA server and tested it. So both > methods work in my current setup RHEL 7.1 and IPA server 4.1.0. First > method allows user to run default terminal as a target user (bash in > my case). Second method is using SU command, but runs it as a root > user. So depending on security preferences either one could satisfy > admins. > > =================================== > > *Options:* > !authenticate > > *Who:* > user1 > > *Access this Host:* > webserver > > *Run Commands:* > /usr/bin/sudo > /bin/bash > > *As Whom:* > oracle (external user type is oracle is created locally only) > > How is it working: > [user1 at webserver ~]$ *sudo -u oracle bash -i* > [oracle at webserver user1]$ > > =================================== > > *Options:* > !authenticate > > *Who:* > user1 > > *Access this Host:* > webserver > > *Run Commands:* > /usr/bin/sudo > /bin/su - oracle > > *As Whom:* > root > > How is it working: > [user1 at webserver ~]$ *sudo su - oracle* > Last login: Wed May 13 11:41:52 CDT 2015 on pts/0 > [oracle at webserver ~]$ > > =================================== > > For some reason *NOPASSWD:* option was not recognized correctly by IPA > server. This is the output I was getting: > > [user1 at webserver ~]$ sudo su - oracle > sudo: unknown defaults entry `NOPASSWD:' > Last login: Tue May 12 15:00:31 CDT 2015 on pts/1 > Last failed login: Wed May 13 10:46:52 CDT 2015 on pts/0 > There were 7 failed login attempts since the last successful login. > [oracle at webserver ~]$ > > Regards, > > Andrey Ptashnik > Thank you! Would you mind turning it into a HowTo on the freeIPA wiki? > > From: , Joshua > > Date: Tuesday, May 12, 2015 at 9:41 PM > To: "dpal at redhat.com " >, "freeipa-users at redhat.com > " > > Subject: Re: [Freeipa-users] Allow user or group to switch user > without password and not becoming root > > For the NOPASSWD option, I found that using !authenticate in the sudo > option is what IPA wants instead. > > $ ipa sudorule-add-option readfiles > Sudo Option: !authenticate > ----------------------------------------------------- > Added option "!authenticate" to Sudo rule "readfiles" > ----------------------------------------------------- > > From: Dmitri Pal > > Organization: Red Hat > Reply-To: "dpal at redhat.com " > > Date: Tuesday, May 12, 2015 at 5:32 PM > To: "freeipa-users at redhat.com " > > > Subject: Re: [Freeipa-users] Allow user or group to switch user > without password and not becoming root > > On 05/12/2015 04:44 PM, Andrey Ptashnik wrote: >> Hello Team, >> >> We have RHEL 7.1 and IPA server 4.1.0 in our environment as well as >> stack of Oracle software that require existence of local passwordless >> users like weblogic and oracle. >> Users log in to servers via domain accounts at IPA server. >> >> I?m trying to configure Sudo policy in IPA server that will allow >> users in the company to log in to servers in IPA domain and switch to >> weblogic or oracle user without having to enter any passwords, but >> also without increasing their privileges to root. >> Using plain /etc/sudoers file it can be accomplished something like >> below: >> >> %users ALL = (root) > > Users will be who of the IPA sudo rule > >> NOPASSWD: > > This will be an option that you would put into the sudo rule > >> /bin/su ? oracle > > This will be the command. You create a command and then reference it > in the rule. > > At least this is what I would try. > >> >> How can I configure this behavior in IPA server? >> >> Regards, >> >> Andrey >> >> >> > > > -- > Thank you, > Dmitri Pal > > Director of Engineering for IdM portfolio > Red Hat, Inc. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed May 13 17:32:52 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 13 May 2015 11:32:52 -0600 Subject: [Freeipa-users] more replication issues In-Reply-To: <55537D10.4000208@gmail.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> <55537817.9010904@redhat.com> <55537D10.4000208@gmail.com> Message-ID: <55538AC4.8050909@redhat.com> On 05/13/2015 10:34 AM, Janelle wrote: > On 5/13/15 9:13 AM, Rich Megginson wrote: >> On 05/13/2015 10:04 AM, Janelle wrote: >>> On 5/13/15 8:49 AM, Rich Megginson wrote: >>>> On 05/13/2015 09:40 AM, Janelle wrote: >>>>> Recently I started seeing these crop up across my servers: >>>>> >>>>> slapi_ldap_bind - Error: could not bind id [cn=Replication Manager >>>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication >>>>> mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) >>>> >>>> Does that entry exist? >>>> >>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>> base -b "cn=Replication Manager >>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >>>> >>>> Does the parent exist? >>>> >>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>> base -b "ou=csusers,cn=config" >>> >>> I am finding that there does seem to be a relation to the above >>> error and a possible CSN issue: >>> >>> Can't locate CSN 555131e5000200190000 in the changelog (DB >>> rc=-30988). If replication stops, the consumer may need to be >>> reinitialized. >>> >>> I guess what concerns me is what could be causing this. We don't do >>> a lot of changes all the time. >>> >>> And in answer to the question above - we seem to have last the >>> agreement somehow: >>> >>> No such object (32) >>> >> >> Is there a DEL operation in the access log for "cn=Replication >> Manager >> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? >> >> maybe something like >> >> # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication >> Manager" >> > nope -- none of the servers have it. > Either there is some internal op that is deleting it, or there is a bug that is causing it to be removed. To see what internal operation could be doing this, you could enable internal access logging: ldapmodify -x -h consumer.host -D "cn=directory manager" -w "password" < References: Message-ID: <55538CD4.3020001@redhat.com> On 05/13/2015 10:44 AM, Bahmer, Eric Vaughn wrote: > Institutionally we have a hardware token set up, you use a pin to > unlock the device and it spits out a passcode. > The passcode allows access through kerberos, radius, or ldap binds to > linux servers, or with a custom apache module to websites. > > I have an out-of-band private network set up that attaches to our > intranet using a firewall/gateway server which does some port > forwarding for various things like SSH, RDP. > I'm attempting to set up RADIUS on this firewall/gateway to be used as > a proxy for freeipa to our token system which I'd like to be able to > use behind the firewall. > However I seem to be getting nearly a dozen requests into the radius > server, about half are dropped as duplicate, but usually 3-6 get > through and since it's a single use token the first attempt succeeds, > but the rest fail and cause the hardware token to be blacklisted. > Is there a way to specify that the user radius login is a one-time > token or is this something that sssd or pam is causing? > Or does the OTP support just not work in the way I need it to? > I have this issue with both the inbox 4.1.0 in RHEL7.1 or the upstream > 4.1.4 rpms. > > My only alternative is probably to set up a KDC on the firewall to > trust the institutional realm and have the IdM kerberos realm trust that. > This is also a mixed linux/windows environment behind the firewall, > I've enabled unix attributes in my AD and I'm using a script to sync > uid/gid with the external ldap. > > > Let me rephrase the setup to see if I got it. You have an OTP server, it is behind the firewall. IPA is outside the firewall. You configured IPA to use radius to talk to OTP server. The firewall drops some of the packets but some go through. If this is true then: - There can be a problem with our implementation of the RADIUS client retries. If the client starts a new conversation every time rather than retries the same packet then this is a client side bug. Nathaniel, do you have any hints on how to debug, troubleshoot, change configuration of the RADIUS client? Are retries and timeouts configurable? - The problem can be also on the server side. Server should be tolerant to the identical radius packets and not do more than one 2FA authentication sequence. If it starts more than one it is a bug on the server side. Being the former implementer of one of the RADIUS servers for one of the major 2FA vendors I know exactly how that happens. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Wed May 13 17:48:23 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 13 May 2015 13:48:23 -0400 Subject: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX In-Reply-To: <20150513133143.GT5152@redhat.com> References: <20150512181454.GQ5152@redhat.com> <55526F8B.3040706@redhat.com> <20150513133143.GT5152@redhat.com> Message-ID: Thank you. I had originally went with the RH documentation. I followed the guide and was able to get my RHEL5 client working. AIX6 is closer to working as well. On 5/13/15, 9:31 AM, "Alexander Bokovoy" wrote: >Have you actually read the definitive guide we have? >https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeipa.org_images >_0_0d_FreeIPA33-2Dlegacy-2Dclients.pdf&d=AwIFAg&c=k9MF1d71ITtkuJx-PdWme51d >KbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24&m=axYK-L >XpDnB6taF3q8whBGDW0q7jDMqS2Wv5kOEFsKk&s=BnxBd_Jlajh36QyW5WUwRx66b0wQsahXds >0jLtMUgFA&e= , linked >from >https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeipa.org_page_D >ocumentation&d=AwIFAg&c=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0 >y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24&m=axYK-LXpDnB6taF3q8whBGDW0q7jDMqS >2Wv5kOEFsKk&s=uxaGUOkBbxd11-Nx8G2bGLeRCHdDmsc2Oc6CwUf7q5c&e= > >It looks like you have missed it, given your answers and attempts to use >non-fully qualified user names. From npmccallum at redhat.com Wed May 13 18:00:30 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 13 May 2015 14:00:30 -0400 Subject: [Freeipa-users] ipa spamming radius with otp token? In-Reply-To: References: Message-ID: <1431540030.3260.53.camel@redhat.com> On Wed, 2015-05-13 at 14:44 +0000, Bahmer, Eric Vaughn wrote: > Institutionally we have a hardware token set up, you use a pin to > unlock the device and it spits out a passcode. > The passcode allows access through kerberos, radius, or ldap binds > to linux servers, or with a custom apache module to websites. > > I have an out-of-band private network set up that attaches to our > intranet using a firewall/gateway server which does some port > forwarding for various things like SSH, RDP. > I?m attempting to set up RADIUS on this firewall/gateway to be used > as a proxy for freeipa to our token system which I?d like to be able > to use behind the firewall. > However I seem to be getting nearly a dozen requests into the radius > server, about half are dropped as duplicate, but usually 3-6 get > through and since it?s a single use token the first attempt > succeeds, but the rest fail and cause the hardware token to be > blacklisted. > Is there a way to specify that the user radius login is a one-time > token or is this something that sssd or pam is causing? > Or does the OTP support just not work in the way I need it to? > I have this issue with both the inbox 4.1.0 in RHEL7.1 or the > upstream 4.1.4 rpms. > > My only alternative is probably to set up a KDC on the firewall to > trust the institutional realm and have the IdM kerberos realm trust > that. > This is also a mixed linux/windows environment behind the firewall, > I?ve enabled unix attributes in my AD and I?m using a script to sync > uid/gid with the external ldap. I do think a cross realm trust is the right way to set this up. However, let's look more closely at the RADIUS issue. First, I want to ensure that you are using TCP for your kerberos connections. If you are using UDP for kerberos, then the kerberos client will send a new packet which will cause the KDC to fire off a new set of RADIUS messages. The use of TCP should be enforced with kerberos when using OTP. How long does it take for the hardware token RADIUS server to respond? Have you tried adjusting the number of retries and timeout for the RADIUS server in FreeIPA? A longer timeout or fewer retries will reduce the number of packets transmitted. If you are able to setup a test user with fake credentials and could perform a packet capture of kerberos and RADIUS traffic it would help me understand what is going on here. Nathaniel PS - If I had to take a guess based on what I know now, I would suspect that the real culprit is kinit sending too many requests. This is based on your statement that the RADIUS server is dropping *some* duplicates. This means that the other RADIUS packets are *not* duplicates and probably represent a subsequent AS-REQ on the KDC from kinit. From wgraboyes at cenic.org Wed May 13 23:40:14 2015 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 13 May 2015 16:40:14 -0700 Subject: [Freeipa-users] External Self Help Suggestions. Message-ID: <5553E0DE.2010502@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi List, I am trying to figure out a method of allowing users who do not have shell access to change their own passwords. The GUI that comes with FreeIPA is out of the question due to the untrusted CA (yes I know we are a strange shop, there is nothing I can do about it, and you would want to gouge you eyes out if I told you the full story) becoming a "Bad habit forming" method of changing one's password. I have been looking around for about a week now, and am somewhat lost and perplexed. The old documentation for FreeIPA basically says that it is not a good idea to manipulate the password directly in LDAP (and even then finding what hash is being used has been next to impossible). So the question is this, does anyone know of any tools out there that can happily, or even with some modification, allow me to set up a trusted external ssl site that allows users to change their passwords. Thanks, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX kzyr3+tqYdDbgibcYyhd =5KCr -----END PGP SIGNATURE----- From mail at willsheldon.com Wed May 13 23:50:29 2015 From: mail at willsheldon.com (Will Sheldon) Date: Wed, 13 May 2015 16:50:29 -0700 Subject: [Freeipa-users] Problems with failed upgrade: groups are not created Message-ID: Hello everyone :) We are seeing some strange behavior (created groups don't exist) and I really hope someone can lend some advice... We installed v 3.0 some time ago, and tried an upgrade to 3.3 which was aborted before completion, however I believe the schema was updated. Recently we attempted to upgrade to 4.1, but encountered some issues with the upgrade; replication failed : from the install log (before schema update, so server was running 3.3 schema): =======================> Done configuring ipa-otpd. Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure attribute "cn" not allowed =======================< After that we tried updating the schema, and we now get this error (we have log file captures for this): =======================> [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 131 seconds elapsed Update in progress yet not in progress [vanipa.foo.com] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ========================< which seems to be referring to this bit of the log: =======================> 2015-04-21T19:18:48Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) =======================< Since then we have a somewhat strange issue where new groups that are added using the web interface and ipa CLI command interface are created in the compat tree, but not in the cn=hostgroups,cn=accounts tree, even though ADD operations appear to complete successfully (slapd log output below) =======================> [13/May/2015:23:13:58 +0000] conn=7120402 op=4 ADD dn="cn=p-test-100,cn=hostgroups,cn=accounts,dc=foo,dc=com" [13/May/2015:23:13:58 +0000] conn=2616653 op=3660217 SRCH base="idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660217 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660218 SRCH base="idnsName= bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660218 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660219 SRCH base="idnsName= vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660219 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660220 SRCH base="idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660220 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660221 SRCH base="idnsName= bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660221 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660222 SRCH base="idnsName= vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660222 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=7120402 op=4 RESULT err=0 tag=105 nentries=0 etime=0 csn=5553e3f8000100040000 =======================< Which is consistent with the slapd log during the upgrade: [21/Apr/2015:19:18:43 +0000] NSACLPlugin - The ACL target cn=hr,cn=groups,cn=accounts,dc=foo,dc=com does not exist -- Kind regards, Will Sheldon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu May 14 00:00:35 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 May 2015 20:00:35 -0400 Subject: [Freeipa-users] External Self Help Suggestions. In-Reply-To: <5553E0DE.2010502@cenic.org> References: <5553E0DE.2010502@cenic.org> Message-ID: <5553E5A3.1080701@redhat.com> On 05/13/2015 07:40 PM, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi List, > > I am trying to figure out a method of allowing users who do not have > shell access to change their own passwords. The GUI that comes with > FreeIPA is out of the question due to the untrusted CA (yes I know we > are a strange shop, there is nothing I can do about it, and you would > want to gouge you eyes out if I told you the full story) becoming a > "Bad habit forming" method of changing one's password. I have been > looking around for about a week now, and am somewhat lost and > perplexed. The old documentation for FreeIPA basically says that it is > not a good idea to manipulate the password directly in LDAP (and even > then finding what hash is being used has been next to impossible). > > So the question is this, does anyone know of any tools out there that > can happily, or even with some modification, allow me to set up a > trusted external ssl site that allows users to change their passwords. There is no external password reset self service in IPA yet. We will be starting to look into this effort during summer. Take a look at the bucket of tickets in the "FreeIPA Community Portal Release" here https://fedorahosted.org/freeipa/report/3. What prevents you from making IPA trusted? You can chain IPA to your CA or use it CA-less with certs from your own CA. Then UI would be an option I assume. Other option is https://code.google.com/p/pwm/ > > Thanks, > Bill > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 > MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc > bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV > UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU > NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm > zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW > /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK > ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml > 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ > 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 > ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX > kzyr3+tqYdDbgibcYyhd > =5KCr > -----END PGP SIGNATURE----- > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From wgraboyes at cenic.org Thu May 14 00:18:48 2015 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 13 May 2015 17:18:48 -0700 Subject: [Freeipa-users] External Self Help Suggestions. In-Reply-To: <5553E5A3.1080701@redhat.com> References: <5553E0DE.2010502@cenic.org> <5553E5A3.1080701@redhat.com> Message-ID: <5553E9E8.4060901@cenic.org> Hi Dmitri, That is quite a bucket of stuff... On the CA-less install, basically I don't want to have my users change their passwords again (they are complaining about the every 90 day password rotation policy), we do not have an internal CA, most of our "desk top support" folks don't even have access to all of the desktops in the place. Like I said this place is mind bending when it comes to standard practices. The CA-less would be good if it were possible to make that change in place, or make the change by standing up a new IPA server and having the ability to import the current data set. I was looking at PWM, and may try to get that implemented. Thanks, Bill On 5/13/15 5:00 PM, Dmitri Pal wrote: > On 05/13/2015 07:40 PM, William Graboyes wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Hi List, > > > > I am trying to figure out a method of allowing users who do not have > > shell access to change their own passwords. The GUI that comes with > > FreeIPA is out of the question due to the untrusted CA (yes I know we > > are a strange shop, there is nothing I can do about it, and you would > > want to gouge you eyes out if I told you the full story) becoming a > > "Bad habit forming" method of changing one's password. I have been > > looking around for about a week now, and am somewhat lost and > > perplexed. The old documentation for FreeIPA basically says that it is > > not a good idea to manipulate the password directly in LDAP (and even > > then finding what hash is being used has been next to impossible). > > > > So the question is this, does anyone know of any tools out there that > > can happily, or even with some modification, allow me to set up a > > trusted external ssl site that allows users to change their passwords. > > There is no external password reset self service in IPA yet. We will be > starting to look into this effort during summer. > Take a look at the bucket of tickets in the "FreeIPA Community Portal > Release" here https://fedorahosted.org/freeipa/report/3. > > What prevents you from making IPA trusted? You can chain IPA to your CA > or use it CA-less with certs from your own CA. > Then UI would be an option I assume. > > Other option is https://code.google.com/p/pwm/ > > > > > Thanks, > > Bill > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > Comment: GPGTools - https://gpgtools.org > > > > iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 > > MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc > > bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV > > UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU > > NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm > > zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW > > /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK > > ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml > > 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ > > 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 > > ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX > > kzyr3+tqYdDbgibcYyhd > > =5KCr > > -----END PGP SIGNATURE----- > > > > From dpal at redhat.com Thu May 14 00:28:53 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 May 2015 20:28:53 -0400 Subject: [Freeipa-users] External Self Help Suggestions. In-Reply-To: <5553E9E8.4060901@cenic.org> References: <5553E0DE.2010502@cenic.org> <5553E5A3.1080701@redhat.com> <5553E9E8.4060901@cenic.org> Message-ID: <5553EC45.9060101@redhat.com> On 05/13/2015 08:18 PM, William Graboyes wrote: > Hi Dmitri, > > That is quite a bucket of stuff... On the CA-less install, basically I don't want to have my users change their passwords again (they are complaining about the every 90 day password rotation policy), we do not have an internal CA, most of our "desk top support" folks don't even have access to all of the desktops in the place. Like I said this place is mind bending when it comes to standard practices. The CA-less would be good if it were possible to make that change in place, or make the change by standing up a new IPA server and having the ability to import the current data set. > > I was looking at PWM, and may try to get that implemented. Another option is to reset expiration time in the user entry and set it some date close to 2038 which is the end of the 32-bit time. If the problem is 90 day policy you can just change the policy to be 5000 days and then next time people change password they would not be bother for another 5000 days or so (make sure it does not roll over). For people that already have 90 days in their entry you can run a script once and move the date into the future. People have done it for the same reason and in the same way. > > Thanks, > Bill > > On 5/13/15 5:00 PM, Dmitri Pal wrote: >> On 05/13/2015 07:40 PM, William Graboyes wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> Hi List, >>> >>> I am trying to figure out a method of allowing users who do not have >>> shell access to change their own passwords. The GUI that comes with >>> FreeIPA is out of the question due to the untrusted CA (yes I know we >>> are a strange shop, there is nothing I can do about it, and you would >>> want to gouge you eyes out if I told you the full story) becoming a >>> "Bad habit forming" method of changing one's password. I have been >>> looking around for about a week now, and am somewhat lost and >>> perplexed. The old documentation for FreeIPA basically says that it is >>> not a good idea to manipulate the password directly in LDAP (and even >>> then finding what hash is being used has been next to impossible). >>> >>> So the question is this, does anyone know of any tools out there that >>> can happily, or even with some modification, allow me to set up a >>> trusted external ssl site that allows users to change their passwords. >> There is no external password reset self service in IPA yet. We will be >> starting to look into this effort during summer. >> Take a look at the bucket of tickets in the "FreeIPA Community Portal >> Release" here https://fedorahosted.org/freeipa/report/3. >> >> What prevents you from making IPA trusted? You can chain IPA to your CA >> or use it CA-less with certs from your own CA. >> Then UI would be an option I assume. >> >> Other option is https://code.google.com/p/pwm/ >> >>> Thanks, >>> Bill >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>> Comment: GPGTools - https://gpgtools.org >>> >>> iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 >>> MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc >>> bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV >>> UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU >>> NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm >>> zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW >>> /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK >>> ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml >>> 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ >>> 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 >>> ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX >>> kzyr3+tqYdDbgibcYyhd >>> =5KCr >>> -----END PGP SIGNATURE----- >>> >> -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From nathan at nathanpeters.com Thu May 14 02:58:30 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 13 May 2015 19:58:30 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR Message-ID: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> I have tried to setup synchronization between a FreeIPA domain and an AD domain. The certificates are in the right place. [root at ipadc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=sync user,cn=Users,dc=datacenter,dc=addomain,dc=net" --bindpw secretpassword --passsync secretpassword --cacert /etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to certificate database for ipadc1.ipadomain.net ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net Windows PassSync system account exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication This is the system journal while the failure is happening May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory Server IPADOMAIN-NET.... May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't contact LDAP server: ldap_sync_poll() failed May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl will reconnect in 60 seconds May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa : ERROR syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP server"}) May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback (most recent call last): May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 106, in May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 349, in syncrepl_poll May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: add_intermediates=1, add_ctrls=1, all = 0 May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in result4 May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in _ldap_call May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result = func(*args,**kwargs) May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN: {'desc': "Can't contact LDAP server"} May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory Server IPADOMAIN-NET.. May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory Server IPADOMAIN-NET.... May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory Server IPADOMAIN-NET.. May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: Configured NSS Ciphers May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 +0000] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: connection to the LDAP server was lost May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 1 May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 2 May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 3 May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: successfully reconnected to LDAP server May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP instance 'ipa' is being synchronized, please ignore message 'all zones loaded' May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't contact LDAP server: while modifying(replace) entry 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: retrying LDAP operation (modifying(replace)) on entry 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't contact LDAP server: connection error May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling restart. May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Stopping IPA key daemon... May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Starting IPA key daemon... May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Started IPA key daemon. May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 1 May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 2 May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 3 May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: successfully reconnected to LDAP server May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone 19.21.10.in-addr.arpa/IN: loaded serial 1431571902 May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone ipadomain.net/IN: loaded serial 1431571901 May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: 2 master zones from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 0 failed to load) May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 1 May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 2 May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 2 May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 3 May 14 02:51:43 ipadc1.ipadomain.net ipa-dnskeysyncd[3318]: ipa : INFO LDAP bind... From jpazdziora at redhat.com Thu May 14 07:38:49 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 14 May 2015 09:38:49 +0200 Subject: [Freeipa-users] FreeIPA server in Docker container improved In-Reply-To: <20150408124238.GA5498@redhat.com> References: <20150408124238.GA5498@redhat.com> Message-ID: <20150514073849.GP6587@redhat.com> On Wed, Apr 08, 2015 at 02:42:38PM +0200, Jan Pazdziora wrote: > > The ability to run FreeIPA server in a container was recently > improved by adding support for storing the server configuration and > data in a volume, making it easier to backup the server, upgrade it to > newer versions, as well as adding the ability to start a container > as a replica of existing (containerized or non-containerized) IPA > server. > > Using IPA in a container can be an easy way to try IPA or test things > on different OSes (there are multiple per-OS branches in the GitHub > repo and multiple images built), as well as running IPA on a machine > where it would otherwise clash with other software. It it still > an unsupported release but working in multiple tests on our side, so > we encourage our community members to try it out. > > We will welcome your comments about your experience with the code at > > https://github.com/adelton/docker-freeipa I gave presentation on EurOpen conference yesterday about the FreeIPA containerization work: http://www.adelton.com/docs/docker/nontrivial-application-in-container It explains the approach and the reasons for the layout of the image. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Thu May 14 08:44:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 May 2015 10:44:09 +0200 Subject: [Freeipa-users] Problems with failed upgrade: groups are not created In-Reply-To: References: Message-ID: <55546059.60003@redhat.com> On 14/05/15 01:50, Will Sheldon wrote: > > Hello everyone :) > > We are seeing some strange behavior (created groups don't exist) and I > really hope someone can lend some advice... > > We installed v 3.0 some time ago, and tried an upgrade to 3.3 which > was aborted before completion, however I believe the schema was updated. > > Recently we attempted to upgrade to 4.1, but encountered some issues > with the upgrade; replication failed : > > from the install log (before schema update, so server was running 3.3 > schema): > > =======================> > Done configuring ipa-otpd. > Applying LDAP updates > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure > attribute "cn" not allowed > =======================< > > > After that we tried updating the schema, and we now get this error (we > have log file captures for this): > > =======================> > [24/35]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 131 seconds elapsed > Update in progress yet not in progress > > [vanipa.foo.com ] reports: Update failed! > Status: [10 Total update abortedLDAP error: Referral] > > [error] RuntimeError: Failed to start replication > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > ========================< > > which seems to be referring to this bit of the log: > =======================> > 2015-04-21T19:18:48Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 382, in start_creation > run_step(full_msg, method) > =======================< > > > Since then we have a somewhat strange issue where new groups that are > added using the web interface and ipa CLI command interface are > created in the compat tree, but not in the cn=hostgroups,cn=accounts > tree, even though ADD operations appear to complete successfully > (slapd log output below) > > =======================> > [13/May/2015:23:13:58 +0000] conn=7120402 op=4 ADD > dn="cn=p-test-100,cn=hostgroups,cn=accounts,dc=foo,dc=com" > > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660217 SRCH > base="idnsName=net,idnsname=bar.net > ,cn=dns,dc=foo,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660217 RESULT err=32 > tag=101 nentries=0 etime=0 > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660218 SRCH > base="idnsName=bar.net ,idnsname=bar.net > ,cn=dns,dc=foo,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660218 RESULT err=32 > tag=101 nentries=0 etime=0 > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660219 SRCH > base="idnsName=vanzbx.bar.net ,idnsname=bar.net > ,cn=dns,dc=foo,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660219 RESULT err=32 > tag=101 nentries=0 etime=0 > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660220 SRCH > base="idnsName=net,idnsname=bar.net > ,cn=dns,dc=foo,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660220 RESULT err=32 > tag=101 nentries=0 etime=0 > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660221 SRCH > base="idnsName=bar.net ,idnsname=bar.net > ,cn=dns,dc=foo,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660221 RESULT err=32 > tag=101 nentries=0 etime=0 > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660222 SRCH > base="idnsName=vanzbx.bar.net ,idnsname=bar.net > ,cn=dns,dc=foo,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [13/May/2015:23:13:58 +0000] conn=2616653 op=3660222 RESULT err=32 > tag=101 nentries=0 etime=0 > [13/May/2015:23:13:58 +0000] conn=7120402 op=4 RESULT err=0 tag=105 > nentries=0 etime=0 csn=5553e3f8000100040000 > =======================< > > > Which is consistent with the slapd log during the upgrade: > > [21/Apr/2015:19:18:43 +0000] NSACLPlugin - The ACL target > cn=hr,cn=groups,cn=accounts,dc=foo,dc=com does not exist > > -- > > Kind regards, > > Will Sheldon > > > Hello, can you find in ipaserver-install.log more details about this error? ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure attribute "cn" not allowed Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmoncayo at ingenia.es Thu May 14 09:58:41 2015 From: rmoncayo at ingenia.es (Remigio Moncayo Serrano) Date: Thu, 14 May 2015 09:58:41 +0000 Subject: [Freeipa-users] Configuration of CA failed Message-ID: <0A2A5163954B3342B82944846B7FD995149006@lexus.ingenia.local> Hello, I've been put in charge of implementing a solution that uses LDAP and kerberos authentication. At first thought I should use openLDAP and Kerberos but found freeIPA and looks really cool, however, when trying to install I keep getting this error about configuration of CA: The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server ipa : CRITICAL Failed to restart the directory server. See the installation log for details. Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipatest.ingenia.local -cs_port 9445 -client_certdb_dir /tmp/tmp-ARezzO -client_certdb_pwd XXXXXXXX -preop_pin f0dLhx9bLX5qWHYx50h6 -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host ipatest.ingenia.local -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INGENIA.LOCAL -ca_server_cert_subject_name CN=ipatest.ingenia.local,O=INGENIA.LOCAL -ca_audit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL -ca_sign_cert_subject_name CN=Certificate Authority,O=INGENIA.LOCAL -external false -clone false' returned non-zero exit status 255 Configuration of CA failed I'm including two install logs, one with dns-setup and the other without it. Don't really know what I'm doing wrong, thought maybe I should allow connections to certain ports in ip tables or something but have no clue really and I'm quite new to this, help please.. Regards, Remigio -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaserver-install.log Type: application/octet-stream Size: 18198 bytes Desc: ipaserver-install.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaserver-install1.log Type: application/octet-stream Size: 18474 bytes Desc: ipaserver-install1.log URL: From mkosek at redhat.com Thu May 14 10:59:00 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 May 2015 12:59:00 +0200 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> Message-ID: <55547FF4.3060100@redhat.com> On 05/14/2015 04:58 AM, nathan at nathanpeters.com wrote: > I have tried to setup synchronization between a FreeIPA domain and an AD > domain. The certificates are in the right place. > > [root at ipadc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=sync > user,cn=Users,dc=datacenter,dc=addomain,dc=net" --bindpw secretpassword > --passsync secretpassword --cacert > /etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net > -v > Directory Manager password: > > Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to > certificate database for ipadc1.ipadomain.net > ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net > Windows PassSync system account exists, not resetting password > ipa: INFO: Added new sync agreement, waiting for it to become ready . . . > ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP > error: Connect error: start: 0: end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > > [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP error: > Connect error] > > Failed to start replication > > > This is the system journal while the failure is happening > > May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory > Server IPADOMAIN-NET.... > May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't > contact LDAP server: ldap_sync_poll() failed > May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl > will reconnect in 60 seconds > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa : > ERROR syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP server"}) > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback > (most recent call last): > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File > "/usr/libexec/ipa/ipa-dnskeysyncd", line 106, in > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while > ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 349, in > syncrepl_poll > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: > add_intermediates=1, add_ctrls=1, all = 0 > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File > "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in > result4 > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result = > self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File > "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in > _ldap_call > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result = > func(*args,**kwargs) > May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN: > {'desc': "Can't contact LDAP server"} > May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service: > main process exited, code=exited, status=1/FAILURE > May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit > ipa-dnskeysyncd.service entered failed state. > May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory > Server IPADOMAIN-NET.. > May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory > Server IPADOMAIN-NET.... > May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory > Server IPADOMAIN-NET.. > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, > max: TLS1.2 > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: Configured NSS Ciphers > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: > enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: > enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41 > +0000] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: connection to the > LDAP server was lost > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 1 > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 2 > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 > May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 3 > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: successfully > reconnected to LDAP server > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP instance > 'ipa' is being synchronized, please ignore message 'all zones loaded' > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't > contact LDAP server: while modifying(replace) entry > 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: retrying LDAP > operation (modifying(replace)) on entry > 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't > contact LDAP server: connection error > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service > holdoff time over, scheduling restart. > May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Stopping IPA key daemon... > May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Starting IPA key daemon... > May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Started IPA key daemon. > May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 1 > May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 2 > May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 > May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 3 > May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: successfully > reconnected to LDAP server > May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone > 19.21.10.in-addr.arpa/IN: loaded serial 1431571902 > May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone > ipadomain.net/IN: loaded serial 1431571901 > May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: 2 master zones > from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 0 failed to > load) > May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 > May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 > May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 1 > May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 > May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 2 > May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 2 > May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step 3 > May 14 02:51:43 ipadc1.ipadomain.net ipa-dnskeysyncd[3318]: ipa : > INFO LDAP bind... CCing Alexander. I wonder if it is related to https://bugzilla.redhat.com/show_bug.cgi?id=1215010 If your AD has the MS update mentioned in the bug and has a CA cert with SHA-512 signing, then may be hitting this bug. From mkosek at redhat.com Thu May 14 11:02:50 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 May 2015 13:02:50 +0200 Subject: [Freeipa-users] Configuration of CA failed In-Reply-To: <0A2A5163954B3342B82944846B7FD995149006@lexus.ingenia.local> References: <0A2A5163954B3342B82944846B7FD995149006@lexus.ingenia.local> Message-ID: <555480DA.1070304@redhat.com> On 05/14/2015 11:58 AM, Remigio Moncayo Serrano wrote: > Hello, > > I've been put in charge of implementing a solution that uses LDAP and kerberos authentication. At first thought I should use openLDAP and Kerberos but found freeIPA and looks really cool, however, when trying to install I keep getting this error about configuration of CA: > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server for the CA (pkids): Estimated time 30 seconds > [1/3]: creating directory server user > [2/3]: creating directory server instance > [3/3]: restarting directory server > ipa : CRITICAL Failed to restart the directory server. See the installation log for details. > Done configuring directory server for the CA (pkids). > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds > [1/20]: creating certificate server user > [2/20]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipatest.ingenia.local -cs_port 9445 -client_certdb_dir /tmp/tmp-ARezzO -client_certdb_pwd XXXXXXXX -preop_pin f0dLhx9bLX5qWHYx50h6 -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host ipatest.ingenia.local -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INGENIA.LOCAL -ca_server_cert_subject_name CN=ipatest.ingenia.local,O=INGENIA.L! OCAL -ca_a udit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL -ca_sign_cert_subject_name CN=Certificate Authority,O=INGENIA.LOCAL -external false -clone false' returned non-zero exit status 255 > Configuration of CA failed > > I'm including two install logs, one with dns-setup and the other without it. Don't really know what I'm doing wrong, thought maybe I should allow connections to certain ports in ip tables or something but have no clue really and I'm quite new to this, help please.. > > Regards, > > Remigio Hello, What platform are you using (Fedora? CentOS? RHEL?) and what version of FreeIPA are you using? Also, I following error in the log java.net.ConnectException: Connection refused So it seems some port is occupied. Is your port 8443 occupied? Maybe by running httpd daemon before the installation? Martin From mbasti at redhat.com Thu May 14 11:04:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 May 2015 13:04:36 +0200 Subject: [Freeipa-users] Configuration of CA failed In-Reply-To: <0A2A5163954B3342B82944846B7FD995149006@lexus.ingenia.local> References: <0A2A5163954B3342B82944846B7FD995149006@lexus.ingenia.local> Message-ID: <55548144.9000607@redhat.com> On 14/05/15 11:58, Remigio Moncayo Serrano wrote: > > Hello, > > I?ve been put in charge of implementing a solution that uses LDAP and > kerberos authentication. At first thought I should use openLDAP and > Kerberos but found freeIPA and looks really cool, however, when trying > to install I keep getting this error about configuration of CA: > > The following operations may take some minutes to complete. > > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > > [1/4]: stopping ntpd > > [2/4]: writing configuration > > [3/4]: configuring ntpd to start on boot > > [4/4]: starting ntpd > > Done configuring NTP daemon (ntpd). > > Configuring directory server for the CA (pkids): Estimated time 30 seconds > > [1/3]: creating directory server user > > [2/3]: creating directory server instance > > [3/3]: restarting directory server > > ipa : CRITICAL Failed to restart the directory server. See the > installation log for details. > > Done configuring directory server for the CA (pkids). > > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > seconds > > [1/20]: creating certificate server user > > [2/20]: configuring certificate server instance > > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ipatest.ingenia.local -cs_port 9445 -client_certdb_dir /tmp/tmp-ARezzO > -client_certdb_pwd XXXXXXXX -preop_pin f0dLhx9bLX5qWHYx50h6 > -domain_name IPA -admin_user admin -admin_email root at localhost > -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 > -agent_key_type rsa -agent_cert_subject > CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host ipatest.ingenia.local > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX > -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa > -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX > -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INGENIA.LOCAL > -ca_server_cert_subject_name CN=ipatest.ingenia.local,O=INGENIA.LOCAL > -ca_audit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL > -ca_sign_cert_subject_name CN=Certificate Authority,O=INGENIA.LOCAL > -external false -clone false' returned non-zero exit status 255 > > Configuration of CA failed > > I?m including two install logs, one with dns-setup and the other > without it. Don?t really know what I?m doing wrong, thought maybe I > should allow connections to certain ports in ip tables or something > but have no clue really and I?m quite new to this, help please.. > > Regards, > > Remigio > > > Hello, can you please check error logs of DS? /var/log/dirsrv/slapd-*/errors And please post here an error why DS restart failed. Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From bahmer at lanl.gov Wed May 13 19:01:27 2015 From: bahmer at lanl.gov (Bahmer, Eric Vaughn) Date: Wed, 13 May 2015 19:01:27 +0000 Subject: [Freeipa-users] ipa spamming radius with otp token? In-Reply-To: <1431540030.3260.53.camel@redhat.com> Message-ID: I?ll have to look into the the ports on the idm server then, I?m not overly familiar with firewalld, I tried to install iptables and use the rules I had before I rebuilt the box as RHEL7.1 from RHEL6.6 to test. But it wouldn?t take, so I ended up turning firewalld off during testing since it was behind the other firewall/gateway server. It probably is using UDP for the connections then, I know you can set an option in kerberos to use tcp depending on the packet size, but it still falls back to udp if the attempt fails. The hardware token radius varies on response time depending on which configuration I?m using on the firewall/gateway machine. If I had them unblock me at the institutional side I can proxy my radius off their radius and the config is identical to another sub-network that works fairly quick, couple seconds at most. The other config uses ldap and takes several seconds since it has to first open the connection, start tls, pass the root certificate, authenticate as the top level for the realm, fetch user information, then rebind as the user with the token. I have not yet tried to use ldap just for the accounting section in my radius with kerberos as the auth mechanism on their side since I?d probably have to request a radius principal for the firewall/gateway server since I don?t own the intranet realm, but I expect it to be nearly as slow having to take so many extra steps. I will give setting up firewalld a go then to restrict udp. Since you mentioned that a cross-realm trust is probably better in this case (I could always go back to using ipa-3.x on RHEL6), assuming the following: Some names changed to protect the guilty. Vlans 4-windows, 5-nfs (though I can use for some general traffic as well), 6-management This is to keep certain types of traffic isolated by vlan and restrict user access. Internal networks mostly use 10.vlan.switch.x and are not registered with the institutional kdc. Intranet realm: example.gov (in lowercase unfortunately) My firewall server: mon-gate1.example.gov ? external network, internal vlans 5/6 My internal idm: idm2.manage.monitor.net ? vlans 4,5,6 full ipa-server realm is MANAGE.MONITOR.NET owns domain manage.monitor.net on vlan 6 and also serves dns for monitor.net on vlan5, I needed a bare-metal dns on the management vlan for vm host machines. My windows ad: mon-ad.windows.monitor.net ? vlans 4,5,6, owns domain windows.monitor.net on vlan4 and is a vm. I already have a trust between manage.monitor.net and windows.monitor.net, but not the groups or account mapping since I need consistent uid/gid. I?m assuming I need to set up a kdc on the firewall/gateway mon-gate1.example.gov, and have idm trust that, or both idm and the ad trust it, but have the kdc on the firewall/gateway trust the example.gov intranet realm. The only place I?m confused is how to set up the kdc on the gateway as it?s multi-homed, I?m assuming it needs to use it?s own intranet resolvable fqdn but with a different realm name like BRIDGE.MONITOR.NET or something and make sure that krb5.conf indicates that mon-gate1.example.gov is part of the realm. How I get it done isn?t quite as important is that I can use our hardware token behind the gateway as I?m required, for security reasons. On 5/13/15, 12:00 PM, "Nathaniel McCallum" wrote: >On Wed, 2015-05-13 at 14:44 +0000, Bahmer, Eric Vaughn wrote: >> Institutionally we have a hardware token set up, you use a pin to >> unlock the device and it spits out a passcode. >> The passcode allows access through kerberos, radius, or ldap binds >> to linux servers, or with a custom apache module to websites. >> >> I have an out-of-band private network set up that attaches to our >> intranet using a firewall/gateway server which does some port >> forwarding for various things like SSH, RDP. >> I?m attempting to set up RADIUS on this firewall/gateway to be used >> as a proxy for freeipa to our token system which I?d like to be able >> to use behind the firewall. >> However I seem to be getting nearly a dozen requests into the radius >> server, about half are dropped as duplicate, but usually 3-6 get >> through and since it?s a single use token the first attempt >> succeeds, but the rest fail and cause the hardware token to be >> blacklisted. >> Is there a way to specify that the user radius login is a one-time >> token or is this something that sssd or pam is causing? >> Or does the OTP support just not work in the way I need it to? >> I have this issue with both the inbox 4.1.0 in RHEL7.1 or the >> upstream 4.1.4 rpms. >> >> My only alternative is probably to set up a KDC on the firewall to >> trust the institutional realm and have the IdM kerberos realm trust >> that. >> This is also a mixed linux/windows environment behind the firewall, >> I?ve enabled unix attributes in my AD and I?m using a script to sync >> uid/gid with the external ldap. > >I do think a cross realm trust is the right way to set this up. > >However, let's look more closely at the RADIUS issue. > >First, I want to ensure that you are using TCP for your kerberos >connections. If you are using UDP for kerberos, then the kerberos >client will send a new packet which will cause the KDC to fire off a >new set of RADIUS messages. The use of TCP should be enforced with >kerberos when using OTP. > > >How long does it take for the hardware token RADIUS server to respond? >Have you tried adjusting the number of retries and timeout for the >RADIUS server in FreeIPA? A longer timeout or fewer retries will >reduce the number of packets transmitted. > >If you are able to setup a test user with fake credentials and could >perform a packet capture of kerberos and RADIUS traffic it would help >me understand what is going on here. > >Nathaniel > >PS - If I had to take a guess based on what I know now, I would >suspect that the real culprit is kinit sending too many requests. This >is based on your statement that the RADIUS server is dropping *some* >duplicates. This means that the other RADIUS packets are *not* >duplicates and probably represent a subsequent AS-REQ on the KDC from >kinit. From dpal at redhat.com Thu May 14 13:39:08 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 14 May 2015 09:39:08 -0400 Subject: [Freeipa-users] ipa spamming radius with otp token? In-Reply-To: References: Message-ID: <5554A57C.6040101@redhat.com> On 05/13/2015 03:01 PM, Bahmer, Eric Vaughn wrote: > I?ll have to look into the the ports on the idm server then, I?m not > overly familiar with firewalld, I tried to install iptables and use the > rules I had before I rebuilt the box as RHEL7.1 from RHEL6.6 to test. > But it wouldn?t take, so I ended up turning firewalld off during testing > since it was behind the other firewall/gateway server. > It probably is using UDP for the connections then, I know you can set an > option in kerberos to use tcp depending on the packet size, but it still > falls back to udp if the attempt fails. > > The hardware token radius varies on response time depending on which > configuration I?m using on the firewall/gateway machine. > If I had them unblock me at the institutional side I can proxy my radius > off their radius and the config is identical to another sub-network that > works fairly quick, couple seconds at most. > The other config uses ldap and takes several seconds since it has to first > open the connection, start tls, pass the root certificate, authenticate as > the top level for the realm, fetch user information, then rebind as the > user with the token. > I have not yet tried to use ldap just for the accounting section in my > radius with kerberos as the auth mechanism on their side since I?d > probably have to request a radius principal for the firewall/gateway > server since I don?t own the intranet realm, but I expect it to be nearly > as slow having to take so many extra steps. > > I will give setting up firewalld a go then to restrict udp. > > > > Since you mentioned that a cross-realm trust is probably better in this > case (I could always go back to using ipa-3.x on RHEL6), assuming the > following: > > Some names changed to protect the guilty. > Vlans 4-windows, 5-nfs (though I can use for some general traffic as > well), 6-management > This is to keep certain types of traffic isolated by vlan and restrict > user access. > Internal networks mostly use 10.vlan.switch.x and are not registered with > the institutional kdc. > > Intranet realm: example.gov (in lowercase unfortunately) > My firewall server: mon-gate1.example.gov ? external network, internal > vlans 5/6 > My internal idm: idm2.manage.monitor.net ? vlans 4,5,6 full ipa-server > realm is MANAGE.MONITOR.NET owns domain manage.monitor.net on vlan 6 and > also serves dns for monitor.net on vlan5, I needed a bare-metal dns on the > management vlan for vm host machines. > My windows ad: mon-ad.windows.monitor.net ? vlans 4,5,6, owns domain > windows.monitor.net on vlan4 and is a vm. > I already have a trust between manage.monitor.net and windows.monitor.net, > but not the groups or account mapping since I need consistent uid/gid. > I?m assuming I need to set up a kdc on the firewall/gateway > mon-gate1.example.gov, and have idm trust that, or both idm and the ad > trust it, but have the kdc on the firewall/gateway trust the example.gov > intranet realm. > The only place I?m confused is how to set up the kdc on the gateway as > it?s multi-homed, I?m assuming it needs to use it?s own intranet > resolvable fqdn but with a different realm name like BRIDGE.MONITOR.NET or > something and make sure that krb5.conf indicates that > mon-gate1.example.gov is part of the realm. > > > How I get it done isn?t quite as important is that I can use our hardware > token behind the gateway as I?m required, for security reasons. There is a bit too much complexity to digest in one mail. It would be beneficial to have a diagram and comments around it to try to understand your environment and goals. The only other comment I would make is that trust is not supported in RHEL6.x it is in tech preview and it is done differently in RHEL7 where it is supported. Using 7.1 is recommended. > > > On 5/13/15, 12:00 PM, "Nathaniel McCallum" wrote: > >> On Wed, 2015-05-13 at 14:44 +0000, Bahmer, Eric Vaughn wrote: >>> Institutionally we have a hardware token set up, you use a pin to >>> unlock the device and it spits out a passcode. >>> The passcode allows access through kerberos, radius, or ldap binds >>> to linux servers, or with a custom apache module to websites. >>> >>> I have an out-of-band private network set up that attaches to our >>> intranet using a firewall/gateway server which does some port >>> forwarding for various things like SSH, RDP. >>> I?m attempting to set up RADIUS on this firewall/gateway to be used >>> as a proxy for freeipa to our token system which I?d like to be able >>> to use behind the firewall. >>> However I seem to be getting nearly a dozen requests into the radius >>> server, about half are dropped as duplicate, but usually 3-6 get >>> through and since it?s a single use token the first attempt >>> succeeds, but the rest fail and cause the hardware token to be >>> blacklisted. >>> Is there a way to specify that the user radius login is a one-time >>> token or is this something that sssd or pam is causing? >>> Or does the OTP support just not work in the way I need it to? >>> I have this issue with both the inbox 4.1.0 in RHEL7.1 or the >>> upstream 4.1.4 rpms. >>> >>> My only alternative is probably to set up a KDC on the firewall to >>> trust the institutional realm and have the IdM kerberos realm trust >>> that. >>> This is also a mixed linux/windows environment behind the firewall, >>> I?ve enabled unix attributes in my AD and I?m using a script to sync >>> uid/gid with the external ldap. >> I do think a cross realm trust is the right way to set this up. >> >> However, let's look more closely at the RADIUS issue. >> >> First, I want to ensure that you are using TCP for your kerberos >> connections. If you are using UDP for kerberos, then the kerberos >> client will send a new packet which will cause the KDC to fire off a >> new set of RADIUS messages. The use of TCP should be enforced with >> kerberos when using OTP. >> >> >> How long does it take for the hardware token RADIUS server to respond? >> Have you tried adjusting the number of retries and timeout for the >> RADIUS server in FreeIPA? A longer timeout or fewer retries will >> reduce the number of packets transmitted. >> >> If you are able to setup a test user with fake credentials and could >> perform a packet capture of kerberos and RADIUS traffic it would help >> me understand what is going on here. >> >> Nathaniel >> >> PS - If I had to take a guess based on what I know now, I would >> suspect that the real culprit is kinit sending too many requests. This >> is based on your statement that the RADIUS server is dropping *some* >> duplicates. This means that the other RADIUS packets are *not* >> duplicates and probably represent a subsequent AS-REQ on the KDC from >> kinit. > -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From david.little2 at gmail.com Thu May 14 14:15:29 2015 From: david.little2 at gmail.com (David Little) Date: Thu, 14 May 2015 10:15:29 -0400 Subject: [Freeipa-users] Replacing HTTP certs with public CA signed wildcard cert Message-ID: Hi there, I was reading this document regarding using 3rd party certificates in FreeIPA: https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP Which includes the information "The certificate in mysite.crt must be signed by the CA used when installing FreeIPA." Also this thread: http://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html Which says at the end " I'm wondering if it's because of this from the doc "The certificate in mysite.crt must be signed by the CA used when installing FreeIPA." but it might not either... In this case you should get a "file.p12 is not signed by /etc/ipa/ca.crt, or the full certificate chain is not present in the PKCS#12 file" error in ipa-server-certinstall." This brings me to my question... If I have an existing multi-server FreeIPA setup with multiple IPA client installations, using a self-signed CA certificate for /etc/ipa/ca.crt, would I need to start over the FreeIPA installation from scratch using the public root CA, which signed the wildcard certificate? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Thu May 14 15:33:28 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Thu, 14 May 2015 15:33:28 +0000 Subject: [Freeipa-users] trusted user groups Message-ID: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. Is there a chance that information will be dropped again at any point going forward? The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? Running sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-client-3.0.0-42.el6.x86_64 on RHEL6x clients against a RHEL7 4.1 ipa server thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From jhrozek at redhat.com Thu May 14 15:45:32 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 14 May 2015 17:45:32 +0200 Subject: [Freeipa-users] trusted user groups In-Reply-To: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> References: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> Message-ID: <20150514154532.GK2709@hendrix> On Thu, May 14, 2015 at 03:33:28PM +0000, Andy Thompson wrote: > I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. > Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. > > The reason I ask is that on our sftp boxes we chroot users based on group > membership. I set that up as an external group in freeIPA and the first > time the user logs in to the sftp box, they are dropped in their normal > home directory as opposed to the chroot environment. If there is a chance > the group membership will not show up correctly again in the future, I'm > inclined to change the chroot stanzas to match on user as opposed to group. > > Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? > > Running > > sssd-ipa-1.11.6-30.el6_6.4.x86_64 > ipa-client-3.0.0-42.el6.x86_64 > > on RHEL6x clients against a RHEL7 4.1 ipa server > > thanks > > -andy > > > > *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** > > > -- > 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 From Andy.Thompson at e-tcc.com Thu May 14 15:53:53 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Thu, 14 May 2015 15:53:53 +0000 Subject: [Freeipa-users] trusted user groups In-Reply-To: <20150514154532.GK2709@hendrix> References: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> <20150514154532.GK2709@hendrix> Message-ID: <19fca29e79eb4635acddd4a9f3be20d3@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Thursday, May 14, 2015 11:46 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trusted user groups > > On Thu, May 14, 2015 at 03:33:28PM +0000, Andy Thompson wrote: > > I've noticed that trusted users supplementary ad groups don't show up > until after the users login to the box at least once. > > That's expected with the versions you're running. Prior to 6.7, we could only > read the trusted users' group membership from the PAC blob attached to > the Kerberos ticket. > > > > Is there a chance that information will be dropped again at any point going > forward? > > No, otherwise it's a bug. > > > > > The reason I ask is that on our sftp boxes we chroot users based on > > group membership. I set that up as an external group in freeIPA and > > the first time the user logs in to the sftp box, they are dropped in > > their normal home directory as opposed to the chroot environment. If > > there is a chance the group membership will not show up correctly > > again in the future, I'm inclined to change the chroot stanzas to match on > user as opposed to group. > > > > Is that by design? > > If you can't see the correct group memberships after a login, then something > is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many > fixes and enhancements in this area..is there a chance you could try out 6.7 > beta or some custom packages? > Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Thanks much -andy From mbasti at redhat.com Thu May 14 17:26:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 May 2015 19:26:11 +0200 Subject: [Freeipa-users] Configuration of CA failed In-Reply-To: <0A2A5163954B3342B82944846B7FD995149055@lexus.ingenia.local> References: <0A2A5163954B3342B82944846B7FD995149006@lexus.ingenia.local> <55548144.9000607@redhat.com> <0A2A5163954B3342B82944846B7FD995149055@lexus.ingenia.local> Message-ID: <5554DAB3.9090603@redhat.com> On 14/05/15 13:54, Remigio Moncayo Serrano wrote: > > I fail to see the problem in the logs so I?m attaching the file here > > *De:*Martin Basti [mailto:mbasti at redhat.com] > *Enviado el:* jueves, 14 de mayo de 2015 13:05 > *Para:* Remigio Moncayo Serrano; freeipa-users at redhat.com > *Asunto:* Re: [Freeipa-users] Configuration of CA failed > > On 14/05/15 11:58, Remigio Moncayo Serrano wrote: > > Hello, > > I?ve been put in charge of implementing a solution that uses LDAP > and kerberos authentication. At first thought I should use > openLDAP and Kerberos but found freeIPA and looks really cool, > however, when trying to install I keep getting this error about > configuration of CA: > > The following operations may take some minutes to complete. > > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > > [1/4]: stopping ntpd > > [2/4]: writing configuration > > [3/4]: configuring ntpd to start on boot > > [4/4]: starting ntpd > > Done configuring NTP daemon (ntpd). > > Configuring directory server for the CA (pkids): Estimated time 30 > seconds > > [1/3]: creating directory server user > > [2/3]: creating directory server instance > > [3/3]: restarting directory server > > ipa : CRITICAL Failed to restart the directory server. See > the installation log for details. > > Done configuring directory server for the CA (pkids). > > Configuring certificate server (pki-cad): Estimated time 3 minutes > 30 seconds > > [1/20]: creating certificate server user > > [2/20]: configuring certificate server instance > > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ipatest.ingenia.local -cs_port 9445 -client_certdb_dir > /tmp/tmp-ARezzO -client_certdb_pwd XXXXXXXX -preop_pin > f0dLhx9bLX5qWHYx50h6 -domain_name IPA -admin_user admin > -admin_email root at localhost -admin_password XXXXXXXX -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host > ipatest.ingenia.local -ldap_port 7389 -bind_dn cn=Directory > Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca > -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA > -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad > -token_name internal -ca_subsystem_cert_subject_name CN=CA > Subsystem,O=INGENIA.LOCAL -ca_subsystem_cert_subject_name CN=CA > Subsystem,O=INGENIA.LOCAL -ca_ocsp_cert_subject_name CN=OCSP > Subsystem,O=INGENIA.LOCAL -ca_server_cert_subject_name > CN=ipatest.ingenia.local,O=INGENIA.LOCAL > -ca_audit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL > -ca_sign_cert_subject_name CN=Certificate > Authority,O=INGENIA.LOCAL -external false -clone false' returned > non-zero exit status 255 > > Configuration of CA failed > > I?m including two install logs, one with dns-setup and the other > without it. Don?t really know what I?m doing wrong, thought maybe > I should allow connections to certain ports in ip tables or > something but have no clue really and I?m quite new to this, help > please.. > > Regards, > > Remigio > > > > Hello, > > can you please check error logs of DS? > /var/log/dirsrv/slapd-*/errors > > And please post here an error why DS restart failed. > > Martin > > -- > Martin Basti indeed, log looks good. There is some issue that IPA cannot verify DS on port 7389. Can you answer the questions asked by Martin Kosek, please? Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Thu May 14 19:56:22 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 14 May 2015 12:56:22 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <55547FF4.3060100@redhat.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> Message-ID: <2e986e74756eb0454df8ead490971c8e.squirrel@webmail.nathanpeters.com> > On 05/14/2015 04:58 AM, nathan at nathanpeters.com wrote: >> I have tried to setup synchronization between a FreeIPA domain and an AD >> domain. The certificates are in the right place. >> >> [root at ipadc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=sync >> user,cn=Users,dc=datacenter,dc=addomain,dc=net" --bindpw secretpassword >> --passsync secretpassword --cacert >> /etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net >> -v >> Directory Manager password: >> >> Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to >> certificate database for ipadc1.ipadomain.net >> ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net >> The user for the Windows PassSync service is >> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >> Windows PassSync system account exists, not resetting password >> ipa: INFO: Added new sync agreement, waiting for it to become ready . . >> . >> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >> error: Connect error: start: 0: end: 0 >> ipa: INFO: Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> >> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >> error: >> Connect error] >> >> Failed to start replication >> >> >> This is the system journal while the failure is happening >> >> May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory >> Server IPADOMAIN-NET.... >> May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >> Can't >> contact LDAP server: ldap_sync_poll() failed >> May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl >> will reconnect in 60 seconds >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa >> : >> ERROR syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP >> server"}) >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback >> (most recent call last): >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/libexec/ipa/ipa-dnskeysyncd", line 106, in >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while >> ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 349, in >> syncrepl_poll >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: >> add_intermediates=1, add_ctrls=1, all = 0 >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in >> result4 >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result >> = >> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in >> _ldap_call >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result = >> func(*args,**kwargs) >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN: >> {'desc': "Can't contact LDAP server"} >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: >> ipa-dnskeysyncd.service: >> main process exited, code=exited, status=1/FAILURE >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit >> ipa-dnskeysyncd.service entered failed state. >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory >> Server IPADOMAIN-NET.. >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory >> Server IPADOMAIN-NET.... >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory >> Server IPADOMAIN-NET.. >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, >> max: TLS1.2 >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: Configured NSS Ciphers >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: connection to >> the >> LDAP server was lost >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 1 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 2 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 2 >> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 3 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: successfully >> reconnected to LDAP server >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP instance >> 'ipa' is being synchronized, please ignore message 'all zones loaded' >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >> Can't >> contact LDAP server: while modifying(replace) entry >> 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: retrying LDAP >> operation (modifying(replace)) on entry >> 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >> Can't >> contact LDAP server: connection error >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service >> holdoff time over, scheduling restart. >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Stopping IPA key >> daemon... >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Starting IPA key >> daemon... >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Started IPA key daemon. >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 1 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 2 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 2 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 3 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: successfully >> reconnected to LDAP server >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone >> 19.21.10.in-addr.arpa/IN: loaded serial 1431571902 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone >> ipadomain.net/IN: loaded serial 1431571901 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: 2 master zones >> from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 0 failed >> to >> load) >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 1 >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 2 >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 2 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 3 >> May 14 02:51:43 ipadc1.ipadomain.net ipa-dnskeysyncd[3318]: ipa >> : >> INFO LDAP bind... > > CCing Alexander. I wonder if it is related to > > https://bugzilla.redhat.com/show_bug.cgi?id=1215010 > > If your AD has the MS update mentioned in the bug and has a CA cert with > SHA-512 signing, then may be hitting this bug. > Although the AD DC is Server 2012R2, it does not have KB2992611 installed. I also checked the certificate and it is SHA1RSA not SHA512. I also ensured that the windows firewall is disabled. From lslebodn at redhat.com Thu May 14 20:41:29 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 14 May 2015 22:41:29 +0200 Subject: [Freeipa-users] trusted user groups In-Reply-To: <19fca29e79eb4635acddd4a9f3be20d3@TCCCORPEXCH02.TCC.local> References: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> <20150514154532.GK2709@hendrix> <19fca29e79eb4635acddd4a9f3be20d3@TCCCORPEXCH02.TCC.local> Message-ID: <20150514204129.GB11220@mail.corp.redhat.com> On (14/05/15 15:53), Andy Thompson wrote: >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Jakub Hrozek >> Sent: Thursday, May 14, 2015 11:46 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] trusted user groups >> >> On Thu, May 14, 2015 at 03:33:28PM +0000, Andy Thompson wrote: >> > I've noticed that trusted users supplementary ad groups don't show up >> until after the users login to the box at least once. >> >> That's expected with the versions you're running. Prior to 6.7, we could only >> read the trusted users' group membership from the PAC blob attached to >> the Kerberos ticket. >> >> >> > Is there a chance that information will be dropped again at any point going >> forward? >> >> No, otherwise it's a bug. >> >> > >> > The reason I ask is that on our sftp boxes we chroot users based on >> > group membership. I set that up as an external group in freeIPA and >> > the first time the user logs in to the sftp box, they are dropped in >> > their normal home directory as opposed to the chroot environment. If >> > there is a chance the group membership will not show up correctly >> > again in the future, I'm inclined to change the chroot stanzas to match on >> user as opposed to group. >> > >> > Is that by design? >> >> If you can't see the correct group memberships after a login, then something >> is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many >> fixes and enhancements in this area..is there a chance you could try out 6.7 >> beta or some custom packages? >> > >Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. > Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ LS From wgraboyes at cenic.org Thu May 14 23:09:46 2015 From: wgraboyes at cenic.org (William Graboyes) Date: Thu, 14 May 2015 16:09:46 -0700 Subject: [Freeipa-users] External Self Help Suggestions. In-Reply-To: <5553EC45.9060101@redhat.com> References: <5553E0DE.2010502@cenic.org> <5553E5A3.1080701@redhat.com> <5553E9E8.4060901@cenic.org> <5553EC45.9060101@redhat.com> Message-ID: <55552B3A.1040004@cenic.org> Hi Dmitri, No I am sticking to the 90 day, gotta start the change in the right direction somewhere :). So I am trying out LBT Self service password, and I am wondering if there is documentation anywhere on how to create a service style account that has the ability to change a password without forcing the user to reset thier password on next login. This would be for if a user forgets thier password and uses a mail token style auth. Thanks, Bill On 5/13/15 5:28 PM, Dmitri Pal wrote: > On 05/13/2015 08:18 PM, William Graboyes wrote: > > Hi Dmitri, > > > > That is quite a bucket of stuff... On the CA-less install, basically I > > don't want to have my users change their passwords again (they are > > complaining about the every 90 day password rotation policy), we do > > not have an internal CA, most of our "desk top support" folks don't > > even have access to all of the desktops in the place. Like I said > > this place is mind bending when it comes to standard practices. The > > CA-less would be good if it were possible to make that change in > > place, or make the change by standing up a new IPA server and having > > the ability to import the current data set. > > > > I was looking at PWM, and may try to get that implemented. > > Another option is to reset expiration time in the user entry and set it > some date close to 2038 which is the end of the 32-bit time. > If the problem is 90 day policy you can just change the policy to be > 5000 days and then next time people change password they would not be > bother for another 5000 days or so (make sure it does not roll over). > For people that already have 90 days in their entry you can run a script > once and move the date into the future. > > People have done it for the same reason and in the same way. > > > > > Thanks, > > Bill > > > > On 5/13/15 5:00 PM, Dmitri Pal wrote: > >> On 05/13/2015 07:40 PM, William Graboyes wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA512 > >>> > >>> Hi List, > >>> > >>> I am trying to figure out a method of allowing users who do not have > >>> shell access to change their own passwords. The GUI that comes with > >>> FreeIPA is out of the question due to the untrusted CA (yes I know we > >>> are a strange shop, there is nothing I can do about it, and you would > >>> want to gouge you eyes out if I told you the full story) becoming a > >>> "Bad habit forming" method of changing one's password. I have been > >>> looking around for about a week now, and am somewhat lost and > >>> perplexed. The old documentation for FreeIPA basically says that it is > >>> not a good idea to manipulate the password directly in LDAP (and even > >>> then finding what hash is being used has been next to impossible). > >>> > >>> So the question is this, does anyone know of any tools out there that > >>> can happily, or even with some modification, allow me to set up a > >>> trusted external ssl site that allows users to change their passwords. > >> There is no external password reset self service in IPA yet. We will be > >> starting to look into this effort during summer. > >> Take a look at the bucket of tickets in the "FreeIPA Community Portal > >> Release" here https://fedorahosted.org/freeipa/report/3. > >> > >> What prevents you from making IPA trusted? You can chain IPA to your CA > >> or use it CA-less with certs from your own CA. > >> Then UI would be an option I assume. > >> > >> Other option is https://code.google.com/p/pwm/ > >> > >>> Thanks, > >>> Bill > >>> -----BEGIN PGP SIGNATURE----- > >>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > >>> Comment: GPGTools - https://gpgtools.org > >>> > >>> iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 > >>> MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc > >>> bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV > >>> UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU > >>> NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm > >>> zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW > >>> /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK > >>> ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml > >>> 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ > >>> 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 > >>> ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX > >>> kzyr3+tqYdDbgibcYyhd > >>> =5KCr > >>> -----END PGP SIGNATURE----- > >>> > >> > > From nathan at nathanpeters.com Thu May 14 23:43:07 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 14 May 2015 16:43:07 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <55547FF4.3060100@redhat.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> Message-ID: > On 05/14/2015 04:58 AM, nathan at nathanpeters.com wrote: >> I have tried to setup synchronization between a FreeIPA domain and an AD >> domain. The certificates are in the right place. >> >> [root at ipadc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=sync >> user,cn=Users,dc=datacenter,dc=addomain,dc=net" --bindpw secretpassword >> --passsync secretpassword --cacert >> /etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net >> -v >> Directory Manager password: >> >> Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to >> certificate database for ipadc1.ipadomain.net >> ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net >> The user for the Windows PassSync service is >> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >> Windows PassSync system account exists, not resetting password >> ipa: INFO: Added new sync agreement, waiting for it to become ready . . >> . >> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >> error: Connect error: start: 0: end: 0 >> ipa: INFO: Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> >> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >> error: >> Connect error] >> >> Failed to start replication >> >> >> This is the system journal while the failure is happening >> >> May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory >> Server IPADOMAIN-NET.... >> May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >> Can't >> contact LDAP server: ldap_sync_poll() failed >> May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl >> will reconnect in 60 seconds >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa >> : >> ERROR syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP >> server"}) >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback >> (most recent call last): >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/libexec/ipa/ipa-dnskeysyncd", line 106, in >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while >> ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 349, in >> syncrepl_poll >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: >> add_intermediates=1, add_ctrls=1, all = 0 >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in >> result4 >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result >> = >> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in >> _ldap_call >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result = >> func(*args,**kwargs) >> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN: >> {'desc': "Can't contact LDAP server"} >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: >> ipa-dnskeysyncd.service: >> main process exited, code=exited, status=1/FAILURE >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit >> ipa-dnskeysyncd.service entered failed state. >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory >> Server IPADOMAIN-NET.. >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory >> Server IPADOMAIN-NET.... >> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory >> Server IPADOMAIN-NET.. >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, >> max: TLS1.2 >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: Configured NSS Ciphers >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: >> enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled >> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >> [14/May/2015:02:50:41 >> +0000] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: connection to >> the >> LDAP server was lost >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 1 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 2 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 2 >> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 3 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: successfully >> reconnected to LDAP server >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP instance >> 'ipa' is being synchronized, please ignore message 'all zones loaded' >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >> Can't >> contact LDAP server: while modifying(replace) entry >> 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: retrying LDAP >> operation (modifying(replace)) on entry >> 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >> Can't >> contact LDAP server: connection error >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service >> holdoff time over, scheduling restart. >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Stopping IPA key >> daemon... >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Starting IPA key >> daemon... >> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Started IPA key daemon. >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 1 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 1 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 2 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >> step 2 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 3 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: successfully >> reconnected to LDAP server >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone >> 19.21.10.in-addr.arpa/IN: loaded serial 1431571902 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone >> ipadomain.net/IN: loaded serial 1431571901 >> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: 2 master zones >> from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 0 failed >> to >> load) >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 1 >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 2 >> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 2 >> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >> 3 >> May 14 02:51:43 ipadc1.ipadomain.net ipa-dnskeysyncd[3318]: ipa >> : >> INFO LDAP bind... > > CCing Alexander. I wonder if it is related to > > https://bugzilla.redhat.com/show_bug.cgi?id=1215010 > > If your AD has the MS update mentioned in the bug and has a CA cert with > SHA-512 signing, then may be hitting this bug. > I have done some more testing and created a 2008r2 DC to try to setup synchronization with. This also failed with the same types of error messages. I find it really strange that I get errors looking up DNS zones in my logs when this is happening. They appear to be looking for the root zone above my AD zone. [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw supersecretpassword --passsync supersecretpassword --cacert /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/addc2-test.cer to certificate database for ipadc1.ipadomain.net ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net Windows PassSync system account exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication [root at ipadc1 cacerts]# May 14 23:35:18 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory Server IPADOMAIN-NET.... May 14 23:35:19 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory Server IPADOMAIN-NET.. May 14 23:35:19 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory Server IPADOMAIN-NET.... May 14 23:35:19 ipadc1.ipadomain.net systemd[1]: Started 389 Directory Server IPADOMAIN-NET.. May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: Configured NSS Ciphers May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 +0000] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: connection to the LDAP server was lost May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 23:35:56 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 23:35:56 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 May 14 23:35:56 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: successfully reconnected to LDAP server May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP instance 'ipa' is being synchronized, please ignore message 'all zones loaded' May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't contact LDAP server: while modifying(replace) entry 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: retrying LDAP operation (modifying(replace)) on entry 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't contact LDAP server: connection error May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: successfully reconnected to LDAP server May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling restart. May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: Stopping IPA key daemon... May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: Starting IPA key daemon... May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: Started IPA key daemon. May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: zone 19.21.10.in-addr.arpa/IN: loaded serial 1431646557 May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: zone ipadomain.net/IN: loaded serial 1431646557 May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: 2 master zones from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 0 failed to load) May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 2 May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 May 14 23:35:58 ipadc1.ipadomain.net ipa-dnskeysyncd[4988]: ipa : INFO LDAP bind... May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 1 May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 1 May 14 23:35:58 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 1 May 14 23:35:58 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 2 May 14 23:35:58 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 May 14 23:35:58 ipadc1.ipadomain.net ipa-dnskeysyncd[4988]: ipa : INFO Commencing sync process May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: validating @0x7fbd5d6dcdf0: . NS: got insecure response; parent indicates it should be secure May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: validating @0x7fbd5c6af300: . DNSKEY: got insecure response; parent indicates it should be secure May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (insecurity proof failed) resolving './NS/IN': 10.21.19.41#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (insecurity proof failed) resolving './DNSKEY/IN': 10.21.19.41#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network unreachable) resolving './NS/IN': 2001:503:c27::2:30#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network unreachable) resolving './DNSKEY/IN': 2001:503:c27::2:30#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network unreachable) resolving 'mycompany.net/DS/IN': 2001:500:2d::d#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network unreachable) resolving 'mycompany.net/DS/IN': 2001:500:1::803f:235#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network unreachable) resolving 'mycompany.net/DS/IN': 2001:dc3::35#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network unreachable) resolving 'mycompany.net/DS/IN': 2001:503:231d::2:30#53 May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: validating @0x7fbd5d6dc160: net DNSKEY: got insecure response; parent indicates it should be secure May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (insecurity proof failed) resolving 'net/DNSKEY/IN': 10.21.19.41#53 From rmeggins at redhat.com Fri May 15 00:06:41 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 14 May 2015 18:06:41 -0600 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> Message-ID: <55553891.2000507@redhat.com> On 05/14/2015 05:43 PM, nathan at nathanpeters.com wrote: >> On 05/14/2015 04:58 AM, nathan at nathanpeters.com wrote: >>> I have tried to setup synchronization between a FreeIPA domain and an AD >>> domain. The certificates are in the right place. >>> >>> [root at ipadc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=sync >>> user,cn=Users,dc=datacenter,dc=addomain,dc=net" --bindpw secretpassword >>> --passsync secretpassword --cacert >>> /etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net >>> -v >>> Directory Manager password: >>> >>> Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to >>> certificate database for ipadc1.ipadomain.net >>> ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net >>> The user for the Windows PassSync service is >>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>> Windows PassSync system account exists, not resetting password >>> ipa: INFO: Added new sync agreement, waiting for it to become ready . . >>> . >>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>> error: Connect error: start: 0: end: 0 >>> ipa: INFO: Agreement is ready, starting replication . . . >>> Starting replication, please wait until this has completed. >>> >>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>> error: >>> Connect error] >>> >>> Failed to start replication >>> >>> >>> This is the system journal while the failure is happening >>> >>> May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory >>> Server IPADOMAIN-NET.... >>> May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >>> Can't >>> contact LDAP server: ldap_sync_poll() failed >>> May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl >>> will reconnect in 60 seconds >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa >>> : >>> ERROR syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP >>> server"}) >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback >>> (most recent call last): >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >>> "/usr/libexec/ipa/ipa-dnskeysyncd", line 106, in >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while >>> ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >>> "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 349, in >>> syncrepl_poll >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: >>> add_intermediates=1, add_ctrls=1, all = 0 >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in >>> result4 >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result >>> = >>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File >>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in >>> _ldap_call >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result = >>> func(*args,**kwargs) >>> May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN: >>> {'desc': "Can't contact LDAP server"} >>> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: >>> ipa-dnskeysyncd.service: >>> main process exited, code=exited, status=1/FAILURE >>> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit >>> ipa-dnskeysyncd.service entered failed state. >>> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory >>> Server IPADOMAIN-NET.. >>> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory >>> Server IPADOMAIN-NET.... >>> May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory >>> Server IPADOMAIN-NET.. >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, >>> max: TLS1.2 >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: Configured NSS Ciphers >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: >>> enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled >>> May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: >>> [14/May/2015:02:50:41 >>> +0000] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: connection to >>> the >>> LDAP server was lost >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 1 >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 1 >>> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 1 >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 1 >>> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 2 >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 2 >>> May 14 02:51:41 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 3 >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: successfully >>> reconnected to LDAP server >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP instance >>> 'ipa' is being synchronized, please ignore message 'all zones loaded' >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >>> Can't >>> contact LDAP server: while modifying(replace) entry >>> 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: retrying LDAP >>> operation (modifying(replace)) on entry >>> 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: >>> Can't >>> contact LDAP server: connection error >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 1 >>> May 14 02:51:41 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 1 >>> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service >>> holdoff time over, scheduling restart. >>> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Stopping IPA key >>> daemon... >>> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Starting IPA key >>> daemon... >>> May 14 02:51:41 ipadc1.ipadomain.net systemd[1]: Started IPA key daemon. >>> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 1 >>> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 1 >>> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 2 >>> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client >>> step 2 >>> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 3 >>> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: successfully >>> reconnected to LDAP server >>> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone >>> 19.21.10.in-addr.arpa/IN: loaded serial 1431571902 >>> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: zone >>> ipadomain.net/IN: loaded serial 1431571901 >>> May 14 02:51:42 ipadc1.ipadomain.net named-pkcs11[5594]: 2 master zones >>> from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 0 failed >>> to >>> load) >>> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >>> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >>> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 1 >>> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 >>> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 2 >>> May 14 02:51:42 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 2 >>> May 14 02:51:42 ipadc1.ipadomain.net ns-slapd[3269]: GSSAPI server step >>> 3 >>> May 14 02:51:43 ipadc1.ipadomain.net ipa-dnskeysyncd[3318]: ipa >>> : >>> INFO LDAP bind... >> CCing Alexander. I wonder if it is related to >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1215010 >> >> If your AD has the MS update mentioned in the bug and has a CA cert with >> SHA-512 signing, then may be hitting this bug. >> > I have done some more testing and created a 2008r2 DC to try to setup > synchronization with. This also failed with the same types of error > messages. I find it really strange that I get errors looking up DNS zones > in my logs when this is happening. They appear to be looking for the root > zone above my AD zone. > > [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn > "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw > supersecretpassword --passsync supersecretpassword --cacert > /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v > Directory Manager password: > > Added CA certificate /etc/openldap/cacerts/addc2-test.cer to certificate > database for ipadc1.ipadomain.net > ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net > Windows PassSync system account exists, not resetting password > ipa: INFO: Added new sync agreement, waiting for it to become ready . . . > ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP > error: Connect error: start: 0: end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > > [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP error: > Connect error] Have you tried using ldapsearch to verify the connection? # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*" and/or # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*" > > Failed to start replication > [root at ipadc1 cacerts]# > > > May 14 23:35:18 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory > Server IPADOMAIN-NET.... > May 14 23:35:19 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory > Server IPADOMAIN-NET.. > May 14 23:35:19 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory > Server IPADOMAIN-NET.... > May 14 23:35:19 ipadc1.ipadomain.net systemd[1]: Started 389 Directory > Server IPADOMAIN-NET.. > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, > max: TLS1.2 > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: Configured NSS Ciphers > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: > enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: > enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > May 14 23:35:19 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:19 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > May 14 23:35:20 ipadc1.ipadomain.net ns-slapd[4938]: [14/May/2015:23:35:20 > +0000] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled > May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: connection to the > LDAP server was lost > May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 23:35:56 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 > May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 23:35:56 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 > May 14 23:35:56 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 > May 14 23:35:56 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: successfully > reconnected to LDAP server > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP instance > 'ipa' is being synchronized, please ignore message 'all zones loaded' > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't > contact LDAP server: while modifying(replace) entry > 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: retrying LDAP > operation (modifying(replace)) on entry > 'idnsname=ipadomain.net.,cn=dns,dc=ipadomain,dc=net' > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't > contact LDAP server: connection error > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 1 > May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: GSSAPI client step 2 > May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: successfully > reconnected to LDAP server > May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service > holdoff time over, scheduling restart. > May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: Stopping IPA key daemon... > May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: Starting IPA key daemon... > May 14 23:35:57 ipadc1.ipadomain.net systemd[1]: Started IPA key daemon. > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: zone > 19.21.10.in-addr.arpa/IN: loaded serial 1431646557 > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: zone > ipadomain.net/IN: loaded serial 1431646557 > May 14 23:35:57 ipadc1.ipadomain.net named-pkcs11[5594]: 2 master zones > from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 0 failed to > load) > May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 > May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 > May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 > May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 1 > May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 > May 14 23:35:57 ipadc1.ipadomain.net sssd_be[5782]: GSSAPI client step 2 > May 14 23:35:57 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 > May 14 23:35:58 ipadc1.ipadomain.net ipa-dnskeysyncd[4988]: ipa : > INFO LDAP bind... > May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 1 > May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 1 > May 14 23:35:58 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 1 > May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 1 > May 14 23:35:58 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 2 > May 14 23:35:58 ipadc1.ipadomain.net python[4988]: GSSAPI client step 2 > May 14 23:35:58 ipadc1.ipadomain.net ns-slapd[4939]: GSSAPI server step 3 > May 14 23:35:58 ipadc1.ipadomain.net ipa-dnskeysyncd[4988]: ipa : > INFO Commencing sync process > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: validating > @0x7fbd5d6dcdf0: . NS: got insecure response; parent indicates it should > be secure > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: validating > @0x7fbd5c6af300: . DNSKEY: got insecure response; parent indicates it > should be secure > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (insecurity > proof failed) resolving './NS/IN': 10.21.19.41#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (insecurity > proof failed) resolving './DNSKEY/IN': 10.21.19.41#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network > unreachable) resolving './NS/IN': 2001:503:c27::2:30#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network > unreachable) resolving './DNSKEY/IN': 2001:503:c27::2:30#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network > unreachable) resolving 'mycompany.net/DS/IN': 2001:500:2d::d#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network > unreachable) resolving 'mycompany.net/DS/IN': 2001:500:1::803f:235#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network > unreachable) resolving 'mycompany.net/DS/IN': 2001:dc3::35#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (network > unreachable) resolving 'mycompany.net/DS/IN': 2001:503:231d::2:30#53 > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: validating > @0x7fbd5d6dc160: net DNSKEY: got insecure response; parent indicates it > should be secure > May 14 23:36:08 ipadc1.ipadomain.net named-pkcs11[5594]: error (insecurity > proof failed) resolving 'net/DNSKEY/IN': 10.21.19.41#53 > > From nathan at nathanpeters.com Fri May 15 05:33:22 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 14 May 2015 22:33:22 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <55553891.2000507@redhat.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> Message-ID: <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> >> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >> supersecretpassword --passsync supersecretpassword --cacert >> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >> Directory Manager password: >> >> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to certificate >> database for ipadc1.ipadomain.net >> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >> The user for the Windows PassSync service is >> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >> Windows PassSync system account exists, not resetting password >> ipa: INFO: Added new sync agreement, waiting for it to become ready . . >> . >> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >> error: Connect error: start: 0: end: 0 >> ipa: INFO: Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> >> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >> error: >> Connect error] > > Have you tried using ldapsearch to verify the connection? > > # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h > addc2.test.mycompany.net -D "cn=ad > sync,cn=Users,dc=test,dc=mycompany,dc=net" -w > "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" > "objectclass=*" > > and/or > > # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL > -ZZ -h addc2.test.mycompany.net -D "cn=ad > sync,cn=Users,dc=test,dc=mycompany,dc=net" -w > "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" > "objectclass=*" > Both commands give the same successful result. I don't think it's a problem with the credentials because I was able to generate different error messages during the attempted sync setup if I intentionally gave a bad password or username. Here is what happens when I run the above commands : [root at ipadc1 cacerts]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*" dn: cn=Users,dc=test,dc=mycompany,dc=net objectClass: top objectClass: container cn: Users description: Default container for upgraded user accounts distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net instanceType: 4 whenCreated: 20150515024307.0Z whenChanged: 20150515024307.0Z uSNCreated: 5696 uSNChanged: 5696 showInAdvancedViewOnly: FALSE name: Users objectGUID:: V9KaoufynkWbJpSo2PjxiA== systemFlags: -1946157056 objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net isCriticalSystemObject: TRUE dSCorePropagationData: 20150515025646.0Z dSCorePropagationData: 16010101000001.0Z [root at ipadc1 cacerts]# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*" dn: cn=Users,dc=test,dc=mycompany,dc=net objectClass: top objectClass: container cn: Users description: Default container for upgraded user accounts distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net instanceType: 4 whenCreated: 20150515024307.0Z whenChanged: 20150515024307.0Z uSNCreated: 5696 uSNChanged: 5696 showInAdvancedViewOnly: FALSE name: Users objectGUID:: V9KaoufynkWbJpSo2PjxiA== systemFlags: -1946157056 objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net isCriticalSystemObject: TRUE dSCorePropagationData: 20150515025646.0Z dSCorePropagationData: 16010101000001.0Z From jcholast at redhat.com Fri May 15 05:59:27 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 15 May 2015 07:59:27 +0200 Subject: [Freeipa-users] using pathlen:0 for freeipa's CA certificate? In-Reply-To: <554882BE.60806@redhat.com> References: <554755A5.3080109@aixigo.de> <554882BE.60806@redhat.com> Message-ID: <55558B3F.8020006@redhat.com> Hi, Dne 5.5.2015 v 10:43 Martin Kosek napsal(a): > On 05/04/2015 01:19 PM, Harald Dunkel wrote: >> Hi folks, >> >> Instead of a self-signed certificate I would like to use an external >> CA to sign freeipa's CSR ("ipa-server-install --external-ca"). >> Question: >> >> Is pathlen:0, e.g. >> >> basicConstraints=critical,CA:TRUE, pathlen:0 >> >> sufficient for freeipa's CA certificate? > > I would say it should be sufficient for FreeIPA CA for now, given it does not > allow subordinate CAs. However, I am still CCing Fraser and Honza for > reference, in case there would be some limitation in Dogtag/our CA certificate > that would limit use of the basicConstraints extension. I'm not aware of any. > > Note that this basiConstrain would surely prevent you from using the upcoming > feature > > http://www.freeipa.org/page/V4/Sub-CAs > > but this is OK with you, I assume. BTW, Fraser, we should record a task to > properly watch for the pathlen limitation and have nice error messages around > it when admin attempts to use Sub-CAs. > > Final note, there is a related ticket: > https://fedorahosted.org/freeipa/ticket/3466 > > Martin > Honza -- Jan Cholasta From ftweedal at redhat.com Fri May 15 07:22:37 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 15 May 2015 17:22:37 +1000 Subject: [Freeipa-users] using pathlen:0 for freeipa's CA certificate? In-Reply-To: <55558B3F.8020006@redhat.com> References: <554755A5.3080109@aixigo.de> <554882BE.60806@redhat.com> <55558B3F.8020006@redhat.com> Message-ID: <20150515072237.GO12806@dhcp-40-8.bne.redhat.com> On Fri, May 15, 2015 at 07:59:27AM +0200, Jan Cholasta wrote: > Hi, > > Dne 5.5.2015 v 10:43 Martin Kosek napsal(a): > >On 05/04/2015 01:19 PM, Harald Dunkel wrote: > >>Hi folks, > >> > >>Instead of a self-signed certificate I would like to use an external > >>CA to sign freeipa's CSR ("ipa-server-install --external-ca"). > >>Question: > >> > >>Is pathlen:0, e.g. > >> > >> basicConstraints=critical,CA:TRUE, pathlen:0 > >> > >>sufficient for freeipa's CA certificate? > > > >I would say it should be sufficient for FreeIPA CA for now, given it does not > >allow subordinate CAs. However, I am still CCing Fraser and Honza for > >reference, in case there would be some limitation in Dogtag/our CA certificate > >that would limit use of the basicConstraints extension. > > I'm not aware of any. > Yes, currently it is sufficient. When FreeIPA has sub-CAs capability, a pathLenConstraint of zero will prevent the creation of valid sub-CAs. Martin, Jan, this is a situation I had not considered. I propose that we should detect pathLenConstraint and error out if sub-CAs creation is attempted at a depth that cannot be valid. If you agree I will add to design document. Cheers, Fraser > > > >Note that this basiConstrain would surely prevent you from using the upcoming > >feature > > > >http://www.freeipa.org/page/V4/Sub-CAs > > > >but this is OK with you, I assume. BTW, Fraser, we should record a task to > >properly watch for the pathlen limitation and have nice error messages around > >it when admin attempts to use Sub-CAs. > > > >Final note, there is a related ticket: > >https://fedorahosted.org/freeipa/ticket/3466 > > > >Martin > > > > Honza > > -- > Jan Cholasta From mkosek at redhat.com Fri May 15 07:31:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 May 2015 09:31:02 +0200 Subject: [Freeipa-users] using pathlen:0 for freeipa's CA certificate? In-Reply-To: <20150515072237.GO12806@dhcp-40-8.bne.redhat.com> References: <554755A5.3080109@aixigo.de> <554882BE.60806@redhat.com> <55558B3F.8020006@redhat.com> <20150515072237.GO12806@dhcp-40-8.bne.redhat.com> Message-ID: <5555A0B6.5090309@redhat.com> On 05/15/2015 09:22 AM, Fraser Tweedale wrote: > On Fri, May 15, 2015 at 07:59:27AM +0200, Jan Cholasta wrote: >> Hi, >> >> Dne 5.5.2015 v 10:43 Martin Kosek napsal(a): >>> On 05/04/2015 01:19 PM, Harald Dunkel wrote: >>>> Hi folks, >>>> >>>> Instead of a self-signed certificate I would like to use an external >>>> CA to sign freeipa's CSR ("ipa-server-install --external-ca"). >>>> Question: >>>> >>>> Is pathlen:0, e.g. >>>> >>>> basicConstraints=critical,CA:TRUE, pathlen:0 >>>> >>>> sufficient for freeipa's CA certificate? >>> >>> I would say it should be sufficient for FreeIPA CA for now, given it does not >>> allow subordinate CAs. However, I am still CCing Fraser and Honza for >>> reference, in case there would be some limitation in Dogtag/our CA certificate >>> that would limit use of the basicConstraints extension. >> >> I'm not aware of any. >> > Yes, currently it is sufficient. When FreeIPA has sub-CAs > capability, a pathLenConstraint of zero will prevent the creation of > valid sub-CAs. > > Martin, Jan, this is a situation I had not considered. I propose > that we should detect pathLenConstraint and error out if sub-CAs > creation is attempted at a depth that cannot be valid. If you agree > I will add to design document. I agree. Please also add a ticket for this part. The check can be IMO added to FreeIPA 4.2.1, it is not critical for 4.2 GA. >>> Note that this basiConstrain would surely prevent you from using the upcoming >>> feature >>> >>> http://www.freeipa.org/page/V4/Sub-CAs >>> >>> but this is OK with you, I assume. BTW, Fraser, we should record a task to >>> properly watch for the pathlen limitation and have nice error messages around >>> it when admin attempts to use Sub-CAs. >>> >>> Final note, there is a related ticket: >>> https://fedorahosted.org/freeipa/ticket/3466 >>> >>> Martin >>> >> >> Honza >> >> -- >> Jan Cholasta From mkosek at redhat.com Fri May 15 07:35:50 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 May 2015 09:35:50 +0200 Subject: [Freeipa-users] Old FreeIPA upstream guides removed (WAS: Re: Web UI: Migrated Admins missing action buttons) In-Reply-To: <1430144125.13607.74.camel@willson.usersys.redhat.com> References: <553B1F7B.7090502@redhat.com> <553B2055.1090000@redhat.com> <1559142229.7534860.1430029433988.JavaMail.zimbra@redhat.com> <553E14C1.5060709@redhat.com> <1430144125.13607.74.camel@willson.usersys.redhat.com> Message-ID: <5555A1D6.1090602@redhat.com> On 04/27/2015 04:15 PM, Simo Sorce wrote: > On Mon, 2015-04-27 at 12:51 +0200, Martin Kosek wrote: >> On 04/26/2015 08:23 AM, Alexander Bokovoy wrote: >>> >>> >>> ----- Original Message ----- >>>> Hi Rob and Dimitri >>>> >>>> Migrating via Replica is the obvious way that I would have gone, had the >>>> FreeIPA /RedHat documentation not suggested the replicas must have the same >>>> version. >>>> >>>> I think the link that put me off from replicating was: >>>> >>>> http://www.freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Multi_Master_Replication-Creating_the_Replica_Information_File.html >>>> >>>> Looking at the link more closely I now see this applies to version >>>> 1.2 ....., but from the page itself that was not obvious. it would be great >>>> if the version to which the IPA documentation applies was more obvious.... >>>> I am sure I am not the only user who enters the documentation via a search >>>> engine. >>> We really need to remove this version 1.x documentation, it is giving too much confusion. >> >> I agree, this was the last straw. I just did an update to FreeIPA.org mediawiki >> and (besides upgrading to new Mediawiki) replaced the deprecated FreeIPA 1.2.1 >> and 2.0.0 guides with a redirection to: >> >> http://www.freeipa.org/page/Upstream_User_Guide >> >> which contains the reasoning and updated list of deprecated guides and a link >> to the current documentations. >> >> HTH. If anyone needs the old guides, I can zip them and add as a download to >> Documentation section. > > Yes please, leave the guides available for download. People may need > them for historical reasons. I agree. I finally found a time slot to zip those and make them available for historical reasons on FreeIPA.org. So, here they are: http://www.freeipa.org/page/Upstream_User_Guide#Deprecated_Upstream_Guides They are also linked from "Old Resources" section of Documentation page. Enjoy! Martin From mkosek at redhat.com Fri May 15 07:55:54 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 May 2015 09:55:54 +0200 Subject: [Freeipa-users] Configuration of CA failed In-Reply-To: <555480DA.1070304@redhat.com> References: <0A2A5163954B3342B82944846B7FD995149006@lexus.ingenia.local> <555480DA.1070304@redhat.com> Message-ID: <5555A68A.5020404@redhat.com> On 05/14/2015 01:02 PM, Martin Kosek wrote: > On 05/14/2015 11:58 AM, Remigio Moncayo Serrano wrote: >> Hello, >> >> I've been put in charge of implementing a solution that uses LDAP and kerberos authentication. At first thought I should use openLDAP and Kerberos but found freeIPA and looks really cool, however, when trying to install I keep getting this error about configuration of CA: >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> [2/4]: writing configuration >> [3/4]: configuring ntpd to start on boot >> [4/4]: starting ntpd >> Done configuring NTP daemon (ntpd). >> Configuring directory server for the CA (pkids): Estimated time 30 seconds >> [1/3]: creating directory server user >> [2/3]: creating directory server instance >> [3/3]: restarting directory server >> ipa : CRITICAL Failed to restart the directory server. See the installation log for details. >> Done configuring directory server for the CA (pkids). >> Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >> [1/20]: creating certificate server user >> [2/20]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipatest.ingenia.local -cs_port 9445 -client_certdb_dir /tmp/tmp-ARezzO -client_certdb_pwd XXXXXXXX -preop_pin f0dLhx9bLX5qWHYx50h6 -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host ipatest.ingenia.local -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INGENIA.LOCAL -ca_server_cert_subject_name CN=ipatest.ingenia.local,O=INGENIA.! L! > OCAL -ca_a > udit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL -ca_sign_cert_subject_name CN=Certificate Authority,O=INGENIA.LOCAL -external false -clone false' returned non-zero exit status 255 >> Configuration of CA failed >> >> I'm including two install logs, one with dns-setup and the other without it. Don't really know what I'm doing wrong, thought maybe I should allow connections to certain ports in ip tables or something but have no clue really and I'm quite new to this, help please.. >> >> Regards, >> >> Remigio > > Hello, > > What platform are you using (Fedora? CentOS? RHEL?) and what version of FreeIPA > are you using? We still have not received answer for that part, though it is obvious the platform will be something RHEL-6.x derived. > > Also, I following error in the log > java.net.ConnectException: Connection refused > So it seems some port is occupied. Is your port 8443 occupied? Maybe by running > httpd daemon before the installation? > > Martin > Looking at the dirsrv log that Remigio sent me privately, it does not look that 8443 is to blame. It is, however, really strange that ipaserver-install.log reports that DS restart fails with following error, even though DS says it is listening on that port: 2015-05-14T09:28:49Z CRITICAL Failed to restart the directory server. See the installation log for details. Could it be maybe a SELinux based problem? You can check for AVCs with # ausearch -m avc -ts today Final suggestion: this does not solve the root cause, but I would really suggest doing the installation on RHEL/CentOS 7.1 as it contains FreeIPA 4.1 which is much better than the old FreeIPA 3.0 present in RHEL-6.x. This is our general recommendation for new deployments anyway. Martin From jcholast at redhat.com Fri May 15 08:53:20 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 15 May 2015 10:53:20 +0200 Subject: [Freeipa-users] using pathlen:0 for freeipa's CA certificate? In-Reply-To: <5555A0B6.5090309@redhat.com> References: <554755A5.3080109@aixigo.de> <554882BE.60806@redhat.com> <55558B3F.8020006@redhat.com> <20150515072237.GO12806@dhcp-40-8.bne.redhat.com> <5555A0B6.5090309@redhat.com> Message-ID: <5555B400.4040202@redhat.com> Dne 15.5.2015 v 09:31 Martin Kosek napsal(a): > On 05/15/2015 09:22 AM, Fraser Tweedale wrote: >> On Fri, May 15, 2015 at 07:59:27AM +0200, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 5.5.2015 v 10:43 Martin Kosek napsal(a): >>>> On 05/04/2015 01:19 PM, Harald Dunkel wrote: >>>>> Hi folks, >>>>> >>>>> Instead of a self-signed certificate I would like to use an external >>>>> CA to sign freeipa's CSR ("ipa-server-install --external-ca"). >>>>> Question: >>>>> >>>>> Is pathlen:0, e.g. >>>>> >>>>> basicConstraints=critical,CA:TRUE, pathlen:0 >>>>> >>>>> sufficient for freeipa's CA certificate? >>>> >>>> I would say it should be sufficient for FreeIPA CA for now, given it >>>> does not >>>> allow subordinate CAs. However, I am still CCing Fraser and Honza for >>>> reference, in case there would be some limitation in Dogtag/our CA >>>> certificate >>>> that would limit use of the basicConstraints extension. >>> >>> I'm not aware of any. >>> >> Yes, currently it is sufficient. When FreeIPA has sub-CAs >> capability, a pathLenConstraint of zero will prevent the creation of >> valid sub-CAs. >> >> Martin, Jan, this is a situation I had not considered. I propose >> that we should detect pathLenConstraint and error out if sub-CAs >> creation is attempted at a depth that cannot be valid. If you agree >> I will add to design document. > > I agree. Please also add a ticket for this part. The check can be IMO > added to FreeIPA 4.2.1, it is not critical for 4.2 GA. I believe there would be other things to check as well, e.g. directoryName name constraints. > >>>> Note that this basiConstrain would surely prevent you from using the >>>> upcoming >>>> feature >>>> >>>> http://www.freeipa.org/page/V4/Sub-CAs >>>> >>>> but this is OK with you, I assume. BTW, Fraser, we should record a >>>> task to >>>> properly watch for the pathlen limitation and have nice error >>>> messages around >>>> it when admin attempts to use Sub-CAs. >>>> >>>> Final note, there is a related ticket: >>>> https://fedorahosted.org/freeipa/ticket/3466 >>>> >>>> Martin >>>> >>> >>> Honza >>> >>> -- >>> Jan Cholasta > -- Jan Cholasta From lkrispen at redhat.com Fri May 15 10:30:01 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 15 May 2015 12:30:01 +0200 Subject: [Freeipa-users] more replication issues In-Reply-To: <55537D10.4000208@gmail.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> <55537817.9010904@redhat.com> <55537D10.4000208@gmail.com> Message-ID: <5555CAA9.4070406@redhat.com> On 05/13/2015 06:34 PM, Janelle wrote: > On 5/13/15 9:13 AM, Rich Megginson wrote: >> On 05/13/2015 10:04 AM, Janelle wrote: >>> On 5/13/15 8:49 AM, Rich Megginson wrote: >>>> On 05/13/2015 09:40 AM, Janelle wrote: >>>>> Recently I started seeing these crop up across my servers: >>>>> >>>>> slapi_ldap_bind - Error: could not bind id [cn=Replication Manager >>>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication >>>>> mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) >>>> >>>> Does that entry exist? >>>> >>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>> base -b "cn=Replication Manager >>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >>>> >>>> Does the parent exist? >>>> >>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>> base -b "ou=csusers,cn=config" >>> >>> I am finding that there does seem to be a relation to the above >>> error and a possible CSN issue: >>> >>> Can't locate CSN 555131e5000200190000 in the changelog (DB >>> rc=-30988). If replication stops, the consumer may need to be >>> reinitialized. >>> >>> I guess what concerns me is what could be causing this. We don't do >>> a lot of changes all the time. >>> >>> And in answer to the question above - we seem to have last the >>> agreement somehow: >>> >>> No such object (32) >>> >> >> Is there a DEL operation in the access log for "cn=Replication >> Manager >> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? >> >> maybe something like >> >> # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication >> Manager" >> > nope -- none of the servers have it. your original message is very clear: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) this means that you have replication agreement wth SIMPLE auth which uses a nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config which does not exist on the target server of the agreement. Now you say it was never deleted, so it was probably never added, but used in the replication agreements. How do you manage and setup replication agreements ? From brian.topping at gmail.com Fri May 15 11:33:13 2015 From: brian.topping at gmail.com (Brian Topping) Date: Fri, 15 May 2015 18:33:13 +0700 Subject: [Freeipa-users] Securing IPA Redux Message-ID: <7B765750-7688-4643-B86E-27F40E8582E0@gmail.com> In the (apparently) first message to the list in 2014, https://www.redhat.com/archives/freeipa-users/2014-January/msg00000.html addressed questions about securing IPA and I don't see much other talk about it. Now that 4.x is prevalent, I wanted to bring it up again. I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted filesystems) to be a part of the domain. I believe this means that I need to expose Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult to force TLS (https://blog.routedlogic.net/?p=119 ) and maybe that's a bad idea under IPA for reasons I thought I'd ask here about. Last year's thread also referenced https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html and I thought I would check to see if that's still necessary under 4.x. Setting up the firewall to allow cloud networks in is always an option, but if I can get a secure IPA setup going, it would also allow road warriors to kinit and use their credentials for configured intranet sites without having to turn on the VPN (which can really slow things down from remote parts of the globe). Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ftweedal at redhat.com Fri May 15 11:35:28 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 15 May 2015 21:35:28 +1000 Subject: [Freeipa-users] using pathlen:0 for freeipa's CA certificate? In-Reply-To: <5555B400.4040202@redhat.com> References: <554755A5.3080109@aixigo.de> <554882BE.60806@redhat.com> <55558B3F.8020006@redhat.com> <20150515072237.GO12806@dhcp-40-8.bne.redhat.com> <5555A0B6.5090309@redhat.com> <5555B400.4040202@redhat.com> Message-ID: <20150515113528.GS12806@dhcp-40-8.bne.redhat.com> On Fri, May 15, 2015 at 10:53:20AM +0200, Jan Cholasta wrote: > Dne 15.5.2015 v 09:31 Martin Kosek napsal(a): > >On 05/15/2015 09:22 AM, Fraser Tweedale wrote: > >>On Fri, May 15, 2015 at 07:59:27AM +0200, Jan Cholasta wrote: > >>>Hi, > >>> > >>>Dne 5.5.2015 v 10:43 Martin Kosek napsal(a): > >>>>On 05/04/2015 01:19 PM, Harald Dunkel wrote: > >>>>>Hi folks, > >>>>> > >>>>>Instead of a self-signed certificate I would like to use an external > >>>>>CA to sign freeipa's CSR ("ipa-server-install --external-ca"). > >>>>>Question: > >>>>> > >>>>>Is pathlen:0, e.g. > >>>>> > >>>>> basicConstraints=critical,CA:TRUE, pathlen:0 > >>>>> > >>>>>sufficient for freeipa's CA certificate? > >>>> > >>>>I would say it should be sufficient for FreeIPA CA for now, given it > >>>>does not > >>>>allow subordinate CAs. However, I am still CCing Fraser and Honza for > >>>>reference, in case there would be some limitation in Dogtag/our CA > >>>>certificate > >>>>that would limit use of the basicConstraints extension. > >>> > >>>I'm not aware of any. > >>> > >>Yes, currently it is sufficient. When FreeIPA has sub-CAs > >>capability, a pathLenConstraint of zero will prevent the creation of > >>valid sub-CAs. > >> > >>Martin, Jan, this is a situation I had not considered. I propose > >>that we should detect pathLenConstraint and error out if sub-CAs > >>creation is attempted at a depth that cannot be valid. If you agree > >>I will add to design document. > > > >I agree. Please also add a ticket for this part. The check can be IMO > >added to FreeIPA 4.2.1, it is not critical for 4.2 GA. > Filed tickets: - https://fedorahosted.org/pki/ticket/1383 - https://fedorahosted.org/freeipa/ticket/5024 I think we should enforce in Dogtag's sub-CA code but I filed the IPA tracking ticket (4.2 Backlog for now) to make sure we handle the case properly in IPA as well. Cheers, Fraser > I believe there would be other things to check as well, e.g. directoryName > name constraints. > > > > >>>>Note that this basiConstrain would surely prevent you from using the > >>>>upcoming > >>>>feature > >>>> > >>>>http://www.freeipa.org/page/V4/Sub-CAs > >>>> > >>>>but this is OK with you, I assume. BTW, Fraser, we should record a > >>>>task to > >>>>properly watch for the pathlen limitation and have nice error > >>>>messages around > >>>>it when admin attempts to use Sub-CAs. > >>>> > >>>>Final note, there is a related ticket: > >>>>https://fedorahosted.org/freeipa/ticket/3466 > >>>> > >>>>Martin > >>>> > >>> > >>>Honza > >>> > >>>-- > >>>Jan Cholasta > > > > > -- > Jan Cholasta From janellenicole80 at gmail.com Fri May 15 12:45:14 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 15 May 2015 05:45:14 -0700 Subject: [Freeipa-users] more replication issues In-Reply-To: <5555CAA9.4070406@redhat.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> <55537817.9010904@redhat.com> <55537D10.4000208@gmail.com> <5555CAA9.4070406@redhat.com> Message-ID: <5555EA5A.1070200@gmail.com> On 5/15/15 3:30 AM, Ludwig Krispenz wrote: > > On 05/13/2015 06:34 PM, Janelle wrote: >> On 5/13/15 9:13 AM, Rich Megginson wrote: >>> On 05/13/2015 10:04 AM, Janelle wrote: >>>> On 5/13/15 8:49 AM, Rich Megginson wrote: >>>>> On 05/13/2015 09:40 AM, Janelle wrote: >>>>>> Recently I started seeing these crop up across my servers: >>>>>> >>>>>> slapi_ldap_bind - Error: could not bind id [cn=Replication >>>>>> Manager >>>>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] >>>>>> authentication mechanism [SIMPLE]: error 32 (No such object) >>>>>> errno 0 (Success) >>>>> >>>>> Does that entry exist? >>>>> >>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>>> base -b "cn=Replication Manager >>>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >>>>> >>>>> Does the parent exist? >>>>> >>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>>> base -b "ou=csusers,cn=config" >>>> >>>> I am finding that there does seem to be a relation to the above >>>> error and a possible CSN issue: >>>> >>>> Can't locate CSN 555131e5000200190000 in the changelog (DB >>>> rc=-30988). If replication stops, the consumer may need to be >>>> reinitialized. >>>> >>>> I guess what concerns me is what could be causing this. We don't do >>>> a lot of changes all the time. >>>> >>>> And in answer to the question above - we seem to have last the >>>> agreement somehow: >>>> >>>> No such object (32) >>>> >>> >>> Is there a DEL operation in the access log for "cn=Replication >>> Manager >>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? >>> >>> maybe something like >>> >>> # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication >>> Manager" >>> >> nope -- none of the servers have it. > your original message is very clear: > > could not bind id [cn=Replication Manager > masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] > authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 > (Success) > > this means that you have replication agreement wth SIMPLE auth which > uses a > nsDS5ReplicaBindDN: cn=Replication Manager > masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config > > which does not exist on the target server of the agreement. Now you > say it was never deleted, so it was probably never added, but used in > the replication agreements. How do you manage and setup replication > agreements ? > All replicas are configred simply: ipa-replica-prepare hostname... scp .. ipa-replica-install --no-ntp --setup-ca Replica-file That is it. NTP is not set because internal NTP servers are used. All replicas are CA replicas for safety (no certs are managed) After a few days to a week the message starts popping up in logs. ~J From jreg2k at gmail.com Fri May 15 13:55:10 2015 From: jreg2k at gmail.com (James James) Date: Fri, 15 May 2015 15:55:10 +0200 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: <5530755B.1030403@redhat.com> References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> Message-ID: Is it possible to change the nsds5ReplicaTimeout value to get rid of this timeout error ? 2015-04-17 4:52 GMT+02:00 Rich Megginson : > On 04/15/2015 10:44 PM, James James wrote: > > The ipareplica-install.log file in attachment ... > > > Here are the pertinent bits: > > 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] timeout 300 > 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from > SchemaCache > 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= > ldap://ipa.example.com:389 conn= instance at 0x484f4d0> > 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 from > SchemaCache > 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= > ldaps://ipa1.example.com:636 conn= instance at 0x4170290> > 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 382, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 372, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 368, in __setup_replica > r_bindpw=self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line > 969, in setup_replication > raise RuntimeError("Failed to start replication") > RuntimeError: Failed to start replication > > 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to start > replication > > The times are a little off, but I believe this corresponds to > [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. > Processed 1539 entries in 126 seconds. (12.21 entries/sec) > [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is > coming online; enabling replication > > I don't know why setup_replication is reporting an error if replication > completed successfully. > > > > 2015-04-16 2:22 GMT+02:00 Rob Crittenden : > >> Rich Megginson wrote: >> > On 04/15/2015 02:58 PM, James James wrote: >> >> Nothing on the replica .. maybye a process on the master. How can I >> >> check that ? >> > >> > I have no idea. But it seems highly unlikely that a process on the >> > master is able to shutdown a process on the replica . . . >> > >> > I would say that there is some problem with the ipa-replica-install not >> > properly checking the status - see below: >> > >> >> >> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson > >> >: >> >> >> >> On 04/15/2015 12:43 PM, James James wrote: >> >>> Here the log >> >>> >> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson > >>> >: >> >>> >> >>> On 04/15/2015 09:46 AM, James James wrote: >> >>>> Hello, >> >>>> >> >>>> I have been looking to solve my problem but I 'm asking for >> >>>> some help. >> >>>> >> >>>> The replication begins but cannot be completed .... >> >>>> >> >>>> I want to install a new fresh replica but I've always got >> >>>> this error : >> >>>> >> >>>> [21/35]: configure dirsrv ccache >> >>>> [22/35]: enable SASL mapping fallback >> >>>> [23/35]: restarting directory server >> >>>> [24/35]: setting up initial replication >> >>>> Starting replication, please wait until this has completed. >> >>>> Update in progress, 127 seconds elapsed >> >>>> Update in progress yet not in progress >> >>>> >> >>>> Update in progress yet not in progress >> >>> >> > >> > in progress yet not in progress???? The error log below clearly shows >> > that replica init succeeded after 127 seconds. >> > >> > IPA-ers - wasn't there some bug about checking replica status properly? >> > >> >> The loop looks at nsds5BeginReplicaRefresh, nsds5replicaUpdateInProgress >> and nsds5ReplicaLastInitStatus. >> >> It loops looking for nsds5BeginReplicaRefresh. If there is no value it >> prints "Update in progress, %d seconds elapsed". Once it gets a status, >> the update is done, and it looks at nsds5ReplicaLastInitStatus. If it >> isn't empty, doesn't include 'replica busy' or 'Total update succeeded' >> then it looks to see if nsds5replicaUpdateInProgress is TRUE. If it is, >> ir prints Update in progress yet not in progress and tries the loop again. >> >> AFAICT this part of a replica install doesn't restart 389-ds. >> >> /var/log/ipareplica-install.log may hold some details. >> >> rob >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Fri May 15 13:57:45 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 15 May 2015 15:57:45 +0200 Subject: [Freeipa-users] more replication issues In-Reply-To: <5555EA5A.1070200@gmail.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> <55537817.9010904@redhat.com> <55537D10.4000208@gmail.com> <5555CAA9.4070406@redhat.com> <5555EA5A.1070200@gmail.com> Message-ID: <5555FB59.3010903@redhat.com> On 05/15/2015 02:45 PM, Janelle wrote: > On 5/15/15 3:30 AM, Ludwig Krispenz wrote: >> >> On 05/13/2015 06:34 PM, Janelle wrote: >>> On 5/13/15 9:13 AM, Rich Megginson wrote: >>>> On 05/13/2015 10:04 AM, Janelle wrote: >>>>> On 5/13/15 8:49 AM, Rich Megginson wrote: >>>>>> On 05/13/2015 09:40 AM, Janelle wrote: >>>>>>> Recently I started seeing these crop up across my servers: >>>>>>> >>>>>>> slapi_ldap_bind - Error: could not bind id [cn=Replication >>>>>>> Manager >>>>>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] >>>>>>> authentication mechanism [SIMPLE]: error 32 (No such object) >>>>>>> errno 0 (Success) >>>>>> >>>>>> Does that entry exist? >>>>>> >>>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>>>> base -b "cn=Replication Manager >>>>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >>>>>> >>>>>> Does the parent exist? >>>>>> >>>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s >>>>>> base -b "ou=csusers,cn=config" >>>>> >>>>> I am finding that there does seem to be a relation to the above >>>>> error and a possible CSN issue: >>>>> >>>>> Can't locate CSN 555131e5000200190000 in the changelog (DB >>>>> rc=-30988). If replication stops, the consumer may need to be >>>>> reinitialized. >>>>> >>>>> I guess what concerns me is what could be causing this. We don't >>>>> do a lot of changes all the time. >>>>> >>>>> And in answer to the question above - we seem to have last the >>>>> agreement somehow: >>>>> >>>>> No such object (32) >>>>> >>>> >>>> Is there a DEL operation in the access log for "cn=Replication >>>> Manager >>>> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? >>>> >>>> maybe something like >>>> >>>> # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication >>>> Manager" >>>> >>> nope -- none of the servers have it. >> your original message is very clear: >> >> could not bind id [cn=Replication Manager >> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] >> authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 >> (Success) >> >> this means that you have replication agreement wth SIMPLE auth which >> uses a >> nsDS5ReplicaBindDN: cn=Replication Manager >> masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config >> >> which does not exist on the target server of the agreement. Now you >> say it was never deleted, so it was probably never added, but used in >> the replication agreements. How do you manage and setup replication >> agreements ? >> > All replicas are configred simply: > > ipa-replica-prepare hostname... > scp .. > ipa-replica-install --no-ntp --setup-ca Replica-file > > That is it. NTP is not set because internal NTP servers are used. All > replicas are CA replicas for safety (no certs are managed) ok, I was a bit puzzled because ipa uses ldapprincipals and gssapi for the main suffix replication. But I just verified that after ipa-replica-install --setup-ca CA replication is setup with users in ou=csusers,cn=config and uses it as replica binddn, I have no idea why it would disappear. when Rich asked to search for a DEL, did you check this on the server that logged the message or on the endpoint of the replication agreement (it should be there), and you may have to check in the rotated access logs access. as well > > After a few days to a week the message starts popping up in logs. > > ~J > From rmeggins at redhat.com Fri May 15 14:00:10 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 08:00:10 -0600 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> Message-ID: <5555FBEA.8090005@redhat.com> On 05/15/2015 07:55 AM, James James wrote: > Is it possible to change the nsds5ReplicaTimeout value to get rid of > this timeout error ? What timeout error? > > 2015-04-17 4:52 GMT+02:00 Rich Megginson >: > > On 04/15/2015 10:44 PM, James James wrote: >> The ipareplica-install.log file in attachment ... > > Here are the pertinent bits: > > 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] > timeout 300 > 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 > from SchemaCache > 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache > url=ldap://ipa.example.com:389 > conn= > 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 > from SchemaCache > 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache > url=ldaps://ipa1.example.com:636 > conn= > 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 382, in start_creation > run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 372, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line > 368, in __setup_replica > r_bindpw=self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 969, in setup_replication > raise RuntimeError("Failed to start replication") > RuntimeError: Failed to start replication > > 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to start > replication > > The times are a little off, but I believe this corresponds to > [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. > Processed 1539 entries in 126 seconds. (12.21 entries/sec) > [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr > is coming online; enabling replication > > I don't know why setup_replication is reporting an error if > replication completed successfully. > > >> >> 2015-04-16 2:22 GMT+02:00 Rob Crittenden > >: >> >> Rich Megginson wrote: >> > On 04/15/2015 02:58 PM, James James wrote: >> >> Nothing on the replica .. maybye a process on the master. >> How can I >> >> check that ? >> > >> > I have no idea. But it seems highly unlikely that a >> process on the >> > master is able to shutdown a process on the replica . . . >> > >> > I would say that there is some problem with the >> ipa-replica-install not >> > properly checking the status - see below: >> > >> >> >> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson >> >> >> >>: >> >> >> >> On 04/15/2015 12:43 PM, James James wrote: >> >>> Here the log >> >>> >> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >> >> >>> > >>: >> >>> >> >>> On 04/15/2015 09:46 AM, James James wrote: >> >>>> Hello, >> >>>> >> >>>> I have been looking to solve my problem but I 'm >> asking for >> >>>> some help. >> >>>> >> >>>> The replication begins but cannot be completed .... >> >>>> >> >>>> I want to install a new fresh replica but I've >> always got >> >>>> this error : >> >>>> >> >>>> [21/35]: configure dirsrv ccache >> >>>> [22/35]: enable SASL mapping fallback >> >>>> [23/35]: restarting directory server >> >>>> [24/35]: setting up initial replication >> >>>> Starting replication, please wait until this has >> completed. >> >>>> Update in progress, 127 seconds elapsed >> >>>> Update in progress yet not in progress >> >>>> >> >>>> Update in progress yet not in progress >> >>> >> > >> > in progress yet not in progress???? The error log below >> clearly shows >> > that replica init succeeded after 127 seconds. >> > >> > IPA-ers - wasn't there some bug about checking replica >> status properly? >> > >> >> The loop looks at nsds5BeginReplicaRefresh, >> nsds5replicaUpdateInProgress >> and nsds5ReplicaLastInitStatus. >> >> It loops looking for nsds5BeginReplicaRefresh. If there is no >> value it >> prints "Update in progress, %d seconds elapsed". Once it gets >> a status, >> the update is done, and it looks at >> nsds5ReplicaLastInitStatus. If it >> isn't empty, doesn't include 'replica busy' or 'Total update >> succeeded' >> then it looks to see if nsds5replicaUpdateInProgress is TRUE. >> If it is, >> ir prints Update in progress yet not in progress and tries >> the loop again. >> >> AFAICT this part of a replica install doesn't restart 389-ds. >> >> /var/log/ipareplica-install.log may hold some details. >> >> rob >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri May 15 14:09:53 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 08:09:53 -0600 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> Message-ID: <5555FE31.6060202@redhat.com> On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>> supersecretpassword --passsync supersecretpassword --cacert >>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>> Directory Manager password: >>> >>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to certificate >>> database for ipadc1.ipadomain.net >>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>> The user for the Windows PassSync service is >>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>> Windows PassSync system account exists, not resetting password >>> ipa: INFO: Added new sync agreement, waiting for it to become ready . . >>> . >>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>> error: Connect error: start: 0: end: 0 >>> ipa: INFO: Agreement is ready, starting replication . . . >>> Starting replication, please wait until this has completed. >>> >>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>> error: >>> Connect error] >> Have you tried using ldapsearch to verify the connection? >> >> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h >> addc2.test.mycompany.net -D "cn=ad >> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >> "objectclass=*" >> >> and/or >> >> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL >> -ZZ -h addc2.test.mycompany.net -D "cn=ad >> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >> "objectclass=*" >> > Both commands give the same successful result. I don't think it's a > problem with the credentials because I was able to generate different > error messages during the attempted sync setup if I intentionally gave a > bad password or username. Ok. Have you tried enabling the replication log level? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > Here is what happens when I run the above > commands : > > [root at ipadc1 cacerts]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM > ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad > sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s > base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*" > dn: cn=Users,dc=test,dc=mycompany,dc=net > objectClass: top > objectClass: container > cn: Users > description: Default container for upgraded user accounts > distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net > instanceType: 4 > whenCreated: 20150515024307.0Z > whenChanged: 20150515024307.0Z > uSNCreated: 5696 > uSNChanged: 5696 > showInAdvancedViewOnly: FALSE > name: Users > objectGUID:: V9KaoufynkWbJpSo2PjxiA== > systemFlags: -1946157056 > objectCategory: > CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net > isCriticalSystemObject: TRUE > dSCorePropagationData: 20150515025646.0Z > dSCorePropagationData: 16010101000001.0Z > > [root at ipadc1 cacerts]# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer > ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad > sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s > base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*" > dn: cn=Users,dc=test,dc=mycompany,dc=net > objectClass: top > objectClass: container > cn: Users > description: Default container for upgraded user accounts > distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net > instanceType: 4 > whenCreated: 20150515024307.0Z > whenChanged: 20150515024307.0Z > uSNCreated: 5696 > uSNChanged: 5696 > showInAdvancedViewOnly: FALSE > name: Users > objectGUID:: V9KaoufynkWbJpSo2PjxiA== > systemFlags: -1946157056 > objectCategory: > CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net > isCriticalSystemObject: TRUE > dSCorePropagationData: 20150515025646.0Z > dSCorePropagationData: 16010101000001.0Z > > From jreg2k at gmail.com Fri May 15 14:22:16 2015 From: jreg2k at gmail.com (James James) Date: Fri, 15 May 2015 16:22:16 +0200 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: <5555FBEA.8090005@redhat.com> References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> <5555FBEA.8090005@redhat.com> Message-ID: I think that : Starting replication, please wait until this has completed. Update in progress, 127 seconds elapsed Update in progress yet not in progress looks like a time error : https://fedorahosted.org/freeipa/ticket/4756 2015-05-15 16:00 GMT+02:00 Rich Megginson : > On 05/15/2015 07:55 AM, James James wrote: > > Is it possible to change the nsds5ReplicaTimeout value to get rid of this > timeout error ? > > > What timeout error? > > > 2015-04-17 4:52 GMT+02:00 Rich Megginson : > >> On 04/15/2015 10:44 PM, James James wrote: >> >> The ipareplica-install.log file in attachment ... >> >> >> Here are the pertinent bits: >> >> 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] timeout >> 300 >> 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from >> SchemaCache >> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= >> ldap://ipa.example.com:389 conn=> instance at 0x484f4d0> >> 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 from >> SchemaCache >> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= >> ldaps://ipa1.example.com:636 conn=> instance at 0x4170290> >> 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 382, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 372, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >> 368, in __setup_replica >> r_bindpw=self.dm_password) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line >> 969, in setup_replication >> raise RuntimeError("Failed to start replication") >> RuntimeError: Failed to start replication >> >> 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to start >> replication >> >> The times are a little off, but I believe this corresponds to >> [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. >> Processed 1539 entries in 126 seconds. (12.21 entries/sec) >> [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is >> coming online; enabling replication >> >> I don't know why setup_replication is reporting an error if replication >> completed successfully. >> >> >> >> 2015-04-16 2:22 GMT+02:00 Rob Crittenden : >> >>> Rich Megginson wrote: >>> > On 04/15/2015 02:58 PM, James James wrote: >>> >> Nothing on the replica .. maybye a process on the master. How can I >>> >> check that ? >>> > >>> > I have no idea. But it seems highly unlikely that a process on the >>> > master is able to shutdown a process on the replica . . . >>> > >>> > I would say that there is some problem with the ipa-replica-install not >>> > properly checking the status - see below: >>> > >>> >> >>> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson >> >> >: >>> >> >>> >> On 04/15/2015 12:43 PM, James James wrote: >>> >>> Here the log >>> >>> >>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >> >>> >: >>> >>> >>> >>> On 04/15/2015 09:46 AM, James James wrote: >>> >>>> Hello, >>> >>>> >>> >>>> I have been looking to solve my problem but I 'm asking for >>> >>>> some help. >>> >>>> >>> >>>> The replication begins but cannot be completed .... >>> >>>> >>> >>>> I want to install a new fresh replica but I've always got >>> >>>> this error : >>> >>>> >>> >>>> [21/35]: configure dirsrv ccache >>> >>>> [22/35]: enable SASL mapping fallback >>> >>>> [23/35]: restarting directory server >>> >>>> [24/35]: setting up initial replication >>> >>>> Starting replication, please wait until this has completed. >>> >>>> Update in progress, 127 seconds elapsed >>> >>>> Update in progress yet not in progress >>> >>>> >>> >>>> Update in progress yet not in progress >>> >>> >>> > >>> > in progress yet not in progress???? The error log below clearly shows >>> > that replica init succeeded after 127 seconds. >>> > >>> > IPA-ers - wasn't there some bug about checking replica status properly? >>> > >>> >>> The loop looks at nsds5BeginReplicaRefresh, nsds5replicaUpdateInProgress >>> and nsds5ReplicaLastInitStatus. >>> >>> It loops looking for nsds5BeginReplicaRefresh. If there is no value it >>> prints "Update in progress, %d seconds elapsed". Once it gets a status, >>> the update is done, and it looks at nsds5ReplicaLastInitStatus. If it >>> isn't empty, doesn't include 'replica busy' or 'Total update succeeded' >>> then it looks to see if nsds5replicaUpdateInProgress is TRUE. If it is, >>> ir prints Update in progress yet not in progress and tries the loop >>> again. >>> >>> AFAICT this part of a replica install doesn't restart 389-ds. >>> >>> /var/log/ipareplica-install.log may hold some details. >>> >>> rob >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri May 15 14:32:00 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 08:32:00 -0600 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> <5555FBEA.8090005@redhat.com> Message-ID: <55560360.706@redhat.com> On 05/15/2015 08:22 AM, James James wrote: > I think that : > > Starting replication, please wait until this has completed. > Update in progress, 127 seconds elapsed > Update in progress yet not in progress > > > looks like a time error : https://fedorahosted.org/freeipa/ticket/4756 That issue should have been fixed in 389-ds-base-1.3.3 branch. What version of 389-ds-base? rpm -q 389-ds-base > > 2015-05-15 16:00 GMT+02:00 Rich Megginson >: > > On 05/15/2015 07:55 AM, James James wrote: >> Is it possible to change the nsds5ReplicaTimeout value to get rid >> of this timeout error ? > > What timeout error? > >> >> 2015-04-17 4:52 GMT+02:00 Rich Megginson > >: >> >> On 04/15/2015 10:44 PM, James James wrote: >>> The ipareplica-install.log file in attachment ... >> >> Here are the pertinent bits: >> >> 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost >> [389] timeout 300 >> 2015-04-15T15:06:32Z DEBUG flushing >> ldap://ipa.example.com:389 from SchemaCache >> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache >> url=ldap://ipa.example.com:389 >> conn= >> 2015-04-15T15:06:32Z DEBUG flushing >> ldaps://ipa1.example.com:636 from SchemaCache >> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache >> url=ldaps://ipa1.example.com:636 >> conn= >> 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 382, in start_creation >> run_step(full_msg, method) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 372, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >> line 368, in __setup_replica >> r_bindpw=self.dm_password) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >> line 969, in setup_replication >> raise RuntimeError("Failed to start replication") >> RuntimeError: Failed to start replication >> >> 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to >> start replication >> >> The times are a little off, but I believe this corresponds to >> [15/Apr/2015:17:08:39 +0200] - import userRoot: Import >> complete. Processed 1539 entries in 126 seconds. (12.21 >> entries/sec) >> [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - >> multimaster_be_state_change: replica >> dc=lix,dc=polytechnique,dc=fr is coming online; enabling >> replication >> >> I don't know why setup_replication is reporting an error if >> replication completed successfully. >> >> >>> >>> 2015-04-16 2:22 GMT+02:00 Rob Crittenden >>> >: >>> >>> Rich Megginson wrote: >>> > On 04/15/2015 02:58 PM, James James wrote: >>> >> Nothing on the replica .. maybye a process on the >>> master. How can I >>> >> check that ? >>> > >>> > I have no idea. But it seems highly unlikely that a >>> process on the >>> > master is able to shutdown a process on the replica . . . >>> > >>> > I would say that there is some problem with the >>> ipa-replica-install not >>> > properly checking the status - see below: >>> > >>> >> >>> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson >>> >>> >> >> >>: >>> >> >>> >> On 04/15/2015 12:43 PM, James James wrote: >>> >>> Here the log >>> >>> >>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >>> >>> >>> >> >>: >>> >>> >>> >>> On 04/15/2015 09:46 AM, James James wrote: >>> >>>> Hello, >>> >>>> >>> >>>> I have been looking to solve my problem but >>> I 'm asking for >>> >>>> some help. >>> >>>> >>> >>>> The replication begins but cannot be >>> completed .... >>> >>>> >>> >>>> I want to install a new fresh replica but >>> I've always got >>> >>>> this error : >>> >>>> >>> >>>> [21/35]: configure dirsrv ccache >>> >>>> [22/35]: enable SASL mapping fallback >>> >>>> [23/35]: restarting directory server >>> >>>> [24/35]: setting up initial replication >>> >>>> Starting replication, please wait until this has >>> completed. >>> >>>> Update in progress, 127 seconds elapsed >>> >>>> Update in progress yet not in progress >>> >>>> >>> >>>> Update in progress yet not in progress >>> >>> >>> > >>> > in progress yet not in progress???? The error log >>> below clearly shows >>> > that replica init succeeded after 127 seconds. >>> > >>> > IPA-ers - wasn't there some bug about checking replica >>> status properly? >>> > >>> >>> The loop looks at nsds5BeginReplicaRefresh, >>> nsds5replicaUpdateInProgress >>> and nsds5ReplicaLastInitStatus. >>> >>> It loops looking for nsds5BeginReplicaRefresh. If there >>> is no value it >>> prints "Update in progress, %d seconds elapsed". Once it >>> gets a status, >>> the update is done, and it looks at >>> nsds5ReplicaLastInitStatus. If it >>> isn't empty, doesn't include 'replica busy' or 'Total >>> update succeeded' >>> then it looks to see if nsds5replicaUpdateInProgress is >>> TRUE. If it is, >>> ir prints Update in progress yet not in progress and >>> tries the loop again. >>> >>> AFAICT this part of a replica install doesn't restart >>> 389-ds. >>> >>> /var/log/ipareplica-install.log may hold some details. >>> >>> rob >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Fri May 15 14:46:31 2015 From: jreg2k at gmail.com (James James) Date: Fri, 15 May 2015 16:46:31 +0200 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: <55560360.706@redhat.com> References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> <5555FBEA.8090005@redhat.com> <55560360.706@redhat.com> Message-ID: [root at ipa ~]# rpm -q 389-ds-base 389-ds-base-1.2.11.15-50.el6_6.x86_64 2015-05-15 16:32 GMT+02:00 Rich Megginson : > On 05/15/2015 08:22 AM, James James wrote: > > I think that : > > Starting replication, please wait until this has completed. > Update in progress, 127 seconds elapsed > Update in progress yet not in progress > > > looks like a time error : https://fedorahosted.org/freeipa/ticket/4756 > > > That issue should have been fixed in 389-ds-base-1.3.3 branch. What > version of 389-ds-base? rpm -q 389-ds-base > > > > 2015-05-15 16:00 GMT+02:00 Rich Megginson : > >> On 05/15/2015 07:55 AM, James James wrote: >> >> Is it possible to change the nsds5ReplicaTimeout value to get rid of >> this timeout error ? >> >> >> What timeout error? >> >> >> 2015-04-17 4:52 GMT+02:00 Rich Megginson : >> >>> On 04/15/2015 10:44 PM, James James wrote: >>> >>> The ipareplica-install.log file in attachment ... >>> >>> >>> Here are the pertinent bits: >>> >>> 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] timeout >>> 300 >>> 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from >>> SchemaCache >>> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= >>> ldap://ipa.example.com:389 conn=>> instance at 0x484f4d0> >>> 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 from >>> SchemaCache >>> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= >>> ldaps://ipa1.example.com:636 conn=>> instance at 0x4170290> >>> 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 382, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 372, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >>> 368, in __setup_replica >>> r_bindpw=self.dm_password) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line >>> 969, in setup_replication >>> raise RuntimeError("Failed to start replication") >>> RuntimeError: Failed to start replication >>> >>> 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to start >>> replication >>> >>> The times are a little off, but I believe this corresponds to >>> [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. >>> Processed 1539 entries in 126 seconds. (12.21 entries/sec) >>> [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - >>> multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is >>> coming online; enabling replication >>> >>> I don't know why setup_replication is reporting an error if replication >>> completed successfully. >>> >>> >>> >>> 2015-04-16 2:22 GMT+02:00 Rob Crittenden : >>> >>>> Rich Megginson wrote: >>>> > On 04/15/2015 02:58 PM, James James wrote: >>>> >> Nothing on the replica .. maybye a process on the master. How can I >>>> >> check that ? >>>> > >>>> > I have no idea. But it seems highly unlikely that a process on the >>>> > master is able to shutdown a process on the replica . . . >>>> > >>>> > I would say that there is some problem with the ipa-replica-install >>>> not >>>> > properly checking the status - see below: >>>> > >>>> >> >>>> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson >>> >> >: >>>> >> >>>> >> On 04/15/2015 12:43 PM, James James wrote: >>>> >>> Here the log >>>> >>> >>>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >>> >>> >: >>>> >>> >>>> >>> On 04/15/2015 09:46 AM, James James wrote: >>>> >>>> Hello, >>>> >>>> >>>> >>>> I have been looking to solve my problem but I 'm asking for >>>> >>>> some help. >>>> >>>> >>>> >>>> The replication begins but cannot be completed .... >>>> >>>> >>>> >>>> I want to install a new fresh replica but I've always got >>>> >>>> this error : >>>> >>>> >>>> >>>> [21/35]: configure dirsrv ccache >>>> >>>> [22/35]: enable SASL mapping fallback >>>> >>>> [23/35]: restarting directory server >>>> >>>> [24/35]: setting up initial replication >>>> >>>> Starting replication, please wait until this has completed. >>>> >>>> Update in progress, 127 seconds elapsed >>>> >>>> Update in progress yet not in progress >>>> >>>> >>>> >>>> Update in progress yet not in progress >>>> >>> >>>> > >>>> > in progress yet not in progress???? The error log below clearly shows >>>> > that replica init succeeded after 127 seconds. >>>> > >>>> > IPA-ers - wasn't there some bug about checking replica status >>>> properly? >>>> > >>>> >>>> The loop looks at nsds5BeginReplicaRefresh, nsds5replicaUpdateInProgress >>>> and nsds5ReplicaLastInitStatus. >>>> >>>> It loops looking for nsds5BeginReplicaRefresh. If there is no value it >>>> prints "Update in progress, %d seconds elapsed". Once it gets a status, >>>> the update is done, and it looks at nsds5ReplicaLastInitStatus. If it >>>> isn't empty, doesn't include 'replica busy' or 'Total update succeeded' >>>> then it looks to see if nsds5replicaUpdateInProgress is TRUE. If it is, >>>> ir prints Update in progress yet not in progress and tries the loop >>>> again. >>>> >>>> AFAICT this part of a replica install doesn't restart 389-ds. >>>> >>>> /var/log/ipareplica-install.log may hold some details. >>>> >>>> rob >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri May 15 14:58:01 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 08:58:01 -0600 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> <5555FBEA.8090005@redhat.com> <55560360.706@redhat.com> Message-ID: <55560979.50508@redhat.com> On 05/15/2015 08:46 AM, James James wrote: > [root at ipa ~]# rpm -q 389-ds-base > 389-ds-base-1.2.11.15-50.el6_6.x86_64 Ok. Looks like this is planned to be fixed in RHEL 6.7 with version 389-ds-base-1.2.11.15-56.el6 I don't know if there are any workarounds. > > > > 2015-05-15 16:32 GMT+02:00 Rich Megginson >: > > On 05/15/2015 08:22 AM, James James wrote: >> I think that : >> >> Starting replication, please wait until this has completed. >> Update in progress, 127 seconds elapsed >> Update in progress yet not in progress >> >> >> looks like a time error : >> https://fedorahosted.org/freeipa/ticket/4756 > > That issue should have been fixed in 389-ds-base-1.3.3 branch. > What version of 389-ds-base? rpm -q 389-ds-base > > >> >> 2015-05-15 16:00 GMT+02:00 Rich Megginson > >: >> >> On 05/15/2015 07:55 AM, James James wrote: >>> Is it possible to change the nsds5ReplicaTimeout value to >>> get rid of this timeout error ? >> >> What timeout error? >> >>> >>> 2015-04-17 4:52 GMT+02:00 Rich Megginson >>> >: >>> >>> On 04/15/2015 10:44 PM, James James wrote: >>>> The ipareplica-install.log file in attachment ... >>> >>> Here are the pertinent bits: >>> >>> 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: >>> localhost [389] timeout 300 >>> 2015-04-15T15:06:32Z DEBUG flushing >>> ldap://ipa.example.com:389 from SchemaCache >>> 2015-04-15T15:06:32Z DEBUG retrieving schema for >>> SchemaCache url=ldap://ipa.example.com:389 >>> conn=>> 0x484f4d0> >>> 2015-04-15T15:06:32Z DEBUG flushing >>> ldaps://ipa1.example.com:636 from SchemaCache >>> 2015-04-15T15:06:32Z DEBUG retrieving schema for >>> SchemaCache url=ldaps://ipa1.example.com:636 >>> conn=>> 0x4170290> >>> 2015-04-15T15:08:44Z DEBUG Traceback (most recent call >>> last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 382, in start_creation >>> run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 372, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>> line 368, in __setup_replica >>> r_bindpw=self.dm_password) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>> line 969, in setup_replication >>> raise RuntimeError("Failed to start replication") >>> RuntimeError: Failed to start replication >>> >>> 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: >>> Failed to start replication >>> >>> The times are a little off, but I believe this >>> corresponds to >>> [15/Apr/2015:17:08:39 +0200] - import userRoot: Import >>> complete. Processed 1539 entries in 126 seconds. (12.21 >>> entries/sec) >>> [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - >>> multimaster_be_state_change: replica >>> dc=lix,dc=polytechnique,dc=fr is coming online; enabling >>> replication >>> >>> I don't know why setup_replication is reporting an error >>> if replication completed successfully. >>> >>> >>>> >>>> 2015-04-16 2:22 GMT+02:00 Rob Crittenden >>>> >: >>>> >>>> Rich Megginson wrote: >>>> > On 04/15/2015 02:58 PM, James James wrote: >>>> >> Nothing on the replica .. maybye a process on >>>> the master. How can I >>>> >> check that ? >>>> > >>>> > I have no idea. But it seems highly unlikely >>>> that a process on the >>>> > master is able to shutdown a process on the >>>> replica . . . >>>> > >>>> > I would say that there is some problem with the >>>> ipa-replica-install not >>>> > properly checking the status - see below: >>>> > >>>> >> >>>> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson >>>> >>>> >> >>> >>: >>>> >> >>>> >> On 04/15/2015 12:43 PM, James James wrote: >>>> >>> Here the log >>>> >>> >>>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >>>> >>>> >>> >>> >>: >>>> >>> >>>> >>> On 04/15/2015 09:46 AM, James James wrote: >>>> >>>> Hello, >>>> >>>> >>>> >>>> I have been looking to solve my problem >>>> but I 'm asking for >>>> >>>> some help. >>>> >>>> >>>> >>>> The replication begins but cannot be >>>> completed .... >>>> >>>> >>>> >>>> I want to install a new fresh replica >>>> but I've always got >>>> >>>> this error : >>>> >>>> >>>> >>>> [21/35]: configure dirsrv ccache >>>> >>>> [22/35]: enable SASL mapping fallback >>>> >>>> [23/35]: restarting directory server >>>> >>>> [24/35]: setting up initial replication >>>> >>>> Starting replication, please wait until >>>> this has completed. >>>> >>>> Update in progress, 127 seconds elapsed >>>> >>>> Update in progress yet not in progress >>>> >>>> >>>> >>>> Update in progress yet not in progress >>>> >>> >>>> > >>>> > in progress yet not in progress???? The error log >>>> below clearly shows >>>> > that replica init succeeded after 127 seconds. >>>> > >>>> > IPA-ers - wasn't there some bug about checking >>>> replica status properly? >>>> > >>>> >>>> The loop looks at nsds5BeginReplicaRefresh, >>>> nsds5replicaUpdateInProgress >>>> and nsds5ReplicaLastInitStatus. >>>> >>>> It loops looking for nsds5BeginReplicaRefresh. If >>>> there is no value it >>>> prints "Update in progress, %d seconds elapsed". >>>> Once it gets a status, >>>> the update is done, and it looks at >>>> nsds5ReplicaLastInitStatus. If it >>>> isn't empty, doesn't include 'replica busy' or >>>> 'Total update succeeded' >>>> then it looks to see if >>>> nsds5replicaUpdateInProgress is TRUE. If it is, >>>> ir prints Update in progress yet not in progress >>>> and tries the loop again. >>>> >>>> AFAICT this part of a replica install doesn't >>>> restart 389-ds. >>>> >>>> /var/log/ipareplica-install.log may hold some details. >>>> >>>> rob >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Fri May 15 15:11:35 2015 From: jreg2k at gmail.com (James James) Date: Fri, 15 May 2015 17:11:35 +0200 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: <55560979.50508@redhat.com> References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> <5555FBEA.8090005@redhat.com> <55560360.706@redhat.com> <55560979.50508@redhat.com> Message-ID: ok Rob. Thanks for your help. I will wait for the Scientific Linux 6.7 . Best. James 2015-05-15 16:58 GMT+02:00 Rich Megginson : > On 05/15/2015 08:46 AM, James James wrote: > > [root at ipa ~]# rpm -q 389-ds-base > 389-ds-base-1.2.11.15-50.el6_6.x86_64 > > > Ok. Looks like this is planned to be fixed in RHEL 6.7 with version > 389-ds-base-1.2.11.15-56.el6 > > I don't know if there are any workarounds. > > > > > > 2015-05-15 16:32 GMT+02:00 Rich Megginson : > >> On 05/15/2015 08:22 AM, James James wrote: >> >> I think that : >> >> Starting replication, please wait until this has completed. >> Update in progress, 127 seconds elapsed >> Update in progress yet not in progress >> >> >> looks like a time error : https://fedorahosted.org/freeipa/ticket/4756 >> >> >> That issue should have been fixed in 389-ds-base-1.3.3 branch. What >> version of 389-ds-base? rpm -q 389-ds-base >> >> >> >> 2015-05-15 16:00 GMT+02:00 Rich Megginson : >> >>> On 05/15/2015 07:55 AM, James James wrote: >>> >>> Is it possible to change the nsds5ReplicaTimeout value to get rid of >>> this timeout error ? >>> >>> >>> What timeout error? >>> >>> >>> 2015-04-17 4:52 GMT+02:00 Rich Megginson : >>> >>>> On 04/15/2015 10:44 PM, James James wrote: >>>> >>>> The ipareplica-install.log file in attachment ... >>>> >>>> >>>> Here are the pertinent bits: >>>> >>>> 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] timeout >>>> 300 >>>> 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from >>>> SchemaCache >>>> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= >>>> ldap://ipa.example.com:389 conn=>>> instance at 0x484f4d0> >>>> 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 from >>>> SchemaCache >>>> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url= >>>> ldaps://ipa1.example.com:636 conn=>>> instance at 0x4170290> >>>> 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 382, in start_creation >>>> run_step(full_msg, method) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 372, in run_step >>>> method() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >>>> 368, in __setup_replica >>>> r_bindpw=self.dm_password) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line >>>> 969, in setup_replication >>>> raise RuntimeError("Failed to start replication") >>>> RuntimeError: Failed to start replication >>>> >>>> 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to start >>>> replication >>>> >>>> The times are a little off, but I believe this corresponds to >>>> [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. >>>> Processed 1539 entries in 126 seconds. (12.21 entries/sec) >>>> [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - >>>> multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is >>>> coming online; enabling replication >>>> >>>> I don't know why setup_replication is reporting an error if >>>> replication completed successfully. >>>> >>>> >>>> >>>> 2015-04-16 2:22 GMT+02:00 Rob Crittenden : >>>> >>>>> Rich Megginson wrote: >>>>> > On 04/15/2015 02:58 PM, James James wrote: >>>>> >> Nothing on the replica .. maybye a process on the master. How can I >>>>> >> check that ? >>>>> > >>>>> > I have no idea. But it seems highly unlikely that a process on the >>>>> > master is able to shutdown a process on the replica . . . >>>>> > >>>>> > I would say that there is some problem with the ipa-replica-install >>>>> not >>>>> > properly checking the status - see below: >>>>> > >>>>> >> >>>>> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson >>>> >> >: >>>>> >> >>>>> >> On 04/15/2015 12:43 PM, James James wrote: >>>>> >>> Here the log >>>>> >>> >>>>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >>>> >>> >: >>>>> >>> >>>>> >>> On 04/15/2015 09:46 AM, James James wrote: >>>>> >>>> Hello, >>>>> >>>> >>>>> >>>> I have been looking to solve my problem but I 'm asking >>>>> for >>>>> >>>> some help. >>>>> >>>> >>>>> >>>> The replication begins but cannot be completed .... >>>>> >>>> >>>>> >>>> I want to install a new fresh replica but I've always got >>>>> >>>> this error : >>>>> >>>> >>>>> >>>> [21/35]: configure dirsrv ccache >>>>> >>>> [22/35]: enable SASL mapping fallback >>>>> >>>> [23/35]: restarting directory server >>>>> >>>> [24/35]: setting up initial replication >>>>> >>>> Starting replication, please wait until this has >>>>> completed. >>>>> >>>> Update in progress, 127 seconds elapsed >>>>> >>>> Update in progress yet not in progress >>>>> >>>> >>>>> >>>> Update in progress yet not in progress >>>>> >>> >>>>> > >>>>> > in progress yet not in progress???? The error log below clearly >>>>> shows >>>>> > that replica init succeeded after 127 seconds. >>>>> > >>>>> > IPA-ers - wasn't there some bug about checking replica status >>>>> properly? >>>>> > >>>>> >>>>> The loop looks at nsds5BeginReplicaRefresh, >>>>> nsds5replicaUpdateInProgress >>>>> and nsds5ReplicaLastInitStatus. >>>>> >>>>> It loops looking for nsds5BeginReplicaRefresh. If there is no value it >>>>> prints "Update in progress, %d seconds elapsed". Once it gets a status, >>>>> the update is done, and it looks at nsds5ReplicaLastInitStatus. If it >>>>> isn't empty, doesn't include 'replica busy' or 'Total update succeeded' >>>>> then it looks to see if nsds5replicaUpdateInProgress is TRUE. If it is, >>>>> ir prints Update in progress yet not in progress and tries the loop >>>>> again. >>>>> >>>>> AFAICT this part of a replica install doesn't restart 389-ds. >>>>> >>>>> /var/log/ipareplica-install.log may hold some details. >>>>> >>>>> rob >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Fri May 15 15:53:22 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 15 May 2015 10:53:22 -0500 Subject: [Freeipa-users] more replication issues In-Reply-To: <5555FB59.3010903@redhat.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> <55537817.9010904@redhat.com> <55537D10.4000208@gmail.com> <5555CAA9.4070406@redhat.com> <5555EA5A.1070200@gmail.com> <5555FB59.3010903@redhat.com> Message-ID: <81D0E7EE-1034-4BF8-AFAF-EAC920ABB4F3@gmail.com> > > On May 15, 2015, at 08:57, Ludwig Krispenz wrote: > > >> On 05/15/2015 02:45 PM, Janelle wrote: >>> On 5/15/15 3:30 AM, Ludwig Krispenz wrote: >>> >>>> On 05/13/2015 06:34 PM, Janelle wrote: >>>>> On 5/13/15 9:13 AM, Rich Megginson wrote: >>>>>> On 05/13/2015 10:04 AM, Janelle wrote: >>>>>>> On 5/13/15 8:49 AM, Rich Megginson wrote: >>>>>>>> On 05/13/2015 09:40 AM, Janelle wrote: >>>>>>>> Recently I started seeing these crop up across my servers: >>>>>>>> >>>>>>>> slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) >>>>>>> >>>>>>> Does that entry exist? >>>>>>> >>>>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b "cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >>>>>>> >>>>>>> Does the parent exist? >>>>>>> >>>>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b "ou=csusers,cn=config" >>>>>> >>>>>> I am finding that there does seem to be a relation to the above error and a possible CSN issue: >>>>>> >>>>>> Can't locate CSN 555131e5000200190000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. >>>>>> >>>>>> I guess what concerns me is what could be causing this. We don't do a lot of changes all the time. >>>>>> >>>>>> And in answer to the question above - we seem to have last the agreement somehow: >>>>>> >>>>>> No such object (32) >>>>>> >>>>> >>>>> Is there a DEL operation in the access log for "cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? >>>>> >>>>> maybe something like >>>>> >>>>> # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication Manager" >>>>> >>>> nope -- none of the servers have it. >>> your original message is very clear: >>> >>> could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) >>> >>> this means that you have replication agreement wth SIMPLE auth which uses a >>> nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config >>> >>> which does not exist on the target server of the agreement. Now you say it was never deleted, so it was probably never added, but used in the replication agreements. How do you manage and setup replication agreements ? >>> >> All replicas are configred simply: >> >> ipa-replica-prepare hostname... >> scp .. >> ipa-replica-install --no-ntp --setup-ca Replica-file >> >> That is it. NTP is not set because internal NTP servers are used. All replicas are CA replicas for safety (no certs are managed) > ok, I was a bit puzzled because ipa uses ldapprincipals and gssapi for the main suffix replication. > But I just verified that after ipa-replica-install --setup-ca CA replication is setup with users in ou=csusers,cn=config and uses it as replica binddn, I have no idea why it would disappear. > > when Rich asked to search for a DEL, did you check this on the server that logged the message or on the endpoint of the replication agreement (it should be there), and you may have to check in the rotated access logs access. as well Checked it on ALL servers just to be sure. ~J From rmeggins at redhat.com Fri May 15 15:59:12 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 09:59:12 -0600 Subject: [Freeipa-users] more replication issues In-Reply-To: <81D0E7EE-1034-4BF8-AFAF-EAC920ABB4F3@gmail.com> References: <55537060.2060502@gmail.com> <5553726D.70505@redhat.com> <55537625.4070701@gmail.com> <55537817.9010904@redhat.com> <55537D10.4000208@gmail.com> <5555CAA9.4070406@redhat.com> <5555EA5A.1070200@gmail.com> <5555FB59.3010903@redhat.com> <81D0E7EE-1034-4BF8-AFAF-EAC920ABB4F3@gmail.com> Message-ID: <555617D0.6060001@redhat.com> On 05/15/2015 09:53 AM, Janelle wrote: >> On May 15, 2015, at 08:57, Ludwig Krispenz wrote: >> >> >>> On 05/15/2015 02:45 PM, Janelle wrote: >>>> On 5/15/15 3:30 AM, Ludwig Krispenz wrote: >>>> >>>>> On 05/13/2015 06:34 PM, Janelle wrote: >>>>>> On 5/13/15 9:13 AM, Rich Megginson wrote: >>>>>>> On 05/13/2015 10:04 AM, Janelle wrote: >>>>>>>> On 5/13/15 8:49 AM, Rich Megginson wrote: >>>>>>>>> On 05/13/2015 09:40 AM, Janelle wrote: >>>>>>>>> Recently I started seeing these crop up across my servers: >>>>>>>>> >>>>>>>>> slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) >>>>>>>> Does that entry exist? >>>>>>>> >>>>>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b "cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config" >>>>>>>> >>>>>>>> Does the parent exist? >>>>>>>> >>>>>>>> ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b "ou=csusers,cn=config" >>>>>>> I am finding that there does seem to be a relation to the above error and a possible CSN issue: >>>>>>> >>>>>>> Can't locate CSN 555131e5000200190000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. >>>>>>> >>>>>>> I guess what concerns me is what could be causing this. We don't do a lot of changes all the time. >>>>>>> >>>>>>> And in answer to the question above - we seem to have last the agreement somehow: >>>>>>> >>>>>>> No such object (32) >>>>>>> >>>>>> Is there a DEL operation in the access log for "cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"? >>>>>> >>>>>> maybe something like >>>>>> >>>>>> # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication Manager" >>>>>> >>>>> nope -- none of the servers have it. >>>> your original message is very clear: >>>> >>>> could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) >>>> >>>> this means that you have replication agreement wth SIMPLE auth which uses a >>>> nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config >>>> >>>> which does not exist on the target server of the agreement. Now you say it was never deleted, so it was probably never added, but used in the replication agreements. How do you manage and setup replication agreements ? >>>> >>> All replicas are configred simply: >>> >>> ipa-replica-prepare hostname... >>> scp .. >>> ipa-replica-install --no-ntp --setup-ca Replica-file >>> >>> That is it. NTP is not set because internal NTP servers are used. All replicas are CA replicas for safety (no certs are managed) >> ok, I was a bit puzzled because ipa uses ldapprincipals and gssapi for the main suffix replication. >> But I just verified that after ipa-replica-install --setup-ca CA replication is setup with users in ou=csusers,cn=config and uses it as replica binddn, I have no idea why it would disappear. >> >> when Rich asked to search for a DEL, did you check this on the server that logged the message or on the endpoint of the replication agreement (it should be there), and you may have to check in the rotated access logs access. as well > Checked it on ALL servers just to be sure. > > ~J > If it is present at some point, then is missing, it must be some internal operation that is removing it. Please enable access logging of internal operations: ldapmodify -x -h consumer.host -D "cn=directory manager" -w "password" < Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of but if ssh is set to match on then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From lslebodn at redhat.com Fri May 15 19:44:31 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 15 May 2015 21:44:31 +0200 Subject: [Freeipa-users] username case sensitivity In-Reply-To: <9cfa2752940f4897b3cad87232ab8952@TCCCORPEXCH02.TCC.local> References: <9cfa2752940f4897b3cad87232ab8952@TCCCORPEXCH02.TCC.local> Message-ID: <20150515194431.GA1242@mail.corp.redhat.com> On (15/05/15 17:27), Andy Thompson wrote: >Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of but if ssh is set to match on then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. > IPA domain is by default case sensitive. So You will not change anything if you put "case_sensitive = true" into domain section of sssd.conf. But SSSD will create subdomains for each AD domain. It is different id_provider therefore different default values are used for subdomains and for AD provider it is case *insensitive* by default. Currently there's no way how to change it for subdomains (AD trusted domains) LS From nathan at nathanpeters.com Fri May 15 20:44:07 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 15 May 2015 13:44:07 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <5555FE31.6060202@redhat.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> Message-ID: <9aa7cec394c2cc20754bf2018cd5dfdf.squirrel@webmail.nathanpeters.com> > On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>>> supersecretpassword --passsync supersecretpassword --cacert >>>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>>> Directory Manager password: >>>> >>>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to >>>> certificate >>>> database for ipadc1.ipadomain.net >>>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>>> The user for the Windows PassSync service is >>>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>>> Windows PassSync system account exists, not resetting password >>>> ipa: INFO: Added new sync agreement, waiting for it to become ready . >>>> . >>>> . >>>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>>> error: Connect error: start: 0: end: 0 >>>> ipa: INFO: Agreement is ready, starting replication . . . >>>> Starting replication, please wait until this has completed. >>>> >>>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>>> error: >>>> Connect error] >>> Have you tried using ldapsearch to verify the connection? >>> >>> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ >>> -h >>> addc2.test.mycompany.net -D "cn=ad >>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>> "objectclass=*" >>> >>> and/or >>> >>> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL >>> -ZZ -h addc2.test.mycompany.net -D "cn=ad >>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>> "objectclass=*" >>> >> Both commands give the same successful result. I don't think it's a >> problem with the credentials because I was able to generate different >> error messages during the attempted sync setup if I intentionally gave a >> bad password or username. > > Ok. Have you tried enabling the replication log level? > > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > After doing that and poking around in /var/log/dirsrv/slapd-IPADOMAIN-NET/errors I found this : [15/May/2015:20:27:17 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [15/May/2015:20:27:17 +0000] NSMMReplicationPlugin - windows sync - agmt="cn=meToaddc2.test.mycompany.net" (addc2:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.) So it's complaining that it doesn't recognize the certificate that was signed by my AD certificate authority as suggested in here : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/Setting_up_Active_Directory.html#ad-ca-req I copied the certificate to my server though and created the hashes just like the manual said. The only issue I had was the directions here : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/managing-sync-agmt.html tell you to go to my network places but that didn't exist on my server. I did it through start menu -> administrative tools -> certification authority. The rest of double clicking on the cert and going to the details tab and copy to file was the same though. So how do I get FreeIPA to not choke up on the self signed cert? From rmeggins at redhat.com Fri May 15 20:49:31 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 14:49:31 -0600 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <9aa7cec394c2cc20754bf2018cd5dfdf.squirrel@webmail.nathanpeters.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> <9aa7cec394c2cc20754bf2018cd5dfdf.squirrel@webmail.nathanpeters.com> Message-ID: <55565BDB.5030808@redhat.com> On 05/15/2015 02:44 PM, nathan at nathanpeters.com wrote: >> On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>>>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>>>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>>>> supersecretpassword --passsync supersecretpassword --cacert >>>>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>>>> Directory Manager password: >>>>> >>>>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to >>>>> certificate >>>>> database for ipadc1.ipadomain.net >>>>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>>>> The user for the Windows PassSync service is >>>>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>>>> Windows PassSync system account exists, not resetting password >>>>> ipa: INFO: Added new sync agreement, waiting for it to become ready . >>>>> . >>>>> . >>>>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>>>> error: Connect error: start: 0: end: 0 >>>>> ipa: INFO: Agreement is ready, starting replication . . . >>>>> Starting replication, please wait until this has completed. >>>>> >>>>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>>>> error: >>>>> Connect error] >>>> Have you tried using ldapsearch to verify the connection? >>>> >>>> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ >>>> -h >>>> addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>>> and/or >>>> >>>> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL >>>> -ZZ -h addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>> Both commands give the same successful result. I don't think it's a >>> problem with the credentials because I was able to generate different >>> error messages during the attempted sync setup if I intentionally gave a >>> bad password or username. >> Ok. Have you tried enabling the replication log level? >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting >> > After doing that and poking around in > /var/log/dirsrv/slapd-IPADOMAIN-NET/errors I found this : > > [15/May/2015:20:27:17 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [15/May/2015:20:27:17 +0000] NSMMReplicationPlugin - windows sync - > agmt="cn=meToaddc2.test.mycompany.net" (addc2:389): Replication bind with > SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's > Certificate issuer is not recognized.) > > So it's complaining that it doesn't recognize the certificate that was > signed by my AD certificate authority as suggested in here : > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/Setting_up_Active_Directory.html#ad-ca-req > > I copied the certificate Which certificate? The CA cert or the server cert? You need the CA cert, not the server cert. > to my server though and created the hashes just > like the manual said. "created the hashes"? There is nothing in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/Setting_up_Active_Directory.html#ad-ca-req about creating any hashes. > > The only issue I had was the directions here : > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/managing-sync-agmt.html > tell you to go to my network places but that didn't exist on my server. I > did it through start menu -> administrative tools -> certification > authority. The rest of double clicking on the cert and going to the > details tab and copy to file was the same though. Was it the CA cert or the server cert? You need the CA cert, not the server cert. > > So how do I get FreeIPA to not choke up on the self signed cert? > From nathan at nathanpeters.com Fri May 15 21:09:26 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 15 May 2015 14:09:26 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <5555FE31.6060202@redhat.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> Message-ID: <14c073ed7f8f0e14d6ce8650bef6c025.squirrel@webmail.nathanpeters.com> > On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>>> supersecretpassword --passsync supersecretpassword --cacert >>>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>>> Directory Manager password: >>>> >>>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to >>>> certificate >>>> database for ipadc1.ipadomain.net >>>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>>> The user for the Windows PassSync service is >>>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>>> Windows PassSync system account exists, not resetting password >>>> ipa: INFO: Added new sync agreement, waiting for it to become ready . >>>> . >>>> . >>>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>>> error: Connect error: start: 0: end: 0 >>>> ipa: INFO: Agreement is ready, starting replication . . . >>>> Starting replication, please wait until this has completed. >>>> >>>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>>> error: >>>> Connect error] >>> Have you tried using ldapsearch to verify the connection? >>> >>> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ >>> -h >>> addc2.test.mycompany.net -D "cn=ad >>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>> "objectclass=*" >>> >>> and/or >>> >>> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL >>> -ZZ -h addc2.test.mycompany.net -D "cn=ad >>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>> "objectclass=*" >>> >> Both commands give the same successful result. I don't think it's a >> problem with the credentials because I was able to generate different >> error messages during the attempted sync setup if I intentionally gave a >> bad password or username. > > Ok. Have you tried enabling the replication log level? > > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting Ok, that helped a lot. I got this fixed now. Because the manual tells you to export the cert using a way that doesn't work on newer versions of windows, I tried to improvise and my first attempt exported the wrong cert. The correct way is to go to mmc.exe and add the certificates snap-in. Then go to personal certificates store for the machine account and export the one that has -CA at the end of it in the issued to column. Now that the correct certificate was exported, replication succeeded. The docs should be updated though to reflect the proper way to export. From rmeggins at redhat.com Fri May 15 22:10:10 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 16:10:10 -0600 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <14c073ed7f8f0e14d6ce8650bef6c025.squirrel@webmail.nathanpeters.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> <14c073ed7f8f0e14d6ce8650bef6c025.squirrel@webmail.nathanpeters.com> Message-ID: <55566EC2.5080006@redhat.com> On 05/15/2015 03:09 PM, nathan at nathanpeters.com wrote: >> On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>>>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>>>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>>>> supersecretpassword --passsync supersecretpassword --cacert >>>>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>>>> Directory Manager password: >>>>> >>>>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to >>>>> certificate >>>>> database for ipadc1.ipadomain.net >>>>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>>>> The user for the Windows PassSync service is >>>>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>>>> Windows PassSync system account exists, not resetting password >>>>> ipa: INFO: Added new sync agreement, waiting for it to become ready . >>>>> . >>>>> . >>>>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>>>> error: Connect error: start: 0: end: 0 >>>>> ipa: INFO: Agreement is ready, starting replication . . . >>>>> Starting replication, please wait until this has completed. >>>>> >>>>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>>>> error: >>>>> Connect error] >>>> Have you tried using ldapsearch to verify the connection? >>>> >>>> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ >>>> -h >>>> addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>>> and/or >>>> >>>> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL >>>> -ZZ -h addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>> Both commands give the same successful result. I don't think it's a >>> problem with the credentials because I was able to generate different >>> error messages during the attempted sync setup if I intentionally gave a >>> bad password or username. >> Ok. Have you tried enabling the replication log level? >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > Ok, that helped a lot. I got this fixed now. Because the manual tells > you to export the cert using a way that doesn't work on newer versions of > windows, I tried to improvise and my first attempt exported the wrong > cert. > > The correct way is to go to mmc.exe and add the certificates snap-in. > Then go to personal certificates store for the machine account and export > the one that has -CA at the end of it in the issued to column. > > Now that the correct certificate was exported, replication succeeded. The > docs should be updated though to reflect the proper way to export. > I will file a doc bug. What version of Windows are you using that does not have the correct instructions? From rmeggins at redhat.com Fri May 15 23:13:16 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 May 2015 17:13:16 -0600 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <14c073ed7f8f0e14d6ce8650bef6c025.squirrel@webmail.nathanpeters.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> <14c073ed7f8f0e14d6ce8650bef6c025.squirrel@webmail.nathanpeters.com> Message-ID: <55567D8C.4070008@redhat.com> On 05/15/2015 03:09 PM, nathan at nathanpeters.com wrote: >> On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>>>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>>>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>>>> supersecretpassword --passsync supersecretpassword --cacert >>>>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>>>> Directory Manager password: >>>>> >>>>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to >>>>> certificate >>>>> database for ipadc1.ipadomain.net >>>>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>>>> The user for the Windows PassSync service is >>>>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>>>> Windows PassSync system account exists, not resetting password >>>>> ipa: INFO: Added new sync agreement, waiting for it to become ready . >>>>> . >>>>> . >>>>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>>>> error: Connect error: start: 0: end: 0 >>>>> ipa: INFO: Agreement is ready, starting replication . . . >>>>> Starting replication, please wait until this has completed. >>>>> >>>>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>>>> error: >>>>> Connect error] >>>> Have you tried using ldapsearch to verify the connection? >>>> >>>> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ >>>> -h >>>> addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>>> and/or >>>> >>>> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL >>>> -ZZ -h addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>> Both commands give the same successful result. I don't think it's a >>> problem with the credentials because I was able to generate different >>> error messages during the attempted sync setup if I intentionally gave a >>> bad password or username. >> Ok. Have you tried enabling the replication log level? >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > Ok, that helped a lot. I got this fixed now. Because the manual tells > you to export the cert using a way that doesn't work on newer versions of > windows, I tried to improvise and my first attempt exported the wrong > cert. > > The correct way is to go to mmc.exe and add the certificates snap-in. > Then go to personal certificates store for the machine account and export > the one that has -CA at the end of it in the issued to column. > > Now that the correct certificate was exported, replication succeeded. The > docs should be updated though to reflect the proper way to export. > https://bugzilla.redhat.com/show_bug.cgi?id=1222161 Please add yourself to the bug and provide any additional information. From notify.sina at gmail.com Sat May 16 05:00:13 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sat, 16 May 2015 06:00:13 +0100 Subject: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot Message-ID: Hi! I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, with the following versions: libipa_hbac-1.11.6-30.el6_6.4.x86_64 ipa-server-selinux-3.0.0-42.el6.x86_64 libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 ipa-admintools-3.0.0-42.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-3.0.0-42.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 ipa-server-3.0.0-42.el6.x86_64 ipa-python-3.0.0-42.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch sssd-ipa-1.11.6-30.el6_6.4.x86_64 I noticed the replica did not seem to be in sync with the primary IPA server, as login requests to ipa clients using the replica for domain authentication failed with "Too many authentication failures for user UNKNOWN". I forced a sync with the primary server and rebooted the replica afterwards. Now the replica is back up, but when I run "ipactl status", only dirsrv is running: # ipactl status Directory Service: RUNNING No other service shows up. I also tried editing /etc/krb5.conf to change the [realms] information to point to the primary server, but while I can now kinit admin, nothing else works. Please how can I fix this problem? Please what can I do fix this? From notify.sina at gmail.com Sat May 16 10:18:41 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sat, 16 May 2015 11:18:41 +0100 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Message-ID: Hi Group, I'm attempting again to rebuild and reinstall a troublesome replica. I have two freshly upgraded RHEL6.6 IdM servers. Problem is when I try to run createreplica I have this output: ipa-replica-prepare services01.ours.com --ip-address 192.168.2.40 Directory Manager (existing master) password: Preparing replica for services01.ours.com from services.ours.com Creating SSL certificate for the Directory Server Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) I have check the different threads where I find this same error but all symlinks are correctly defined. Please can someone kindly guide a noob in the right path? From notify.sina at gmail.com Sat May 16 10:19:41 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sat, 16 May 2015 11:19:41 +0100 Subject: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot In-Reply-To: References: Message-ID: Please help me. I am in dire straits, this is the linchpin of our network and we are suffering. On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi wrote: > Hi! > > I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, > with the following versions: > libipa_hbac-1.11.6-30.el6_6.4.x86_64 > ipa-server-selinux-3.0.0-42.el6.x86_64 > libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 > ipa-admintools-3.0.0-42.el6.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > ipa-client-3.0.0-42.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 > device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 > ipa-server-3.0.0-42.el6.x86_64 > ipa-python-3.0.0-42.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > sssd-ipa-1.11.6-30.el6_6.4.x86_64 > > > I noticed the replica did not seem to be in sync with the primary IPA > server, as login requests to ipa clients using the replica for domain > authentication failed with > "Too many authentication failures for user UNKNOWN". > I forced a sync with the primary server and rebooted the replica afterwards. > Now the replica is back up, but when I run "ipactl status", only > dirsrv is running: > # ipactl status > Directory Service: RUNNING > > No other service shows up. I also tried editing /etc/krb5.conf to > change the [realms] information to point to the primary server, but > while I can now kinit admin, > nothing else works. > > Please how can I fix this problem? > > Please what can I do fix this? From gjn at gjn.priv.at Sat May 16 11:04:43 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sat, 16 May 2015 13:04:43 +0200 Subject: [Freeipa-users] ipa-client-install --request-cert ERROR Message-ID: <12565440.h3nqUzHW6g@techz> Hello, When I install a IPA client (Centos 7.1) I have this Error in the log. freeipa ERROR certmonger request for host certificate failed Is there a way to become this Certificate back ? I am nearly new on freeIPA and have mach problems :-(. Thanks for the help, -- mit freundlichen Gr?ssen / best regards, G?nther J. Niederwimmer From abokovoy at redhat.com Sat May 16 12:09:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 16 May 2015 15:09:27 +0300 Subject: [Freeipa-users] ipa-client-install --request-cert ERROR In-Reply-To: <12565440.h3nqUzHW6g@techz> References: <12565440.h3nqUzHW6g@techz> Message-ID: <20150516120927.GV5152@redhat.com> On Sat, 16 May 2015, G?nther J. Niederwimmer wrote: >Hello, > >When I install a IPA client (Centos 7.1) I have this Error in the log. > >freeipa ERROR certmonger request for host certificate failed > >Is there a way to become this Certificate back ? > >I am nearly new on freeIPA and have mach problems :-(. Since FreeIPA 4.1 host certificate is not created by default and failing to fetch it is not an issue. The certificate is not used anywhere. -- / Alexander Bokovoy From mail at willsheldon.com Sat May 16 18:29:31 2015 From: mail at willsheldon.com (Will Sheldon) Date: Sat, 16 May 2015 11:29:31 -0700 Subject: [Freeipa-users] Problems with failed upgrade: groups are not created In-Reply-To: <55546059.60003@redhat.com> References: <55546059.60003@redhat.com> Message-ID: Thanks for the reply Martin. Turns out that there was no problem at all, a minor configuration mistake (nested a group inside the wrong parent) led us down a rabbit hole. Our failed upgrade happened on the same day our 1000th group was created. Using the LDAP browser plugin for Eclipse the default search query limit is 1000? It took a while to work that out, needless to say we all feel a little silly and a little wiser now :) ? Will Sheldon On May 14, 2015 at 1:44:15 AM, Martin Basti (mbasti at redhat.com) wrote: On 14/05/15 01:50, Will Sheldon wrote: Hello everyone :) We are seeing some strange behavior (created groups don't exist) and I really hope someone can lend some advice... We installed v 3.0 some time ago, and tried an upgrade to 3.3 which was aborted before completion, however I believe the schema was updated. Recently we attempted to upgrade to 4.1, but encountered some issues with the upgrade; replication failed : from the install log (before schema update, so server was running 3.3 schema): =======================> Done configuring ipa-otpd. Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR??? Add failure attribute "cn" not allowed =======================< After that we tried updating the schema, and we now get this error (we have log file captures for this): =======================> [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 131 seconds elapsed Update in progress yet not in progress [vanipa.foo.com] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] ? [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ========================< which seems to be referring to this bit of the log: =======================> 2015-04-21T19:18:48Z DEBUG Traceback (most recent call last): ? File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation ??? run_step(full_msg, method) =======================< Since then we have a somewhat strange issue where new groups that are added using the web interface and ipa CLI command interface are created in the compat tree, but not in the cn=hostgroups,cn=accounts tree, even though ADD operations appear to complete successfully (slapd log output below) =======================> [13/May/2015:23:13:58 +0000] conn=7120402 op=4 ADD dn="cn=p-test-100,cn=hostgroups,cn=accounts,dc=foo,dc=com" [13/May/2015:23:13:58 +0000] conn=2616653 op=3660217 SRCH base="idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660217 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660218 SRCH base="idnsName=bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660218 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660219 SRCH base="idnsName=vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660219 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660220 SRCH base="idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660220 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660221 SRCH base="idnsName=bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660221 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=2616653 op=3660222 SRCH base="idnsName=vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [13/May/2015:23:13:58 +0000] conn=2616653 op=3660222 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +0000] conn=7120402 op=4 RESULT err=0 tag=105 nentries=0 etime=0 csn=5553e3f8000100040000 =======================< Which is consistent with the slapd log during the upgrade: [21/Apr/2015:19:18:43 +0000] NSACLPlugin - The ACL target cn=hr,cn=groups,cn=accounts,dc=foo,dc=com does not exist -- Kind regards, Will Sheldon Hello, can you find in ipaserver-install.log more details about this error? ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR??? Add failure attribute "cn" not allowed Martin -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Sat May 16 20:24:25 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 16 May 2015 22:24:25 +0200 Subject: [Freeipa-users] host usercertificate attribute Message-ID: hi, If I retrieve the usercertificate attribute for host objects I get some gibberish. How can I decode the info I get from ldapsearch? The command I used was: ldapsearch -b "cn=computers,cn=accounts,dc=sub,dc=domain,dc=tldl" -t -Y gssapi -Z -h kdc01.sub.dmain.tld usercertificate which creates individual files on /tmp with the info looking like this: ?0??*?H????0 0;10U ......... Using the apache directory studio ldap browser I can see the certificate information (subject, validity, etc), so it must be possible. Is it base64 encoding? TIA, -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Sat May 16 22:06:42 2015 From: nathan at nathanpeters.com (Nathan Peters) Date: Sat, 16 May 2015 15:06:42 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <55567D8C.4070008@redhat.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> <14c073ed7f8f0e14d6ce8650bef6c025.squirrel@webmail.nathanpeters.com> <55567D8C.4070008@redhat.com> Message-ID: <59310E142C8544ACB273E946B7121A98@Azul> I have updated the bug report you filed below. The issue was that the instructions would only work in Windows Server 2003 because My Network Places was removed in 2008 and above. Since the manual clearly states that the AD sync is to be performed with server 2008 / 2012 only it made no sense to give instructions for an incompatible version of windows. I have added to the ticket 2 methods to get the *correct* certificate that will work in both server 2008 r2 and server 2012 r2. On 05/15/2015 03:09 PM, nathan at nathanpeters.com wrote: >> On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>>>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>>>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>>>> supersecretpassword --passsync supersecretpassword --cacert >>>>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>>>> Directory Manager password: >>>>> >>>>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to >>>>> certificate >>>>> database for ipadc1.ipadomain.net >>>>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>>>> The user for the Windows PassSync service is >>>>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>>>> Windows PassSync system account exists, not resetting password >>>>> ipa: INFO: Added new sync agreement, waiting for it to become ready . >>>>> . >>>>> . >>>>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP >>>>> error: Connect error: start: 0: end: 0 >>>>> ipa: INFO: Agreement is ready, starting replication . . . >>>>> Starting replication, please wait until this has completed. >>>>> >>>>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>>>> error: >>>>> Connect error] >>>> Have you tried using ldapsearch to verify the connection? >>>> >>>> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ >>>> -h >>>> addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>>> and/or >>>> >>>> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL >>>> -ZZ -h addc2.test.mycompany.net -D "cn=ad >>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>> "supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net" >>>> "objectclass=*" >>>> >>> Both commands give the same successful result. I don't think it's a >>> problem with the credentials because I was able to generate different >>> error messages during the attempted sync setup if I intentionally gave a >>> bad password or username. >> Ok. Have you tried enabling the replication log level? >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > Ok, that helped a lot. I got this fixed now. Because the manual tells > you to export the cert using a way that doesn't work on newer versions of > windows, I tried to improvise and my first attempt exported the wrong > cert. > > The correct way is to go to mmc.exe and add the certificates snap-in. > Then go to personal certificates store for the machine account and export > the one that has -CA at the end of it in the issued to column. > > Now that the correct certificate was exported, replication succeeded. The > docs should be updated though to reflect the proper way to export. > https://bugzilla.redhat.com/show_bug.cgi?id=1222161 Please add yourself to the bug and provide any additional information. From nathan at nathanpeters.com Sat May 16 22:08:47 2015 From: nathan at nathanpeters.com (Nathan Peters) Date: Sat, 16 May 2015 15:08:47 -0700 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <55565BDB.5030808@redhat.com> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> <9aa7cec394c2cc20754bf2018cd5dfdf.squirrel@webmail.nathanpeters.com> <55565BDB.5030808@redhat.com> Message-ID: <43A3881601B545B4B825E2BDC947E770@Azul> >"created the hashes"? There is nothing in >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/Setting_up_Active_Directory.html#ad-ca-req >about creating any hashes. Sorry I should have been more specific. I mean updated the hash symlinks which is in 7.5.1 (7) here : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/managing-sync-agmt.html From natxo.asenjo at gmail.com Sun May 17 14:01:36 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sun, 17 May 2015 16:01:36 +0200 Subject: [Freeipa-users] host usercertificate attribute In-Reply-To: References: Message-ID: On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo wrote: > hi, > > If I retrieve the usercertificate attribute for host objects I get some > gibberish. > > How can I decode the info I get from ldapsearch? > maybe there is a way to feed that to openssl. What I ended up doing was using Perl and Crypt::X509 and I can see all the certificate elements. -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sun May 17 21:23:21 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 17 May 2015 23:23:21 +0200 Subject: [Freeipa-users] username case sensitivity In-Reply-To: <20150515194431.GA1242@mail.corp.redhat.com> References: <9cfa2752940f4897b3cad87232ab8952@TCCCORPEXCH02.TCC.local> <20150515194431.GA1242@mail.corp.redhat.com> Message-ID: <20150517212321.GA15861@hendrix.redhat.com> On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: > On (15/05/15 17:27), Andy Thompson wrote: > >Is there a way to enforce case sensitivity for trusted AD users? I am > trying to use username for ssh chroots and I can authenticated with any > case combination of but if ssh is set to match on > then the chroot is not enforced and the user is dropped to their usual > home directory. I found a case_sensitive option for sssd but it does not > seem to have any affect. Running RHEL6.6 clients. > > > > IPA domain is by default case sensitive. > So You will not change anything if you put "case_sensitive = true" into domain > section of sssd.conf. > > But SSSD will create subdomains for each AD domain. It is different id_provider > therefore different default values are used for subdomains and for AD provider > it is case *insensitive* by default. > > Currently there's no way how to change it for subdomains (AD trusted domains) > What are you using for the SSH matching? The way the case insensitiveness is implemented in SSSD is that all usernames are forcibly lowercased on output, so as long as SSH uses the standard NSS calls, you should be good with using the lowecase usernames.. From Andy.Thompson at e-tcc.com Sun May 17 22:26:45 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Sun, 17 May 2015 22:26:45 +0000 Subject: [Freeipa-users] username case sensitivity In-Reply-To: <20150517212321.GA15861@hendrix.redhat.com> References: <9cfa2752940f4897b3cad87232ab8952@TCCCORPEXCH02.TCC.local> <20150515194431.GA1242@mail.corp.redhat.com> <20150517212321.GA15861@hendrix.redhat.com> Message-ID: <002b3de875284413aef030b385c9c0c0@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Sunday, May 17, 2015 5:23 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] username case sensitivity > > On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: > > On (15/05/15 17:27), Andy Thompson wrote: > > >Is there a way to enforce case sensitivity for trusted AD users? I > > >am > > trying to use username for ssh chroots and I can authenticated with > > any case combination of but if ssh is set to match on > > then the chroot is not enforced and the user is dropped to > > their usual home directory. I found a case_sensitive option for sssd but it > does not > > seem to have any affect. Running RHEL6.6 clients. > > > > > > > IPA domain is by default case sensitive. > > So You will not change anything if you put "case_sensitive = true" > > into domain section of sssd.conf. > > > > But SSSD will create subdomains for each AD domain. It is different > > id_provider therefore different default values are used for subdomains > > and for AD provider it is case *insensitive* by default. > > > > Currently there's no way how to change it for subdomains (AD trusted > > domains) > > > > What are you using for the SSH matching? The way the case insensitiveness is > implemented in SSSD is that all usernames are forcibly lowercased on output, > so as long as SSH uses the standard NSS calls, you should be good with using > the lowecase usernames.. > They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. -andy From janellenicole80 at gmail.com Sun May 17 23:49:42 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sun, 17 May 2015 16:49:42 -0700 Subject: [Freeipa-users] 4.1.4 and OTP In-Reply-To: <1430228679.4592.4.camel@redhat.com> References: <553123D9.5090800@gmail.com> <55313A9B.2030408@redhat.com> <553140DA.7020001@gmail.com> <55316ABF.1000606@redhat.com> <55317279.3010107@gmail.com> <55319908.60109@redhat.com> <8898FB62-D73E-4D51-BE4B-2C0F6A903970@gmail.com> <5531AC8D.3070900@redhat.com> <5531CDAF.1080506@gmail.com> <1430228679.4592.4.camel@redhat.com> Message-ID: <55592916.3080404@gmail.com> On 4/28/15 6:44 AM, Nathaniel McCallum wrote: > On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: >> On 4/17/15 5:59 PM, Dmitri Pal wrote: >>> On 04/17/2015 08:07 PM, Janelle wrote: >>>> >>>> >>>> >>>> On Apr 17, 2015, at 16:36, Dmitri Pal wrote: >>>> for shorter thread.... >>>> Simple. And my test made it simple. >>>> Stand up new vm running fc21/freeipa. >>>> Configure user. >>>> Add password. >>>> Add token. >>>> >>>> Login to the vm with the user created using password. Kerberos >>>> ticket assigned, all is well. >>>> >>>> Login to web interface with admin. Change user to OTP only. >>>> Go to web UI and click sync OTP. >>>> Enter username, password and 2 OTP sequences. Click sync. Error >>>> appears. >>>> >>>> Now, ssh to same vm using OTP username. Enter password + OTP >>>> value. >>>> Login successful. >>> I can reproduce this issue with demo instance. >>> I will file a bug later today. >>> I think it is a bug with sync. >>> Which token do you use time based or event based? >> TOTP... >> >> Hmm, makes me wonder - with HOTP fail the same? Off to try it. > This should just affect TOTP. I have posted a patch that should fix > this problem. Are you able to test it? > > https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html > > Sorry - I just got around to testing this and it does resolve the problem - HOWEVER, you took away the ability to "Name" the tokens? They are now "assigned" unique IDs?? Was this intentional? ~J From jhrozek at redhat.com Mon May 18 08:07:08 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 18 May 2015 10:07:08 +0200 Subject: [Freeipa-users] username case sensitivity In-Reply-To: <002b3de875284413aef030b385c9c0c0@TCCCORPEXCH02.TCC.local> References: <9cfa2752940f4897b3cad87232ab8952@TCCCORPEXCH02.TCC.local> <20150515194431.GA1242@mail.corp.redhat.com> <20150517212321.GA15861@hendrix.redhat.com> <002b3de875284413aef030b385c9c0c0@TCCCORPEXCH02.TCC.local> Message-ID: <20150518080708.GE15861@hendrix.redhat.com> On Sun, May 17, 2015 at 10:26:45PM +0000, Andy Thompson wrote: > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > bounces at redhat.com] On Behalf Of Jakub Hrozek > > Sent: Sunday, May 17, 2015 5:23 PM > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] username case sensitivity > > > > On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: > > > On (15/05/15 17:27), Andy Thompson wrote: > > > >Is there a way to enforce case sensitivity for trusted AD users? I > > > >am > > > trying to use username for ssh chroots and I can authenticated with > > > any case combination of but if ssh is set to match on > > > then the chroot is not enforced and the user is dropped to > > > their usual home directory. I found a case_sensitive option for sssd but it > > does not > > > seem to have any affect. Running RHEL6.6 clients. > > > > > > > > > > IPA domain is by default case sensitive. > > > So You will not change anything if you put "case_sensitive = true" > > > into domain section of sssd.conf. > > > > > > But SSSD will create subdomains for each AD domain. It is different > > > id_provider therefore different default values are used for subdomains > > > and for AD provider it is case *insensitive* by default. > > > > > > Currently there's no way how to change it for subdomains (AD trusted > > > domains) > > > > > > > What are you using for the SSH matching? The way the case insensitiveness is > > implemented in SSSD is that all usernames are forcibly lowercased on output, > > so as long as SSH uses the standard NSS calls, you should be good with using > > the lowecase usernames.. > > > > They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. What is "they" ? I guess not SSSD but grabbing the data directly from LDAP? From mkosek at redhat.com Mon May 18 09:10:06 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 11:10:06 +0200 Subject: [Freeipa-users] Securing IPA Redux In-Reply-To: <7B765750-7688-4643-B86E-27F40E8582E0@gmail.com> References: <7B765750-7688-4643-B86E-27F40E8582E0@gmail.com> Message-ID: <5559AC6E.5060607@redhat.com> On 05/15/2015 01:33 PM, Brian Topping wrote: > In the (apparently) first message to the list in 2014, https://www.redhat.com/archives/freeipa-users/2014-January/msg00000.html addressed questions about securing IPA and I don't see much other talk about it. Now that 4.x is prevalent, I wanted to bring it up again. This is the default by design. However, note that in FreeIPA 4.0+ you can change that default (permission-mod) and let users or some of the user attributes be only shown for authenticated users. https://www.freeipa.org/page/V4/Permissions_V2 So, from my POV, this is not a flaw. > I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted filesystems) to be a part of the domain. I believe this means that I need to expose Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult to force TLS (https://blog.routedlogic.net/?p=119 ) and maybe that's a bad idea under IPA for reasons I thought I'd ask here about. Last year's thread also referenced https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html and I thought I would check to see if that's still necessary under 4.x. 389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1): https://fedorahosted.org/freeipa/ticket/4653 This is an nmap test against the FreeIPA public demo (4.1.x): $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99) Host is up (0.19s latency). PORT STATE SERVICE 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds > Setting up the firewall to allow cloud networks in is always an option, but if I can get a secure IPA setup going, it would also allow road warriors to kinit and use their credentials for configured intranet sites without having to turn on the VPN (which can really slow things down from remote parts of the globe). BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to offer Kerberos-over-HTTP functionality by default: https://fedorahosted.org/freeipa/ticket/4801 Even now, it can be manually configured. This is what GNOME used: https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ So, if I am reading my notes correctly, there should be no blockers in using FreeIPA in your environment. If yes, please let me know. Martin From mkosek at redhat.com Mon May 18 09:15:56 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 11:15:56 +0200 Subject: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot In-Reply-To: References: Message-ID: <5559ADCC.8050001@redhat.com> On 05/16/2015 12:19 PM, Sina Owolabi wrote: > Please help me. I am in dire straits, this is the linchpin of our > network and we are suffering. I am sorry for delay in answering, but not many people here show up on the weekend. Comments below. > On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi wrote: >> Hi! >> >> I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, >> with the following versions: >> libipa_hbac-1.11.6-30.el6_6.4.x86_64 >> ipa-server-selinux-3.0.0-42.el6.x86_64 >> libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 >> ipa-admintools-3.0.0-42.el6.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-client-3.0.0-42.el6.x86_64 >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 >> device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 >> ipa-server-3.0.0-42.el6.x86_64 >> ipa-python-3.0.0-42.el6.x86_64 >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> sssd-ipa-1.11.6-30.el6_6.4.x86_64 >> >> >> I noticed the replica did not seem to be in sync with the primary IPA >> server, as login requests to ipa clients using the replica for domain >> authentication failed with >> "Too many authentication failures for user UNKNOWN". >> I forced a sync with the primary server and rebooted the replica afterwards. >> Now the replica is back up, but when I run "ipactl status", only >> dirsrv is running: >> # ipactl status >> Directory Service: RUNNING This is strange, try # ipactl restart see which services fail to start and see the logs they produce. >> No other service shows up. I also tried editing /etc/krb5.conf to >> change the [realms] information to point to the primary server, but >> while I can now kinit admin, >> nothing else works. >> >> Please how can I fix this problem? >> >> Please what can I do fix this? First things first. You need to first see if all service start and operate properly, if not, we need to see their logs in order to help or advise. Martin From mkosek at redhat.com Mon May 18 09:18:57 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 11:18:57 +0200 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: Message-ID: <5559AE81.9000907@redhat.com> On 05/16/2015 12:18 PM, Sina Owolabi wrote: > Hi Group, > > I'm attempting again to rebuild and reinstall a troublesome replica. I > have two freshly upgraded RHEL6.6 IdM servers. > > Problem is when I try to run createreplica I have this output: > > ipa-replica-prepare services01.ours.com --ip-address 192.168.2.40 > Directory Manager (existing master) password: > > Preparing replica for services01.ours.com from services.ours.com > Creating SSL certificate for the Directory Server > Certificate operation cannot be completed: Unable to communicate with > CMS (Not Found) It looks like CA is not reachable. Is CA on the machine where you run ipa-replica-manage? Or other machine? Is the CA running? (ipactl status) > > I have check the different threads where I find this same error but > all symlinks are correctly defined. > > Please can someone kindly guide a noob in the right path? > From mkosek at redhat.com Mon May 18 09:31:28 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 11:31:28 +0200 Subject: [Freeipa-users] 4.1.4 and OTP In-Reply-To: <55592916.3080404@gmail.com> References: <553123D9.5090800@gmail.com> <55313A9B.2030408@redhat.com> <553140DA.7020001@gmail.com> <55316ABF.1000606@redhat.com> <55317279.3010107@gmail.com> <55319908.60109@redhat.com> <8898FB62-D73E-4D51-BE4B-2C0F6A903970@gmail.com> <5531AC8D.3070900@redhat.com> <5531CDAF.1080506@gmail.com> <1430228679.4592.4.camel@redhat.com> <55592916.3080404@gmail.com> Message-ID: <5559B170.1040402@redhat.com> On 05/18/2015 01:49 AM, Janelle wrote: > On 4/28/15 6:44 AM, Nathaniel McCallum wrote: >> On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: >>> On 4/17/15 5:59 PM, Dmitri Pal wrote: >>>> On 04/17/2015 08:07 PM, Janelle wrote: >>>>> >>>>> >>>>> >>>>> On Apr 17, 2015, at 16:36, Dmitri Pal wrote: >>>>> > for shorter thread.... >>>>> Simple. And my test made it simple. >>>>> Stand up new vm running fc21/freeipa. >>>>> Configure user. >>>>> Add password. >>>>> Add token. >>>>> >>>>> Login to the vm with the user created using password. Kerberos >>>>> ticket assigned, all is well. >>>>> >>>>> Login to web interface with admin. Change user to OTP only. >>>>> Go to web UI and click sync OTP. >>>>> Enter username, password and 2 OTP sequences. Click sync. Error >>>>> appears. >>>>> >>>>> Now, ssh to same vm using OTP username. Enter password + OTP >>>>> value. >>>>> Login successful. >>>> I can reproduce this issue with demo instance. >>>> I will file a bug later today. >>>> I think it is a bug with sync. >>>> Which token do you use time based or event based? >>> TOTP... >>> >>> Hmm, makes me wonder - with HOTP fail the same? Off to try it. >> This should just affect TOTP. I have posted a patch that should fix >> this problem. Are you able to test it? >> >> https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html >> >> > Sorry - I just got around to testing this and it does resolve the problem - > HOWEVER, you took away the ability to "Name" the tokens? They are now > "assigned" unique IDs?? > > Was this intentional? It was, we track this (half-done) change in this ticket: https://fedorahosted.org/freeipa/ticket/4456 The main problem here is that user token names share the same name space and we thus do not want to create completely arbitrary names as they would collide. Applications like FreeOTP allow users to set own labels, so this is IMO the way how to add friendly names to the OTP tokens. Martin From Andy.Thompson at e-tcc.com Mon May 18 10:16:37 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Mon, 18 May 2015 10:16:37 +0000 Subject: [Freeipa-users] username case sensitivity In-Reply-To: <20150518080708.GE15861@hendrix.redhat.com> References: <9cfa2752940f4897b3cad87232ab8952@TCCCORPEXCH02.TCC.local> <20150515194431.GA1242@mail.corp.redhat.com> <20150517212321.GA15861@hendrix.redhat.com> <002b3de875284413aef030b385c9c0c0@TCCCORPEXCH02.TCC.local> <20150518080708.GE15861@hendrix.redhat.com> Message-ID: <277c549fbecf47fcac21b35bc146506f@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: Jakub Hrozek [mailto:jhrozek at redhat.com] > Sent: Monday, May 18, 2015 4:07 AM > To: Andy Thompson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] username case sensitivity > > On Sun, May 17, 2015 at 10:26:45PM +0000, Andy Thompson wrote: > > > -----Original Message----- > > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > > bounces at redhat.com] On Behalf Of Jakub Hrozek > > > Sent: Sunday, May 17, 2015 5:23 PM > > > To: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] username case sensitivity > > > > > > On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: > > > > On (15/05/15 17:27), Andy Thompson wrote: > > > > >Is there a way to enforce case sensitivity for trusted AD users? > > > > >I am > > > > trying to use username for ssh chroots and I can authenticated > > > > with any case combination of but if ssh is set to match > > > > on then the chroot is not enforced and the user is > > > > dropped to their usual home directory. I found a case_sensitive > > > > option for sssd but it > > > does not > > > > seem to have any affect. Running RHEL6.6 clients. > > > > > > > > > > > > > IPA domain is by default case sensitive. > > > > So You will not change anything if you put "case_sensitive = true" > > > > into domain section of sssd.conf. > > > > > > > > But SSSD will create subdomains for each AD domain. It is > > > > different id_provider therefore different default values are used > > > > for subdomains and for AD provider it is case *insensitive* by default. > > > > > > > > Currently there's no way how to change it for subdomains (AD > > > > trusted > > > > domains) > > > > > > > > > > What are you using for the SSH matching? The way the case > > > insensitiveness is implemented in SSSD is that all usernames are > > > forcibly lowercased on output, so as long as SSH uses the standard > > > NSS calls, you should be good with using the lowecase usernames.. > > > > > > > They were initially all in lower case and working when I tested and finalized > the setup. I passed the credentials off and they used mixed case and the > match stopped working. > > What is "they" ? I guess not SSSD but grabbing the data directly from LDAP? The match clauses in the sshd config were set to use lower case names. It is using sssd, just a regular ipa client installation. If I logged in using USERName insetad of username, the match clause did not work. -andy From tbordaz at redhat.com Mon May 18 12:04:27 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 18 May 2015 14:04:27 +0200 Subject: [Freeipa-users] Replication seems to begin but failed after 127 seconds ... In-Reply-To: References: <552E98C3.8020900@redhat.com> <552EBDEA.6040604@redhat.com> <552EDC2D.9070609@redhat.com> <552F00E1.2020006@redhat.com> <5530755B.1030403@redhat.com> <5555FBEA.8090005@redhat.com> <55560360.706@redhat.com> <55560979.50508@redhat.com> Message-ID: <5559D54B.4080408@redhat.com> On 05/15/2015 05:11 PM, James James wrote: > ok Rob. Thanks for your help. I will wait for the Scientific Linux 6.7 . Hi James, Unfortunately there is no workaround. This is a timing issue mostly seen when the master is more powerful than the consumer. If you are using VM you may try to get master/replica with nearly the same cpu/memory. thanks thierry > > Best. > > James > > 2015-05-15 16:58 GMT+02:00 Rich Megginson >: > > On 05/15/2015 08:46 AM, James James wrote: >> [root at ipa ~]# rpm -q 389-ds-base >> 389-ds-base-1.2.11.15-50.el6_6.x86_64 > > Ok. Looks like this is planned to be fixed in RHEL 6.7 with > version 389-ds-base-1.2.11.15-56.el6 > > I don't know if there are any workarounds. > > >> >> >> >> 2015-05-15 16:32 GMT+02:00 Rich Megginson > >: >> >> On 05/15/2015 08:22 AM, James James wrote: >>> I think that : >>> >>> Starting replication, please wait until this has completed. >>> Update in progress, 127 seconds elapsed >>> Update in progress yet not in progress >>> >>> >>> looks like a time error : >>> https://fedorahosted.org/freeipa/ticket/4756 >> >> That issue should have been fixed in 389-ds-base-1.3.3 >> branch. What version of 389-ds-base? rpm -q 389-ds-base >> >> >>> >>> 2015-05-15 16:00 GMT+02:00 Rich Megginson >>> >: >>> >>> On 05/15/2015 07:55 AM, James James wrote: >>>> Is it possible to change the nsds5ReplicaTimeout value >>>> to get rid of this timeout error ? >>> >>> What timeout error? >>> >>>> >>>> 2015-04-17 4:52 GMT+02:00 Rich Megginson >>>> >: >>>> >>>> On 04/15/2015 10:44 PM, James James wrote: >>>>> The ipareplica-install.log file in attachment ... >>>> >>>> Here are the pertinent bits: >>>> >>>> 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: >>>> localhost [389] timeout 300 >>>> 2015-04-15T15:06:32Z DEBUG flushing >>>> ldap://ipa.example.com:389 from SchemaCache >>>> 2015-04-15T15:06:32Z DEBUG retrieving schema for >>>> SchemaCache url=ldap://ipa.example.com:389 >>>> conn=>>> 0x484f4d0> >>>> 2015-04-15T15:06:32Z DEBUG flushing >>>> ldaps://ipa1.example.com:636 from SchemaCache >>>> 2015-04-15T15:06:32Z DEBUG retrieving schema for >>>> SchemaCache url=ldaps://ipa1.example.com:636 >>>> conn=>>> 0x4170290> >>>> 2015-04-15T15:08:44Z DEBUG Traceback (most recent >>>> call last): >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 382, in start_creation >>>> run_step(full_msg, method) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 372, in run_step >>>> method() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>>> line 368, in __setup_replica >>>> r_bindpw=self.dm_password) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>>> line 969, in setup_replication >>>> raise RuntimeError("Failed to start replication") >>>> RuntimeError: Failed to start replication >>>> >>>> 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: >>>> Failed to start replication >>>> >>>> The times are a little off, but I believe this >>>> corresponds to >>>> [15/Apr/2015:17:08:39 +0200] - import userRoot: >>>> Import complete. Processed 1539 entries in 126 >>>> seconds. (12.21 entries/sec) >>>> [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin >>>> - multimaster_be_state_change: replica >>>> dc=lix,dc=polytechnique,dc=fr is coming online; >>>> enabling replication >>>> >>>> I don't know why setup_replication is reporting an >>>> error if replication completed successfully. >>>> >>>> >>>>> >>>>> 2015-04-16 2:22 GMT+02:00 Rob Crittenden >>>>> >: >>>>> >>>>> Rich Megginson wrote: >>>>> > On 04/15/2015 02:58 PM, James James wrote: >>>>> >> Nothing on the replica .. maybye a process >>>>> on the master. How can I >>>>> >> check that ? >>>>> > >>>>> > I have no idea. But it seems highly >>>>> unlikely that a process on the >>>>> > master is able to shutdown a process on the >>>>> replica . . . >>>>> > >>>>> > I would say that there is some problem with >>>>> the ipa-replica-install not >>>>> > properly checking the status - see below: >>>>> > >>>>> >> >>>>> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson >>>>> >>>>> >> >>>> >>: >>>>> >> >>>>> >> On 04/15/2015 12:43 PM, James James wrote: >>>>> >>> Here the log >>>>> >>> >>>>> >>> 2015-04-15 18:58 GMT+02:00 Rich >>>>> Megginson >>>> >>>>> >>> >>>> >>: >>>>> >>> >>>>> >>> On 04/15/2015 09:46 AM, James James >>>>> wrote: >>>>> >>>> Hello, >>>>> >>>> >>>>> >>>> I have been looking to solve my >>>>> problem but I 'm asking for >>>>> >>>> some help. >>>>> >>>> >>>>> >>>> The replication begins but cannot >>>>> be completed .... >>>>> >>>> >>>>> >>>> I want to install a new fresh >>>>> replica but I've always got >>>>> >>>> this error : >>>>> >>>> >>>>> >>>> [21/35]: configure dirsrv ccache >>>>> >>>> [22/35]: enable SASL mapping fallback >>>>> >>>> [23/35]: restarting directory server >>>>> >>>> [24/35]: setting up initial replication >>>>> >>>> Starting replication, please wait until >>>>> this has completed. >>>>> >>>> Update in progress, 127 seconds >>>>> elapsed >>>>> >>>> Update in progress yet not in progress >>>>> >>>> >>>>> >>>> Update in progress yet not in progress >>>>> >>> >>>>> > >>>>> > in progress yet not in progress???? The >>>>> error log below clearly shows >>>>> > that replica init succeeded after 127 seconds. >>>>> > >>>>> > IPA-ers - wasn't there some bug about >>>>> checking replica status properly? >>>>> > >>>>> >>>>> The loop looks at nsds5BeginReplicaRefresh, >>>>> nsds5replicaUpdateInProgress >>>>> and nsds5ReplicaLastInitStatus. >>>>> >>>>> It loops looking for nsds5BeginReplicaRefresh. >>>>> If there is no value it >>>>> prints "Update in progress, %d seconds >>>>> elapsed". Once it gets a status, >>>>> the update is done, and it looks at >>>>> nsds5ReplicaLastInitStatus. If it >>>>> isn't empty, doesn't include 'replica busy' or >>>>> 'Total update succeeded' >>>>> then it looks to see if >>>>> nsds5replicaUpdateInProgress is TRUE. If it is, >>>>> ir prints Update in progress yet not in >>>>> progress and tries the loop again. >>>>> >>>>> AFAICT this part of a replica install doesn't >>>>> restart 389-ds. >>>>> >>>>> /var/log/ipareplica-install.log may hold some >>>>> details. >>>>> >>>>> rob >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notify.sina at gmail.com Mon May 18 12:11:59 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 18 May 2015 13:11:59 +0100 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <5559AE81.9000907@redhat.com> References: <5559AE81.9000907@redhat.com> Message-ID: Yes CA is running, and it's on the same machine. [root at dc ~]# ipa-replica-prepare dc01.ourdom.com --ip-address 192.168.2.40 Directory Manager (existing master) password: Preparing replica for dc01.ourdom.com from dc.ourdom.com Creating SSL certificate for the Directory Server Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) [root at dc ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root at dc ~]# On Mon, May 18, 2015, 10:19 AM Martin Kosek wrote: > On 05/16/2015 12:18 PM, Sina Owolabi wrote: > > Hi Group, > > > > I'm attempting again to rebuild and reinstall a troublesome replica. I > > have two freshly upgraded RHEL6.6 IdM servers. > > > > Problem is when I try to run createreplica I have this output: > > > > ipa-replica-prepare services01.ours.com --ip-address 192.168.2.40 > > Directory Manager (existing master) password: > > > > Preparing replica for services01.ours.com from services.ours.com > > Creating SSL certificate for the Directory Server > > Certificate operation cannot be completed: Unable to communicate with > > CMS (Not Found) > > It looks like CA is not reachable. Is CA on the machine where you run > ipa-replica-manage? Or other machine? > > Is the CA running? (ipactl status) > > > > > I have check the different threads where I find this same error but > > all symlinks are correctly defined. > > > > Please can someone kindly guide a noob in the right path? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notify.sina at gmail.com Mon May 18 12:17:15 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 18 May 2015 13:17:15 +0100 Subject: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot In-Reply-To: <5559ADCC.8050001@redhat.com> References: <5559ADCC.8050001@redhat.com> Message-ID: Hi Martin And thanks for getting back, greatly appreciated. I tore down the replica and reinstalled from scratch, using an old replica-info file I had on the primary. Im not sure if this is a good thing to do, but I would appreciate if you could point me to the logs you'd be interested in seeing. I had to reinstall the replica without CA before it would complete, too. Thanks again for your precious time. On Mon, May 18, 2015 at 10:15 AM, Martin Kosek wrote: > On 05/16/2015 12:19 PM, Sina Owolabi wrote: >> Please help me. I am in dire straits, this is the linchpin of our >> network and we are suffering. > > I am sorry for delay in answering, but not many people here show up on the > weekend. Comments below. > >> On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi wrote: >>> Hi! >>> >>> I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, >>> with the following versions: >>> libipa_hbac-1.11.6-30.el6_6.4.x86_64 >>> ipa-server-selinux-3.0.0-42.el6.x86_64 >>> libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 >>> ipa-admintools-3.0.0-42.el6.x86_64 >>> python-iniparse-0.3.1-2.1.el6.noarch >>> ipa-client-3.0.0-42.el6.x86_64 >>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>> device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 >>> device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 >>> ipa-server-3.0.0-42.el6.x86_64 >>> ipa-python-3.0.0-42.el6.x86_64 >>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>> sssd-ipa-1.11.6-30.el6_6.4.x86_64 >>> >>> >>> I noticed the replica did not seem to be in sync with the primary IPA >>> server, as login requests to ipa clients using the replica for domain >>> authentication failed with >>> "Too many authentication failures for user UNKNOWN". >>> I forced a sync with the primary server and rebooted the replica afterwards. >>> Now the replica is back up, but when I run "ipactl status", only >>> dirsrv is running: >>> # ipactl status >>> Directory Service: RUNNING > > This is strange, try > > # ipactl restart > > see which services fail to start and see the logs they produce. > >>> No other service shows up. I also tried editing /etc/krb5.conf to >>> change the [realms] information to point to the primary server, but >>> while I can now kinit admin, >>> nothing else works. >>> >>> Please how can I fix this problem? >>> >>> Please what can I do fix this? > > First things first. You need to first see if all service start and operate > properly, if not, we need to see their logs in order to help or advise. > > Martin From janellenicole80 at gmail.com Mon May 18 12:59:51 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 18 May 2015 07:59:51 -0500 Subject: [Freeipa-users] 4.1.4 and OTP In-Reply-To: <5559B170.1040402@redhat.com> References: <553123D9.5090800@gmail.com> <55313A9B.2030408@redhat.com> <553140DA.7020001@gmail.com> <55316ABF.1000606@redhat.com> <55317279.3010107@gmail.com> <55319908.60109@redhat.com> <8898FB62-D73E-4D51-BE4B-2C0F6A903970@gmail.com> <5531AC8D.3070900@redhat.com> <5531CDAF.1080506@gmail.com> <1430228679.4592.4.camel@redhat.com> <55592916.3080404@gmail.com> <5559B170.1040402@redhat.com> Message-ID: > On May 18, 2015, at 04:31, Martin Kosek wrote: > >> On 05/18/2015 01:49 AM, Janelle wrote: >>> On 4/28/15 6:44 AM, Nathaniel McCallum wrote: >>>> On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: >>>>> On 4/17/15 5:59 PM, Dmitri Pal wrote: >>>>>> On 04/17/2015 08:07 PM, Janelle wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Apr 17, 2015, at 16:36, Dmitri Pal wrote: >>>>>> >> for shorter thread.... >>>>>> Simple. And my test made it simple. >>>>>> Stand up new vm running fc21/freeipa. >>>>>> Configure user. >>>>>> Add password. >>>>>> Add token. >>>>>> >>>>>> Login to the vm with the user created using password. Kerberos >>>>>> ticket assigned, all is well. >>>>>> >>>>>> Login to web interface with admin. Change user to OTP only. >>>>>> Go to web UI and click sync OTP. >>>>>> Enter username, password and 2 OTP sequences. Click sync. Error >>>>>> appears. >>>>>> >>>>>> Now, ssh to same vm using OTP username. Enter password + OTP >>>>>> value. >>>>>> Login successful. >>>>> I can reproduce this issue with demo instance. >>>>> I will file a bug later today. >>>>> I think it is a bug with sync. >>>>> Which token do you use time based or event based? >>>> TOTP... >>>> >>>> Hmm, makes me wonder - with HOTP fail the same? Off to try it. >>> This should just affect TOTP. I have posted a patch that should fix >>> this problem. Are you able to test it? >>> >>> https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html >>> >>> >> Sorry - I just got around to testing this and it does resolve the problem - >> HOWEVER, you took away the ability to "Name" the tokens? They are now >> "assigned" unique IDs?? >> >> Was this intentional? > > It was, we track this (half-done) change in this ticket: > https://fedorahosted.org/freeipa/ticket/4456 > > The main problem here is that user token names share the same name space and we > thus do not want to create completely arbitrary names as they would collide. > > Applications like FreeOTP allow users to set own labels, so this is IMO the way > how to add friendly names to the OTP tokens. > > Martin > Makes sense, my only concern is syncing tokens. Once you add a second to,en and want to sync it you have to give it a token ID, otherwise it does not know which to sync. In the past if you named it, that was easy, but it does not seem to take description field as a token name. Guess I need to tell my users it is cut/paste time, or is there another option perhaps? Also, I was wondering, looking for a way to use both FreeOTP and yubikey and wondering if anyone has tried this and possible caveats? Janelle From janellenicole80 at gmail.com Mon May 18 13:39:02 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 18 May 2015 06:39:02 -0700 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <20150511065759.GA5152@redhat.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> Message-ID: <5559EB76.9080100@gmail.com> On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > On Sun, 10 May 2015, Janelle wrote: >> On 5/5/15 6:47 AM, Dmitri Pal wrote: >>> On 05/04/2015 09:38 PM, Janelle wrote: >>>> On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >>>>> On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >>>>>> Happy Star Wars Day! >>>>>> May the Fourth be with you! >>>>>> >>>>>> So I have a strange Kerberos problem trying to figure out. On a >>>>>> CLIENT, (CentOS 7.1) if I login to account "usera" they get a >>>>>> ticket as >>>>>> expected. However, if I login to a 6.6 client, it doesn't seem to >>>>>> work. >>>>>> Both were enrolled the same, obviously one is newer. >>>>>> >>>>>> Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >>>>>> as >>>>>> root, bypassing kerberos, and then do "kinit admin" it works just >>>>>> fine. >>>>>> But if I do "kinit usera" I get: >>>>>> >>>>>> kinit: Generic preauthentication failure while getting initial >>>>>> credentials >>>>>> >>>>>> Which makes no sense. The account works with a 7.1 client but not a >>>>>> 6.x >>>>>> client?? And yet "admin" works, no matter what. What am I missing >>>>>> here? >>>>> If I had to guess, usera is enabled for OTP-only login. Is that >>>>> correct? >>>>> >>>>> If so, clients require RHEL 7.1 for OTP support. Also, the error you >>>>> are getting is the result of not enabling FAST support for OTP >>>>> authentication (see the -T option). >>>>> >>>>> Nathaniel >>>> Ok, this did give me an idea (Thanks Nathaniel) -- the account was >>>> set for BOTH "password" and OTP. >>>> Apparently setting both does nothing. Yes a user can login with >>>> their password-only, but trying to use kinit does not work. >>>> >>>> I am not sure I understand where the FAST support or the -T option >>>> is to be applied. On kinit? That does not seem correct. Perhaps I >>>> am misunderstanding this option? >>>> >>>> ~J >>>> >>> If the user is enabled for OTP his credential are sent differently >>> than in the case when it is not enabled. Effectively instead of >>> using encrypted timestamp the password and OTP are sent to the >>> server as data. But they can't be sent in clear. You need to encrypt >>> the data. To encrypt it you need another key - the host key. The >>> encryption of the data in this context is called tunneling . FAST is >>> the Kerberos protocol feature to provide tunneling of the data sent >>> over the wire. To use FAST one needs to use -T on the kinit command >>> line. >>> Does this help? >>> >> It helps -- thank you. >> >> Now allow me to add a little more fun, and there may not be a solution. >>> From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server >> principal" and it works, gives me a ticket, and if I attempt to login >> to the web interface, since I already have my ticket - boom, works fine. >> >> Now, I enable 2FA and setup a token and change my account to OTP >> (with TOTP). But as previously discussed, can't seem to specify a -T >> option from OS X. >> >> I know this sounds tricky -- Any ideas? > Use > kinit --fast-armor-cache /path/to/ccache to specify already existing > ccache to armor the FAST processing. > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. > You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? ~J PS - sorry for the questions, still trying to wrap my head around how to get OTP working from a term session so you can get your ticket and then login to all the hosts you need without reauthenticating. From npmccallum at redhat.com Mon May 18 13:46:21 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 18 May 2015 09:46:21 -0400 Subject: [Freeipa-users] 4.1.4 and OTP In-Reply-To: References: <553123D9.5090800@gmail.com> <55313A9B.2030408@redhat.com> <553140DA.7020001@gmail.com> <55316ABF.1000606@redhat.com> <55317279.3010107@gmail.com> <55319908.60109@redhat.com> <8898FB62-D73E-4D51-BE4B-2C0F6A903970@gmail.com> <5531AC8D.3070900@redhat.com> <5531CDAF.1080506@gmail.com> <1430228679.4592.4.camel@redhat.com> <55592916.3080404@gmail.com> <5559B170.1040402@redhat.com> Message-ID: <1431956781.7868.1.camel@redhat.com> On Mon, 2015-05-18 at 07:59 -0500, Janelle wrote: > > > > On May 18, 2015, at 04:31, Martin Kosek wrote: > > > > > On 05/18/2015 01:49 AM, Janelle wrote: > > > > On 4/28/15 6:44 AM, Nathaniel McCallum wrote: > > > > > On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: > > > > > > On 4/17/15 5:59 PM, Dmitri Pal wrote: > > > > > > > On 04/17/2015 08:07 PM, Janelle wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Apr 17, 2015, at 16:36, Dmitri Pal > > > > > > > wrote: > > > > > > > > > > for shorter thread.... > > > > > > > Simple. And my test made it simple. > > > > > > > Stand up new vm running fc21/freeipa. > > > > > > > Configure user. > > > > > > > Add password. > > > > > > > Add token. > > > > > > > > > > > > > > Login to the vm with the user created using password. > > > > > > > Kerberos > > > > > > > ticket assigned, all is well. > > > > > > > > > > > > > > Login to web interface with admin. Change user to OTP > > > > > > > only. > > > > > > > Go to web UI and click sync OTP. > > > > > > > Enter username, password and 2 OTP sequences. Click sync. > > > > > > > Error > > > > > > > appears. > > > > > > > > > > > > > > Now, ssh to same vm using OTP username. Enter password + > > > > > > > OTP > > > > > > > value. > > > > > > > Login successful. > > > > > > I can reproduce this issue with demo instance. > > > > > > I will file a bug later today. > > > > > > I think it is a bug with sync. > > > > > > Which token do you use time based or event based? > > > > > TOTP... > > > > > > > > > > Hmm, makes me wonder - with HOTP fail the same? Off to try > > > > > it. > > > > This should just affect TOTP. I have posted a patch that should > > > > fix > > > > this problem. Are you able to test it? > > > > > > > > https://www.redhat.com/archives/freeipa-devel/2015 > > > > -April/msg00282.html > > > > > > > > > > > Sorry - I just got around to testing this and it does resolve the > > > problem - > > > HOWEVER, you took away the ability to "Name" the tokens? They are > > > now > > > "assigned" unique IDs?? > > > > > > Was this intentional? > > > > It was, we track this (half-done) change in this ticket: > > https://fedorahosted.org/freeipa/ticket/4456 > > > > The main problem here is that user token names share the same name > > space and we > > thus do not want to create completely arbitrary names as they would > > collide. > > > > Applications like FreeOTP allow users to set own labels, so this is > > IMO the way > > how to add friendly names to the OTP tokens. > > > > Martin > > > > Makes sense, my only concern is syncing tokens. Once you add a > second to,en and want to sync it you have to give it a token ID, > otherwise it does not know which to sync. In the past if you named > it, that was easy, but it does not seem to take description field as > a token name. Guess I need to tell my users it is cut/paste time, or > is there another option perhaps? You do not need to specify the token id when syncing. It is optional. If you leave it blank, FreeIPA will do the right thing. > Also, I was wondering, looking for a way to use both FreeOTP and > yubikey and wondering if anyone has tried this and possible caveats? There shouldn't be any caveats. Yubikey is just an HOTP token. Nathaniel From rcritten at redhat.com Mon May 18 13:46:29 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 May 2015 09:46:29 -0400 Subject: [Freeipa-users] host usercertificate attribute In-Reply-To: References: Message-ID: <5559ED35.8000200@redhat.com> Natxo Asenjo wrote: > On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo > wrote: > > hi, > > If I retrieve the usercertificate attribute for host objects I get > some gibberish. > > How can I decode the info I get from ldapsearch? > > > maybe there is a way to feed that to openssl. What I ended up doing was > using Perl and Crypt::X509 and I can see all the certificate elements. They are DER-encoded files. Something like this will show the contents: $ openssl x509 -text -in /tmp/file rob From vangass at gazeta.pl Mon May 18 13:52:30 2015 From: vangass at gazeta.pl (Vangass) Date: Mon, 18 May 2015 15:52:30 +0200 Subject: [Freeipa-users] LDAP uid to cn modify Message-ID: Hi, I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO client sends dn as "cn=bartosz,cn=users,cn=accounts,dc=example,dc=com" but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other user I create is uid). Is it possible to modify uid to cn or is there any other option? Thanks, Bartosz Witkowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Mon May 18 13:55:04 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Mon, 18 May 2015 13:55:04 +0000 Subject: [Freeipa-users] trusted user groups In-Reply-To: <20150514204129.GB11220@mail.corp.redhat.com> References: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> <20150514154532.GK2709@hendrix> <19fca29e79eb4635acddd4a9f3be20d3@TCCCORPEXCH02.TCC.local> <20150514204129.GB11220@mail.corp.redhat.com> Message-ID: <1efcbde8674c45158b30af7ed10ffa40@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: Lukas Slebodnik [mailto:lslebodn at redhat.com] > Sent: Thursday, May 14, 2015 4:41 PM > To: Andy Thompson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trusted user groups > > On (14/05/15 15:53), Andy Thompson wrote: > >> -----Original Message----- > >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >> bounces at redhat.com] On Behalf Of Jakub Hrozek > >> Sent: Thursday, May 14, 2015 11:46 AM > >> To: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] trusted user groups > >> > >> On Thu, May 14, 2015 at 03:33:28PM +0000, Andy Thompson wrote: > >> > I've noticed that trusted users supplementary ad groups don't show > >> > up > >> until after the users login to the box at least once. > >> > >> That's expected with the versions you're running. Prior to 6.7, we > >> could only read the trusted users' group membership from the PAC blob > >> attached to the Kerberos ticket. > >> > >> > >> > Is there a chance that information will be dropped again at any > >> > point going > >> forward? > >> > >> No, otherwise it's a bug. > >> > >> > > >> > The reason I ask is that on our sftp boxes we chroot users based on > >> > group membership. I set that up as an external group in freeIPA > >> > and the first time the user logs in to the sftp box, they are > >> > dropped in their normal home directory as opposed to the chroot > >> > environment. If there is a chance the group membership will not > >> > show up correctly again in the future, I'm inclined to change the > >> > chroot stanzas to match on > >> user as opposed to group. > >> > > >> > Is that by design? > >> > >> If you can't see the correct group memberships after a login, then > >> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and > >> there's so many fixes and enhancements in this area..is there a > >> chance you could try out 6.7 beta or some custom packages? > >> > > > >Group memberships show up fine after the first login so it is working as > expected then. The accounts are very controlled so it shouldn't be a huge > sticking point. I could try out some custom packages on this box but I can't > move to 6.7 until we upgrade the entire environment. > > > Here you are > https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ > To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. I just can't roll them in production yet :/ Thanks -andy From abokovoy at redhat.com Mon May 18 14:03:18 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 May 2015 17:03:18 +0300 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <5559EB76.9080100@gmail.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> Message-ID: <20150518140318.GB21881@redhat.com> On Mon, 18 May 2015, Janelle wrote: >On 5/10/15 11:57 PM, Alexander Bokovoy wrote: >>On Sun, 10 May 2015, Janelle wrote: >>>On 5/5/15 6:47 AM, Dmitri Pal wrote: >>>>On 05/04/2015 09:38 PM, Janelle wrote: >>>>>On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >>>>>>On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >>>>>>>Happy Star Wars Day! >>>>>>>May the Fourth be with you! >>>>>>> >>>>>>>So I have a strange Kerberos problem trying to figure out. On a >>>>>>>CLIENT, (CentOS 7.1) if I login to account "usera" they get a >>>>>>>ticket as >>>>>>>expected. However, if I login to a 6.6 client, it doesn't seem to >>>>>>>work. >>>>>>>Both were enrolled the same, obviously one is newer. >>>>>>> >>>>>>>Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login >>>>>>>as >>>>>>>root, bypassing kerberos, and then do "kinit admin" it works just >>>>>>>fine. >>>>>>>But if I do "kinit usera" I get: >>>>>>> >>>>>>>kinit: Generic preauthentication failure while getting initial >>>>>>>credentials >>>>>>> >>>>>>>Which makes no sense. The account works with a 7.1 client but not a >>>>>>>6.x >>>>>>>client?? And yet "admin" works, no matter what. What am I missing >>>>>>>here? >>>>>>If I had to guess, usera is enabled for OTP-only login. Is that >>>>>>correct? >>>>>> >>>>>>If so, clients require RHEL 7.1 for OTP support. Also, the error you >>>>>>are getting is the result of not enabling FAST support for OTP >>>>>>authentication (see the -T option). >>>>>> >>>>>>Nathaniel >>>>>Ok, this did give me an idea (Thanks Nathaniel) -- the >>>>>account was set for BOTH "password" and OTP. >>>>>Apparently setting both does nothing. Yes a user can login >>>>>with their password-only, but trying to use kinit does not >>>>>work. >>>>> >>>>>I am not sure I understand where the FAST support or the -T >>>>>option is to be applied. On kinit? That does not seem correct. >>>>>Perhaps I am misunderstanding this option? >>>>> >>>>>~J >>>>> >>>>If the user is enabled for OTP his credential are sent >>>>differently than in the case when it is not enabled. Effectively >>>>instead of using encrypted timestamp the password and OTP are >>>>sent to the server as data. But they can't be sent in clear. You >>>>need to encrypt the data. To encrypt it you need another key - >>>>the host key. The encryption of the data in this context is >>>>called tunneling . FAST is the Kerberos protocol feature to >>>>provide tunneling of the data sent over the wire. To use FAST >>>>one needs to use -T on the kinit command line. >>>>Does this help? >>>> >>>It helps -- thank you. >>> >>>Now allow me to add a little more fun, and there may not be a solution. >>>>From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server >>>principal" and it works, gives me a ticket, and if I attempt to >>>login to the web interface, since I already have my ticket - boom, >>>works fine. >>> >>>Now, I enable 2FA and setup a token and change my account to OTP >>>(with TOTP). But as previously discussed, can't seem to specify a >>>-T option from OS X. >>> >>>I know this sounds tricky -- Any ideas? >>Use >> kinit --fast-armor-cache /path/to/ccache to specify already >>existing ccache to armor the FAST processing. >> >>This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. >>You can check version number by running 'kinit --version'. >Aha, so thee default on OS X Yosemite is > >$ kinit --version >kinit (Heimdal 1.5.1apple1) > >so this won't work? Yes, you have to have the feature in your Kerberos library. -- / Alexander Bokovoy From rcritten at redhat.com Mon May 18 14:03:53 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 May 2015 10:03:53 -0400 Subject: [Freeipa-users] LDAP uid to cn modify In-Reply-To: References: Message-ID: <5559F149.9040500@redhat.com> Vangass wrote: > Hi, > > I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO > client sends dn as "cn=bartosz,cn=users,cn=accounts,dc=example,dc=com" > but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other > user I create is uid). Is it possible to modify uid to cn or is there > any other option? > > Thanks, > Bartosz Witkowski > > Others have had the same issue, https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html If you are running EL 7+ you should be able to create a compat configuration to make it work but it isn't clear if anyone has done this work on IPA 3.3+ or not yet (IIRC the users in this thread were all still on RHEL 6). rob From rcritten at redhat.com Mon May 18 14:05:42 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 May 2015 10:05:42 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <5559AE81.9000907@redhat.com> Message-ID: <5559F1B6.4030207@redhat.com> Sina Owolabi wrote: > Yes CA is running, and it's on the same machine. > > [root at dc ~]# ipa-replica-prepare dc01.ourdom.com > --ip-address 192.168.2.40 > > Directory Manager (existing master) password: > > > Preparing replica for dc01.ourdom.com from > dc.ourdom.com > > Creating SSL certificate for the Directory Server > > Certificate operation cannot be completed: Unable to communicate with > CMS (Not Found) > > [root at dc ~]# ipactl status > > Directory Service: RUNNING > > KDC Service: RUNNING > > KPASSWD Service: RUNNING > > DNS Service: RUNNING > > MEMCACHE Service: RUNNING > > HTTP Service: RUNNING > > CA Service: RUNNING > > [root at dc ~]# This suggests that while the process is running the CA isn't actually operational. You'll need to poke through the logs in /var/log/pki* to see if there are any errors. I'd also see if the certificates are expired by running `getcert list` as root. rob From npmccallum at redhat.com Mon May 18 14:07:06 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 18 May 2015 10:07:06 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <20150518140318.GB21881@redhat.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> Message-ID: <1431958026.7868.3.camel@redhat.com> On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: > On Mon, 18 May 2015, Janelle wrote: > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > > On Sun, 10 May 2015, Janelle wrote: > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > > Happy Star Wars Day! > > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to figure > > > > > > > > out. On a > > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > > they get a > > > > > > > > ticket as > > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > > doesn't seem to > > > > > > > > work. > > > > > > > > Both were enrolled the same, obviously one is newer. > > > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > > also. If I login > > > > > > > > as > > > > > > > > root, bypassing kerberos, and then do "kinit admin" it > > > > > > > > works just > > > > > > > > fine. > > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > > > kinit: Generic preauthentication failure while getting > > > > > > > > initial > > > > > > > > credentials > > > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > > client but not a > > > > > > > > 6.x > > > > > > > > client?? And yet "admin" works, no matter what. What am > > > > > > > > I missing > > > > > > > > here? > > > > > > > If I had to guess, usera is enabled for OTP-only login. > > > > > > > Is that > > > > > > > correct? > > > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. Also, > > > > > > > the error you > > > > > > > are getting is the result of not enabling FAST support > > > > > > > for OTP > > > > > > > authentication (see the -T option). > > > > > > > > > > > > > > Nathaniel > > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > > account was set for BOTH "password" and OTP. > > > > > > Apparently setting both does nothing. Yes a user can login > > > > > > with their password-only, but trying to use kinit does not > > > > > > work. > > > > > > > > > > > > I am not sure I understand where the FAST support or the -T > > > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > > correct. > > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > > > ~J > > > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > > differently than in the case when it is not enabled. > > > > > Effectively > > > > > instead of using encrypted timestamp the password and OTP are > > > > > > > > > > sent to the server as data. But they can't be sent in clear. > > > > > You > > > > > need to encrypt the data. To encrypt it you need another key > > > > > - > > > > > the host key. The encryption of the data in this context is > > > > > called tunneling . FAST is the Kerberos protocol feature to > > > > > provide tunneling of the data sent over the wire. To use FAST > > > > > > > > > > one needs to use -T on the kinit command line. > > > > > Does this help? > > > > > > > > > It helps -- thank you. > > > > > > > > Now allow me to add a little more fun, and there may not be a > > > > solution. > > > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA > > > > > -server > > > > principal" and it works, gives me a ticket, and if I attempt to > > > > > > > > login to the web interface, since I already have my ticket - > > > > boom, > > > > works fine. > > > > > > > > Now, I enable 2FA and setup a token and change my account to > > > > OTP > > > > (with TOTP). But as previously discussed, can't seem to > > > > specify a > > > > -T option from OS X. > > > > > > > > I know this sounds tricky -- Any ideas? > > > Use > > > kinit --fast-armor-cache /path/to/ccache to specify already > > > existing ccache to armor the FAST processing. > > > > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at > > > least. > > > You can check version number by running 'kinit --version'. > > Aha, so thee default on OS X Yosemite is > > > > $ kinit --version > > kinit (Heimdal 1.5.1apple1) > > > > so this won't work? > Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( Nathaniel From wdh at dds.nl Mon May 18 14:09:52 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Mon, 18 May 2015 16:09:52 +0200 Subject: [Freeipa-users] AD-trust and external DNS Message-ID: <5559F2B0.6050507@dds.nl> An HTML attachment was scrubbed... URL: From jbaird at follett.com Mon May 18 14:13:42 2015 From: jbaird at follett.com (Baird, Josh) Date: Mon, 18 May 2015 14:13:42 +0000 Subject: [Freeipa-users] AD-trust and external DNS In-Reply-To: <5559F2B0.6050507@dds.nl> References: <5559F2B0.6050507@dds.nl> Message-ID: You should add your IPA zone as a slave on your 'external' DNS servers so they are able to resolve the IPA zone. Josh From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Winfried de Heiden Sent: Monday, May 18, 2015 10:10 AM To: Freeipa-users Subject: [Freeipa-users] AD-trust and external DNS Hi all, Creating an AD-trust works nicely. However, for some customers both AD and IPA don't have have DNS "for their own", the use external DNS (Infoblox for example) Now, is is possible to create an AD trust without a build-in (bind) IPA-DNS? Thankz! Winfried -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon May 18 14:18:12 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 18 May 2015 08:18:12 -0600 Subject: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR In-Reply-To: <59310E142C8544ACB273E946B7121A98@Azul> References: <96f6d8ab66355a90115b1c92a8a50050.squirrel@webmail.nathanpeters.com> <55547FF4.3060100@redhat.com> <55553891.2000507@redhat.com> <23f113a4d4109c554f82bb48326539f1.squirrel@webmail.nathanpeters.com> <5555FE31.6060202@redhat.com> <14c073ed7f8f0e14d6ce8650bef6c025.squirrel@webmail.nathanpeters.com> <55567D8C.4070008@redhat.com> <59310E142C8544ACB273E946B7121A98@Azul> Message-ID: <5559F4A4.1000704@redhat.com> On 05/16/2015 04:06 PM, Nathan Peters wrote: > I have updated the bug report you filed below. > > The issue was that the instructions would only work in Windows Server > 2003 because My Network Places was removed in 2008 and above. Since > the manual clearly states that the AD sync is to be performed with > server 2008 / 2012 only it made no sense to give instructions for an > incompatible version of windows. > > I have added to the ticket 2 methods to get the *correct* certificate > that will work in both server 2008 r2 and server 2012 r2. I am cc'd on the bug and have seen all of the information you added. Thanks! > > On 05/15/2015 03:09 PM, nathan at nathanpeters.com wrote: >>> On 05/14/2015 11:33 PM, nathan at nathanpeters.com wrote: >>>>>> [root at ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn >>>>>> "cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw >>>>>> supersecretpassword --passsync supersecretpassword --cacert >>>>>> /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v >>>>>> Directory Manager password: >>>>>> >>>>>> Added CA certificate /etc/openldap/cacerts/addc2-test.cer to >>>>>> certificate >>>>>> database for ipadc1.ipadomain.net >>>>>> ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net >>>>>> The user for the Windows PassSync service is >>>>>> uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >>>>>> Windows PassSync system account exists, not resetting password >>>>>> ipa: INFO: Added new sync agreement, waiting for it to become >>>>>> ready . >>>>>> . >>>>>> . >>>>>> ipa: INFO: Replication Update in progress: FALSE: status: -11 - >>>>>> LDAP >>>>>> error: Connect error: start: 0: end: 0 >>>>>> ipa: INFO: Agreement is ready, starting replication . . . >>>>>> Starting replication, please wait until this has completed. >>>>>> >>>>>> [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP >>>>>> error: >>>>>> Connect error] >>>>> Have you tried using ldapsearch to verify the connection? >>>>> >>>>> # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ >>>>> -h >>>>> addc2.test.mycompany.net -D "cn=ad >>>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>>> "supersecretpassword" -s base -b >>>>> "cn=Users,dc=test,dc=mycompany,dc=net" >>>>> "objectclass=*" >>>>> >>>>> and/or >>>>> >>>>> # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch >>>>> -xLLL >>>>> -ZZ -h addc2.test.mycompany.net -D "cn=ad >>>>> sync,cn=Users,dc=test,dc=mycompany,dc=net" -w >>>>> "supersecretpassword" -s base -b >>>>> "cn=Users,dc=test,dc=mycompany,dc=net" >>>>> "objectclass=*" >>>>> >>>> Both commands give the same successful result. I don't think it's a >>>> problem with the credentials because I was able to generate different >>>> error messages during the attempted sync setup if I intentionally >>>> gave a >>>> bad password or username. >>> Ok. Have you tried enabling the replication log level? >>> >>> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting >> Ok, that helped a lot. I got this fixed now. Because the manual tells >> you to export the cert using a way that doesn't work on newer >> versions of >> windows, I tried to improvise and my first attempt exported the wrong >> cert. >> >> The correct way is to go to mmc.exe and add the certificates snap-in. >> Then go to personal certificates store for the machine account and >> export >> the one that has -CA at the end of it in the issued to column. >> >> Now that the correct certificate was exported, replication >> succeeded. The >> docs should be updated though to reflect the proper way to export. >> > https://bugzilla.redhat.com/show_bug.cgi?id=1222161 > > Please add yourself to the bug and provide any additional information. From abokovoy at redhat.com Mon May 18 14:18:15 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 May 2015 17:18:15 +0300 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <1431958026.7868.3.camel@redhat.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> <1431958026.7868.3.camel@redhat.com> Message-ID: <20150518141815.GC21881@redhat.com> On Mon, 18 May 2015, Nathaniel McCallum wrote: >On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: >> On Mon, 18 May 2015, Janelle wrote: >> > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: >> > > On Sun, 10 May 2015, Janelle wrote: >> > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: >> > > > > On 05/04/2015 09:38 PM, Janelle wrote: >> > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >> > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >> > > > > > > > Happy Star Wars Day! >> > > > > > > > May the Fourth be with you! >> > > > > > > > >> > > > > > > > So I have a strange Kerberos problem trying to figure >> > > > > > > > out. On a >> > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" >> > > > > > > > they get a >> > > > > > > > ticket as >> > > > > > > > expected. However, if I login to a 6.6 client, it >> > > > > > > > doesn't seem to >> > > > > > > > work. >> > > > > > > > Both were enrolled the same, obviously one is newer. >> > > > > > > > >> > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 >> > > > > > > > also. If I login >> > > > > > > > as >> > > > > > > > root, bypassing kerberos, and then do "kinit admin" it >> > > > > > > > works just >> > > > > > > > fine. >> > > > > > > > But if I do "kinit usera" I get: >> > > > > > > > >> > > > > > > > kinit: Generic preauthentication failure while getting >> > > > > > > > initial >> > > > > > > > credentials >> > > > > > > > >> > > > > > > > Which makes no sense. The account works with a 7.1 >> > > > > > > > client but not a >> > > > > > > > 6.x >> > > > > > > > client?? And yet "admin" works, no matter what. What am >> > > > > > > > I missing >> > > > > > > > here? >> > > > > > > If I had to guess, usera is enabled for OTP-only login. >> > > > > > > Is that >> > > > > > > correct? >> > > > > > > >> > > > > > > If so, clients require RHEL 7.1 for OTP support. Also, >> > > > > > > the error you >> > > > > > > are getting is the result of not enabling FAST support >> > > > > > > for OTP >> > > > > > > authentication (see the -T option). >> > > > > > > >> > > > > > > Nathaniel >> > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the >> > > > > > account was set for BOTH "password" and OTP. >> > > > > > Apparently setting both does nothing. Yes a user can login >> > > > > > with their password-only, but trying to use kinit does not >> > > > > > work. >> > > > > > >> > > > > > I am not sure I understand where the FAST support or the -T >> > > > > > >> > > > > > option is to be applied. On kinit? That does not seem >> > > > > > correct. >> > > > > > Perhaps I am misunderstanding this option? >> > > > > > >> > > > > > ~J >> > > > > > >> > > > > If the user is enabled for OTP his credential are sent >> > > > > differently than in the case when it is not enabled. >> > > > > Effectively >> > > > > instead of using encrypted timestamp the password and OTP are >> > > > > >> > > > > sent to the server as data. But they can't be sent in clear. >> > > > > You >> > > > > need to encrypt the data. To encrypt it you need another key >> > > > > - >> > > > > the host key. The encryption of the data in this context is >> > > > > called tunneling . FAST is the Kerberos protocol feature to >> > > > > provide tunneling of the data sent over the wire. To use FAST >> > > > > >> > > > > one needs to use -T on the kinit command line. >> > > > > Does this help? >> > > > > >> > > > It helps -- thank you. >> > > > >> > > > Now allow me to add a little more fun, and there may not be a >> > > > solution. >> > > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA >> > > > > -server >> > > > principal" and it works, gives me a ticket, and if I attempt to >> > > > >> > > > login to the web interface, since I already have my ticket - >> > > > boom, >> > > > works fine. >> > > > >> > > > Now, I enable 2FA and setup a token and change my account to >> > > > OTP >> > > > (with TOTP). But as previously discussed, can't seem to >> > > > specify a >> > > > -T option from OS X. >> > > > >> > > > I know this sounds tricky -- Any ideas? >> > > Use >> > > kinit --fast-armor-cache /path/to/ccache to specify already >> > > existing ccache to armor the FAST processing. >> > > >> > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at >> > > least. >> > > You can check version number by running 'kinit --version'. >> > Aha, so thee default on OS X Yosemite is >> > >> > $ kinit --version >> > kinit (Heimdal 1.5.1apple1) >> > >> > so this won't work? >> Yes, you have to have the feature in your Kerberos library. > >Browsing the Heimdal source code, I don't even see any support for OTP >at all. :( The support is since 1.6rc2, it uses the Richards' draft (draft-richards-otp-kerberos-01.txt) as a base and handles preauth but I don't think anything but login and ftpd supports passing the OTP token. -- / Alexander Bokovoy From npmccallum at redhat.com Mon May 18 14:19:10 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 18 May 2015 10:19:10 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <20150518141815.GC21881@redhat.com> References: <55479517.7000803@gmail.com> <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> <1431958026.7868.3.camel@redhat.com> <20150518141815.GC21881@redhat.com> Message-ID: <1431958750.7868.4.camel@redhat.com> On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote: > On Mon, 18 May 2015, Nathaniel McCallum wrote: > > On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: > > > On Mon, 18 May 2015, Janelle wrote: > > > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > > > > On Sun, 10 May 2015, Janelle wrote: > > > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > > > > Happy Star Wars Day! > > > > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to > > > > > > > > > > figure > > > > > > > > > > out. On a > > > > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > > > > they get a > > > > > > > > > > ticket as > > > > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > > > > doesn't seem to > > > > > > > > > > work. > > > > > > > > > > Both were enrolled the same, obviously one is > > > > > > > > > > newer. > > > > > > > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > > > > also. If I login > > > > > > > > > > as > > > > > > > > > > root, bypassing kerberos, and then do "kinit admin" > > > > > > > > > > it > > > > > > > > > > works just > > > > > > > > > > fine. > > > > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > > > > > > > kinit: Generic preauthentication failure while > > > > > > > > > > getting > > > > > > > > > > initial > > > > > > > > > > credentials > > > > > > > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > > > > client but not a > > > > > > > > > > 6.x > > > > > > > > > > client?? And yet "admin" works, no matter what. > > > > > > > > > > What am > > > > > > > > > > I missing > > > > > > > > > > here? > > > > > > > > > If I had to guess, usera is enabled for OTP-only > > > > > > > > > login. > > > > > > > > > Is that > > > > > > > > > correct? > > > > > > > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. > > > > > > > > > Also, > > > > > > > > > the error you > > > > > > > > > are getting is the result of not enabling FAST > > > > > > > > > support > > > > > > > > > for OTP > > > > > > > > > authentication (see the -T option). > > > > > > > > > > > > > > > > > > Nathaniel > > > > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > > > > account was set for BOTH "password" and OTP. > > > > > > > > Apparently setting both does nothing. Yes a user can > > > > > > > > login > > > > > > > > with their password-only, but trying to use kinit does > > > > > > > > not > > > > > > > > work. > > > > > > > > > > > > > > > > I am not sure I understand where the FAST support or > > > > > > > > the -T > > > > > > > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > > > > correct. > > > > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > > > > > > > ~J > > > > > > > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > > > > differently than in the case when it is not enabled. > > > > > > > Effectively > > > > > > > instead of using encrypted timestamp the password and OTP > > > > > > > are > > > > > > > > > > > > > > sent to the server as data. But they can't be sent in > > > > > > > clear. > > > > > > > You > > > > > > > need to encrypt the data. To encrypt it you need another > > > > > > > key > > > > > > > - > > > > > > > the host key. The encryption of the data in this context > > > > > > > is > > > > > > > called tunneling . FAST is the Kerberos protocol feature > > > > > > > to > > > > > > > provide tunneling of the data sent over the wire. To use > > > > > > > FAST > > > > > > > > > > > > > > one needs to use -T on the kinit command line. > > > > > > > Does this help? > > > > > > > > > > > > > It helps -- thank you. > > > > > > > > > > > > Now allow me to add a little more fun, and there may not be > > > > > > a > > > > > > solution. > > > > > > > From OS X (Yosemite) I am able to "kinit --kdc > > > > > > > -hostname=IPA > > > > > > > -server > > > > > > principal" and it works, gives me a ticket, and if I > > > > > > attempt to > > > > > > > > > > > > login to the web interface, since I already have my ticket > > > > > > - > > > > > > boom, > > > > > > works fine. > > > > > > > > > > > > Now, I enable 2FA and setup a token and change my account > > > > > > to > > > > > > OTP > > > > > > (with TOTP). But as previously discussed, can't seem to > > > > > > specify a > > > > > > -T option from OS X. > > > > > > > > > > > > I know this sounds tricky -- Any ideas? > > > > > Use > > > > > kinit --fast-armor-cache /path/to/ccache to specify already > > > > > existing ccache to armor the FAST processing. > > > > > > > > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 > > > > > at > > > > > least. > > > > > You can check version number by running 'kinit --version'. > > > > Aha, so thee default on OS X Yosemite is > > > > > > > > $ kinit --version > > > > kinit (Heimdal 1.5.1apple1) > > > > > > > > so this won't work? > > > Yes, you have to have the feature in your Kerberos library. > > > > Browsing the Heimdal source code, I don't even see any support for > > OTP > > at all. :( > The support is since 1.6rc2, it uses the Richards' draft > (draft-richards-otp-kerberos-01.txt) as a base and handles preauth > but I > don't think anything but login and ftpd supports passing the OTP > token. Where is the code? I don't see any... Nathaniel From abokovoy at redhat.com Mon May 18 14:26:05 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 May 2015 17:26:05 +0300 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <1431958750.7868.4.camel@redhat.com> References: <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> <1431958026.7868.3.camel@redhat.com> <20150518141815.GC21881@redhat.com> <1431958750.7868.4.camel@redhat.com> Message-ID: <20150518142605.GD21881@redhat.com> On Mon, 18 May 2015, Nathaniel McCallum wrote: >On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote: >> On Mon, 18 May 2015, Nathaniel McCallum wrote: >> > On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: >> > > On Mon, 18 May 2015, Janelle wrote: >> > > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: >> > > > > On Sun, 10 May 2015, Janelle wrote: >> > > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: >> > > > > > > On 05/04/2015 09:38 PM, Janelle wrote: >> > > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: >> > > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: >> > > > > > > > > > Happy Star Wars Day! >> > > > > > > > > > May the Fourth be with you! >> > > > > > > > > > >> > > > > > > > > > So I have a strange Kerberos problem trying to >> > > > > > > > > > figure >> > > > > > > > > > out. On a >> > > > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" >> > > > > > > > > > they get a >> > > > > > > > > > ticket as >> > > > > > > > > > expected. However, if I login to a 6.6 client, it >> > > > > > > > > > doesn't seem to >> > > > > > > > > > work. >> > > > > > > > > > Both were enrolled the same, obviously one is >> > > > > > > > > > newer. >> > > > > > > > > > >> > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 >> > > > > > > > > > also. If I login >> > > > > > > > > > as >> > > > > > > > > > root, bypassing kerberos, and then do "kinit admin" >> > > > > > > > > > it >> > > > > > > > > > works just >> > > > > > > > > > fine. >> > > > > > > > > > But if I do "kinit usera" I get: >> > > > > > > > > > >> > > > > > > > > > kinit: Generic preauthentication failure while >> > > > > > > > > > getting >> > > > > > > > > > initial >> > > > > > > > > > credentials >> > > > > > > > > > >> > > > > > > > > > Which makes no sense. The account works with a 7.1 >> > > > > > > > > > client but not a >> > > > > > > > > > 6.x >> > > > > > > > > > client?? And yet "admin" works, no matter what. >> > > > > > > > > > What am >> > > > > > > > > > I missing >> > > > > > > > > > here? >> > > > > > > > > If I had to guess, usera is enabled for OTP-only >> > > > > > > > > login. >> > > > > > > > > Is that >> > > > > > > > > correct? >> > > > > > > > > >> > > > > > > > > If so, clients require RHEL 7.1 for OTP support. >> > > > > > > > > Also, >> > > > > > > > > the error you >> > > > > > > > > are getting is the result of not enabling FAST >> > > > > > > > > support >> > > > > > > > > for OTP >> > > > > > > > > authentication (see the -T option). >> > > > > > > > > >> > > > > > > > > Nathaniel >> > > > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the >> > > > > > > > account was set for BOTH "password" and OTP. >> > > > > > > > Apparently setting both does nothing. Yes a user can >> > > > > > > > login >> > > > > > > > with their password-only, but trying to use kinit does >> > > > > > > > not >> > > > > > > > work. >> > > > > > > > >> > > > > > > > I am not sure I understand where the FAST support or >> > > > > > > > the -T >> > > > > > > > >> > > > > > > > option is to be applied. On kinit? That does not seem >> > > > > > > > correct. >> > > > > > > > Perhaps I am misunderstanding this option? >> > > > > > > > >> > > > > > > > ~J >> > > > > > > > >> > > > > > > If the user is enabled for OTP his credential are sent >> > > > > > > differently than in the case when it is not enabled. >> > > > > > > Effectively >> > > > > > > instead of using encrypted timestamp the password and OTP >> > > > > > > are >> > > > > > > >> > > > > > > sent to the server as data. But they can't be sent in >> > > > > > > clear. >> > > > > > > You >> > > > > > > need to encrypt the data. To encrypt it you need another >> > > > > > > key >> > > > > > > - >> > > > > > > the host key. The encryption of the data in this context >> > > > > > > is >> > > > > > > called tunneling . FAST is the Kerberos protocol feature >> > > > > > > to >> > > > > > > provide tunneling of the data sent over the wire. To use >> > > > > > > FAST >> > > > > > > >> > > > > > > one needs to use -T on the kinit command line. >> > > > > > > Does this help? >> > > > > > > >> > > > > > It helps -- thank you. >> > > > > > >> > > > > > Now allow me to add a little more fun, and there may not be >> > > > > > a >> > > > > > solution. >> > > > > > > From OS X (Yosemite) I am able to "kinit --kdc >> > > > > > > -hostname=IPA >> > > > > > > -server >> > > > > > principal" and it works, gives me a ticket, and if I >> > > > > > attempt to >> > > > > > >> > > > > > login to the web interface, since I already have my ticket >> > > > > > - >> > > > > > boom, >> > > > > > works fine. >> > > > > > >> > > > > > Now, I enable 2FA and setup a token and change my account >> > > > > > to >> > > > > > OTP >> > > > > > (with TOTP). But as previously discussed, can't seem to >> > > > > > specify a >> > > > > > -T option from OS X. >> > > > > > >> > > > > > I know this sounds tricky -- Any ideas? >> > > > > Use >> > > > > kinit --fast-armor-cache /path/to/ccache to specify already >> > > > > existing ccache to armor the FAST processing. >> > > > > >> > > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 >> > > > > at >> > > > > least. >> > > > > You can check version number by running 'kinit --version'. >> > > > Aha, so thee default on OS X Yosemite is >> > > > >> > > > $ kinit --version >> > > > kinit (Heimdal 1.5.1apple1) >> > > > >> > > > so this won't work? >> > > Yes, you have to have the feature in your Kerberos library. >> > >> > Browsing the Heimdal source code, I don't even see any support for >> > OTP >> > at all. :( >> The support is since 1.6rc2, it uses the Richards' draft >> (draft-richards-otp-kerberos-01.txt) as a base and handles preauth >> but I >> don't think anything but login and ftpd supports passing the OTP >> token. > >Where is the code? I don't see any... Yes, you made me realize this is pre-richards code in lib/otp/. Janelle: no support for Kerberos OTP on Mac OS X Yosemite or any other Heimdal environment to date. -- / Alexander Bokovoy From mkosek at redhat.com Mon May 18 14:26:45 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 16:26:45 +0200 Subject: [Freeipa-users] Securing IPA Redux In-Reply-To: <14071628-9A9D-4D2F-8C23-03E342530B93@gmail.com> References: <7B765750-7688-4643-B86E-27F40E8582E0@gmail.com> <5559AC6E.5060607@redhat.com> <14071628-9A9D-4D2F-8C23-03E342530B93@gmail.com> Message-ID: <5559F6A5.7070906@redhat.com> Adding freeipa-users list back, to keep others in the loop. On 05/18/2015 12:32 PM, Brian Topping wrote: > Thanks for taking the time to write that, Martin. It's good to have a reference to build from. > > Result of "ida-client-install" outside the firewall with port 636 accessible: Ah, I mostly just use 636 as a convenience port to show the supported cryptos, 389 is really the port we should be using by default. Of course, 389 port + STARTTLS environment turned on, to make sure passwords do not go in clean over the wire. >> Please make sure the following ports are opened in the firewall settings: >> TCP: 80, 88, 389 >> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) >> Also note that following ports are necessary for ipa-client working properly after enrollment: >> TCP: 464 >> UDP: 464, 123 (if NTP enabled) > > No mention of 636, confirmed by tcpdump that it's not trying. Also no option on command line to specify 636. > > Opening up 389 means that some misconfigured client could expose passwords. It's possible to remove null ciphers, but then there's really no reason not to use 636. > > Seems like ipa-client-install should try 636 by default, then fall back to 389 in it's various forms, no? I think the general direction here was the opposite. To work on the port 389 as the common denominator, offering both password-less traffic and encrypted traffic. I am not sure if there were other reasons too, I would let Rob or Ludwig reply here if they know. Martin >> On May 18, 2015, at 4:10 PM, Martin Kosek wrote: >> >> On 05/15/2015 01:33 PM, Brian Topping wrote: >>> In the (apparently) first message to the list in 2014, https://www.redhat.com/archives/freeipa-users/2014-January/msg00000.html addressed questions about securing IPA and I don't see much other talk about it. Now that 4.x is prevalent, I wanted to bring it up again. >> >> This is the default by design. However, note that in FreeIPA 4.0+ you can >> change that default (permission-mod) and let users or some of the user >> attributes be only shown for authenticated users. >> >> https://www.freeipa.org/page/V4/Permissions_V2 >> >> So, from my POV, this is not a flaw. >> >>> I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted filesystems) to be a part of the domain. I believe this means that I need to expose Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult to force TLS (https://blog.routedlogic.net/?p=119 ) and maybe that's a bad idea under IPA for reasons I thought I'd ask here about. Last year's thread also referenced https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html and I thought I would check to see if that's still necessary under 4.x. >> >> 389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1): >> >> https://fedorahosted.org/freeipa/ticket/4653 >> >> This is an nmap test against the FreeIPA public demo (4.1.x): >> >> $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org >> >> Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST >> Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99) >> Host is up (0.19s latency). >> PORT STATE SERVICE >> 636/tcp open ldapssl >> | ssl-enum-ciphers: >> | TLSv1.2: >> | ciphers: >> | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong >> | TLS_RSA_WITH_AES_128_CBC_SHA - strong >> | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong >> | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong >> | TLS_RSA_WITH_AES_256_CBC_SHA - strong >> | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong >> | TLS_RSA_WITH_RC4_128_MD5 - strong >> | TLS_RSA_WITH_RC4_128_SHA - strong >> | compressors: >> | NULL >> |_ least strength: strong >> >> Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds >> >>> Setting up the firewall to allow cloud networks in is always an option, but if I can get a secure IPA setup going, it would also allow road warriors to kinit and use their credentials for configured intranet sites without having to turn on the VPN (which can really slow things down from remote parts of the globe). >> >> BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to >> offer Kerberos-over-HTTP functionality by default: >> https://fedorahosted.org/freeipa/ticket/4801 >> >> Even now, it can be manually configured. This is what GNOME used: >> https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ >> >> So, if I am reading my notes correctly, there should be no blockers in using >> FreeIPA in your environment. If yes, please let me know. >> >> Martin > From mkosek at redhat.com Mon May 18 14:30:20 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 16:30:20 +0200 Subject: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot In-Reply-To: References: <5559ADCC.8050001@redhat.com> Message-ID: <5559F77C.5000003@redhat.com> On 05/18/2015 02:17 PM, Sina Owolabi wrote: > Hi Martin > > And thanks for getting back, greatly appreciated. > I tore down the replica and reinstalled from scratch, using an old > replica-info file > I had on the primary. Im not sure if this is a good thing to do, but I > would appreciate > if you could point me to the logs you'd be interested in seeing. > I had to reinstall the replica without CA before it would complete, too. > > Thanks again for your precious time. It depends what component you are actually fighting with. There is a separate log for LDAP server, KDC server, Apache and PKI servers. Most directions are specific here http://www.freeipa.org/page/Troubleshooting We need to know first what specific error you are dealing with right now, to point you to right direction. Martin > > On Mon, May 18, 2015 at 10:15 AM, Martin Kosek wrote: >> On 05/16/2015 12:19 PM, Sina Owolabi wrote: >>> Please help me. I am in dire straits, this is the linchpin of our >>> network and we are suffering. >> >> I am sorry for delay in answering, but not many people here show up on the >> weekend. Comments below. >> >>> On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi wrote: >>>> Hi! >>>> >>>> I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, >>>> with the following versions: >>>> libipa_hbac-1.11.6-30.el6_6.4.x86_64 >>>> ipa-server-selinux-3.0.0-42.el6.x86_64 >>>> libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 >>>> ipa-admintools-3.0.0-42.el6.x86_64 >>>> python-iniparse-0.3.1-2.1.el6.noarch >>>> ipa-client-3.0.0-42.el6.x86_64 >>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>> device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 >>>> device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 >>>> ipa-server-3.0.0-42.el6.x86_64 >>>> ipa-python-3.0.0-42.el6.x86_64 >>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>> sssd-ipa-1.11.6-30.el6_6.4.x86_64 >>>> >>>> >>>> I noticed the replica did not seem to be in sync with the primary IPA >>>> server, as login requests to ipa clients using the replica for domain >>>> authentication failed with >>>> "Too many authentication failures for user UNKNOWN". >>>> I forced a sync with the primary server and rebooted the replica afterwards. >>>> Now the replica is back up, but when I run "ipactl status", only >>>> dirsrv is running: >>>> # ipactl status >>>> Directory Service: RUNNING >> >> This is strange, try >> >> # ipactl restart >> >> see which services fail to start and see the logs they produce. >> >>>> No other service shows up. I also tried editing /etc/krb5.conf to >>>> change the [realms] information to point to the primary server, but >>>> while I can now kinit admin, >>>> nothing else works. >>>> >>>> Please how can I fix this problem? >>>> >>>> Please what can I do fix this? >> >> First things first. You need to first see if all service start and operate >> properly, if not, we need to see their logs in order to help or advise. >> >> Martin From lslebodn at redhat.com Mon May 18 14:33:28 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 18 May 2015 16:33:28 +0200 Subject: [Freeipa-users] trusted user groups In-Reply-To: <1efcbde8674c45158b30af7ed10ffa40@TCCCORPEXCH02.TCC.local> References: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> <20150514154532.GK2709@hendrix> <19fca29e79eb4635acddd4a9f3be20d3@TCCCORPEXCH02.TCC.local> <20150514204129.GB11220@mail.corp.redhat.com> <1efcbde8674c45158b30af7ed10ffa40@TCCCORPEXCH02.TCC.local> Message-ID: <20150518143327.GC16916@mail.corp.redhat.com> On (18/05/15 13:55), Andy Thompson wrote: >> -----Original Message----- >> From: Lukas Slebodnik [mailto:lslebodn at redhat.com] >> Sent: Thursday, May 14, 2015 4:41 PM >> To: Andy Thompson >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] trusted user groups >> >> On (14/05/15 15:53), Andy Thompson wrote: >> >> -----Original Message----- >> >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> >> bounces at redhat.com] On Behalf Of Jakub Hrozek >> >> Sent: Thursday, May 14, 2015 11:46 AM >> >> To: freeipa-users at redhat.com >> >> Subject: Re: [Freeipa-users] trusted user groups >> >> >> >> On Thu, May 14, 2015 at 03:33:28PM +0000, Andy Thompson wrote: >> >> > I've noticed that trusted users supplementary ad groups don't show >> >> > up >> >> until after the users login to the box at least once. >> >> >> >> That's expected with the versions you're running. Prior to 6.7, we >> >> could only read the trusted users' group membership from the PAC blob >> >> attached to the Kerberos ticket. >> >> >> >> >> >> > Is there a chance that information will be dropped again at any >> >> > point going >> >> forward? >> >> >> >> No, otherwise it's a bug. >> >> >> >> > >> >> > The reason I ask is that on our sftp boxes we chroot users based on >> >> > group membership. I set that up as an external group in freeIPA >> >> > and the first time the user logs in to the sftp box, they are >> >> > dropped in their normal home directory as opposed to the chroot >> >> > environment. If there is a chance the group membership will not >> >> > show up correctly again in the future, I'm inclined to change the >> >> > chroot stanzas to match on >> >> user as opposed to group. >> >> > >> >> > Is that by design? >> >> >> >> If you can't see the correct group memberships after a login, then >> >> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and >> >> there's so many fixes and enhancements in this area..is there a >> >> chance you could try out 6.7 beta or some custom packages? >> >> >> > >> >Group memberships show up fine after the first login so it is working as >> expected then. The accounts are very controlled so it shouldn't be a huge >> sticking point. I could try out some custom packages on this box but I can't >> move to 6.7 until we upgrade the entire environment. >> > >> Here you are >> https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ >> > >To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. > I'm glad it works for you. >I just can't roll them in production yet :/ > I see. LS From janellenicole80 at gmail.com Mon May 18 14:45:17 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 18 May 2015 09:45:17 -0500 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <20150518142605.GD21881@redhat.com> References: <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> <1431958026.7868.3.camel@redhat.com> <20150518141815.GC21881@redhat.com> <1431958750.7868.4.camel@redhat.com> <20150518142605.GD21881@redhat.com> Message-ID: <20E130CE-9542-48FA-A35F-1E8E1E662FF5@gmail.com> Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. :) ~J From npmccallum at redhat.com Mon May 18 14:47:47 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 18 May 2015 10:47:47 -0400 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <20E130CE-9542-48FA-A35F-1E8E1E662FF5@gmail.com> References: <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> <1431958026.7868.3.camel@redhat.com> <20150518141815.GC21881@redhat.com> <1431958750.7868.4.camel@redhat.com> <20150518142605.GD21881@redhat.com> <20E130CE-9542-48FA-A35F-1E8E1E662FF5@gmail.com> Message-ID: <1431960467.7868.6.camel@redhat.com> On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: > Ok, let me ask this a different way, because maybe there is a way, > and I am just not seeing it. > > I have 2 datacenters with typical bastions in each. I have enabled > OTP and that works fine via ssh. But the user has to login to both > and opening ssh tunnels is problematic at best. > > Using all the creativity in this list, maybe someone knows of another > way to have a user authenticate from a Mac where they would only have > to do it once to get their ticket? > > I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel From Andy.Thompson at e-tcc.com Mon May 18 14:50:12 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Mon, 18 May 2015 14:50:12 +0000 Subject: [Freeipa-users] trusted user groups In-Reply-To: <20150518143327.GC16916@mail.corp.redhat.com> References: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> <20150514154532.GK2709@hendrix> <19fca29e79eb4635acddd4a9f3be20d3@TCCCORPEXCH02.TCC.local> <20150514204129.GB11220@mail.corp.redhat.com> <1efcbde8674c45158b30af7ed10ffa40@TCCCORPEXCH02.TCC.local> <20150518143327.GC16916@mail.corp.redhat.com> Message-ID: > -----Original Message----- > From: Lukas Slebodnik [mailto:lslebodn at redhat.com] > Sent: Monday, May 18, 2015 10:33 AM > To: Andy Thompson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trusted user groups > > On (18/05/15 13:55), Andy Thompson wrote: > >> -----Original Message----- > >> From: Lukas Slebodnik [mailto:lslebodn at redhat.com] > >> Sent: Thursday, May 14, 2015 4:41 PM > >> To: Andy Thompson > >> Cc: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] trusted user groups > >> > >> On (14/05/15 15:53), Andy Thompson wrote: > >> >> -----Original Message----- > >> >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >> >> bounces at redhat.com] On Behalf Of Jakub Hrozek > >> >> Sent: Thursday, May 14, 2015 11:46 AM > >> >> To: freeipa-users at redhat.com > >> >> Subject: Re: [Freeipa-users] trusted user groups > >> >> > >> >> On Thu, May 14, 2015 at 03:33:28PM +0000, Andy Thompson wrote: > >> >> > I've noticed that trusted users supplementary ad groups don't > >> >> > show up > >> >> until after the users login to the box at least once. > >> >> > >> >> That's expected with the versions you're running. Prior to 6.7, we > >> >> could only read the trusted users' group membership from the PAC > >> >> blob attached to the Kerberos ticket. > >> >> > >> >> > >> >> > Is there a chance that information will be dropped again at any > >> >> > point going > >> >> forward? > >> >> > >> >> No, otherwise it's a bug. > >> >> > >> >> > > >> >> > The reason I ask is that on our sftp boxes we chroot users based > >> >> > on group membership. I set that up as an external group in > >> >> > freeIPA and the first time the user logs in to the sftp box, > >> >> > they are dropped in their normal home directory as opposed to > >> >> > the chroot environment. If there is a chance the group > >> >> > membership will not show up correctly again in the future, I'm > >> >> > inclined to change the chroot stanzas to match on > >> >> user as opposed to group. > >> >> > > >> >> > Is that by design? > >> >> > >> >> If you can't see the correct group memberships after a login, then > >> >> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 > >> >> and there's so many fixes and enhancements in this area..is there > >> >> a chance you could try out 6.7 beta or some custom packages? > >> >> > >> > > >> >Group memberships show up fine after the first login so it is > >> >working as > >> expected then. The accounts are very controlled so it shouldn't be a > >> huge sticking point. I could try out some custom packages on this > >> box but I can't move to 6.7 until we upgrade the entire environment. > >> > > >> Here you are > >> https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ > >> > > > >To just bring this full circle, the latest sssd release reads group membership > correctly without a Kerberos ticket. I tested this release on 6.6 and tested a > 7.1 box and both worked without issue. > > > I'm glad it works for you. > > >I just can't roll them in production yet :/ > > > I see. > You have any insight into when 6.7 will be released? From rmeggins at redhat.com Mon May 18 14:55:54 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 18 May 2015 08:55:54 -0600 Subject: [Freeipa-users] Securing IPA Redux In-Reply-To: <5559F6A5.7070906@redhat.com> References: <7B765750-7688-4643-B86E-27F40E8582E0@gmail.com> <5559AC6E.5060607@redhat.com> <14071628-9A9D-4D2F-8C23-03E342530B93@gmail.com> <5559F6A5.7070906@redhat.com> Message-ID: <5559FD7A.3050300@redhat.com> On 05/18/2015 08:26 AM, Martin Kosek wrote: > Adding freeipa-users list back, to keep others in the loop. > > On 05/18/2015 12:32 PM, Brian Topping wrote: >> Thanks for taking the time to write that, Martin. It's good to have a reference to build from. >> >> Result of "ida-client-install" outside the firewall with port 636 accessible: > Ah, I mostly just use 636 as a convenience port to show the supported cryptos, > 389 is really the port we should be using by default. > > Of course, 389 port + STARTTLS environment turned on, to make sure passwords do > not go in clean over the wire. > >>> Please make sure the following ports are opened in the firewall settings: >>> TCP: 80, 88, 389 >>> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) >>> Also note that following ports are necessary for ipa-client working properly after enrollment: >>> TCP: 464 >>> UDP: 464, 123 (if NTP enabled) >> No mention of 636, confirmed by tcpdump that it's not trying. Also no option on command line to specify 636. >> >> Opening up 389 means that some misconfigured client could expose passwords. Not necessarily. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections >> It's possible to remove null ciphers, but then there's really no reason not to use 636. >> >> Seems like ipa-client-install should try 636 by default, then fall back to 389 in it's various forms, no? > I think the general direction here was the opposite. To work on the port 389 as > the common denominator, offering both password-less traffic and encrypted > traffic. I am not sure if there were other reasons too, I would let Rob or > Ludwig reply here if they know. > > Martin > >>> On May 18, 2015, at 4:10 PM, Martin Kosek wrote: >>> >>> On 05/15/2015 01:33 PM, Brian Topping wrote: >>>> In the (apparently) first message to the list in 2014, https://www.redhat.com/archives/freeipa-users/2014-January/msg00000.html addressed questions about securing IPA and I don't see much other talk about it. Now that 4.x is prevalent, I wanted to bring it up again. >>> This is the default by design. However, note that in FreeIPA 4.0+ you can >>> change that default (permission-mod) and let users or some of the user >>> attributes be only shown for authenticated users. >>> >>> https://www.freeipa.org/page/V4/Permissions_V2 >>> >>> So, from my POV, this is not a flaw. >>> >>>> I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted filesystems) to be a part of the domain. I believe this means that I need to expose Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult to force TLS (https://blog.routedlogic.net/?p=119 ) and maybe that's a bad idea under IPA for reasons I thought I'd ask here about. Last year's thread also referenced https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html and I thought I would check to see if that's still necessary under 4.x. >>> 389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1): >>> >>> https://fedorahosted.org/freeipa/ticket/4653 >>> >>> This is an nmap test against the FreeIPA public demo (4.1.x): >>> >>> $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org >>> >>> Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST >>> Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99) >>> Host is up (0.19s latency). >>> PORT STATE SERVICE >>> 636/tcp open ldapssl >>> | ssl-enum-ciphers: >>> | TLSv1.2: >>> | ciphers: >>> | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong >>> | TLS_RSA_WITH_AES_128_CBC_SHA - strong >>> | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong >>> | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong >>> | TLS_RSA_WITH_AES_256_CBC_SHA - strong >>> | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong >>> | TLS_RSA_WITH_RC4_128_MD5 - strong >>> | TLS_RSA_WITH_RC4_128_SHA - strong >>> | compressors: >>> | NULL >>> |_ least strength: strong >>> >>> Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds >>> >>>> Setting up the firewall to allow cloud networks in is always an option, but if I can get a secure IPA setup going, it would also allow road warriors to kinit and use their credentials for configured intranet sites without having to turn on the VPN (which can really slow things down from remote parts of the globe). >>> BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to >>> offer Kerberos-over-HTTP functionality by default: >>> https://fedorahosted.org/freeipa/ticket/4801 >>> >>> Even now, it can be manually configured. This is what GNOME used: >>> https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ >>> >>> So, if I am reading my notes correctly, there should be no blockers in using >>> FreeIPA in your environment. If yes, please let me know. >>> >>> Martin From mkosek at redhat.com Mon May 18 14:58:59 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 16:58:59 +0200 Subject: [Freeipa-users] trusted user groups In-Reply-To: References: <0909e1bb8d614a7eb0eea4e1db962af0@TCCCORPEXCH02.TCC.local> <20150514154532.GK2709@hendrix> <19fca29e79eb4635acddd4a9f3be20d3@TCCCORPEXCH02.TCC.local> <20150514204129.GB11220@mail.corp.redhat.com> <1efcbde8674c45158b30af7ed10ffa40@TCCCORPEXCH02.TCC.local> <20150518143327.GC16916@mail.corp.redhat.com> Message-ID: <5559FE33.2050508@redhat.com> On 05/18/2015 04:50 PM, Andy Thompson wrote: >> -----Original Message----- >> From: Lukas Slebodnik [mailto:lslebodn at redhat.com] >> Sent: Monday, May 18, 2015 10:33 AM >> To: Andy Thompson >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] trusted user groups >> >> On (18/05/15 13:55), Andy Thompson wrote: >>>> -----Original Message----- >>>> From: Lukas Slebodnik [mailto:lslebodn at redhat.com] >>>> Sent: Thursday, May 14, 2015 4:41 PM >>>> To: Andy Thompson >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] trusted user groups >>>> >>>> On (14/05/15 15:53), Andy Thompson wrote: >>>>>> -----Original Message----- >>>>>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>>>>> bounces at redhat.com] On Behalf Of Jakub Hrozek >>>>>> Sent: Thursday, May 14, 2015 11:46 AM >>>>>> To: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] trusted user groups >>>>>> >>>>>> On Thu, May 14, 2015 at 03:33:28PM +0000, Andy Thompson wrote: >>>>>>> I've noticed that trusted users supplementary ad groups don't >>>>>>> show up >>>>>> until after the users login to the box at least once. >>>>>> >>>>>> That's expected with the versions you're running. Prior to 6.7, we >>>>>> could only read the trusted users' group membership from the PAC >>>>>> blob attached to the Kerberos ticket. >>>>>> >>>>>> >>>>>>> Is there a chance that information will be dropped again at any >>>>>>> point going >>>>>> forward? >>>>>> >>>>>> No, otherwise it's a bug. >>>>>> >>>>>>> >>>>>>> The reason I ask is that on our sftp boxes we chroot users based >>>>>>> on group membership. I set that up as an external group in >>>>>>> freeIPA and the first time the user logs in to the sftp box, >>>>>>> they are dropped in their normal home directory as opposed to >>>>>>> the chroot environment. If there is a chance the group >>>>>>> membership will not show up correctly again in the future, I'm >>>>>>> inclined to change the chroot stanzas to match on >>>>>> user as opposed to group. >>>>>>> >>>>>>> Is that by design? >>>>>> >>>>>> If you can't see the correct group memberships after a login, then >>>>>> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 >>>>>> and there's so many fixes and enhancements in this area..is there >>>>>> a chance you could try out 6.7 beta or some custom packages? >>>>>> >>>>> >>>>> Group memberships show up fine after the first login so it is >>>>> working as >>>> expected then. The accounts are very controlled so it shouldn't be a >>>> huge sticking point. I could try out some custom packages on this >>>> box but I can't move to 6.7 until we upgrade the entire environment. >>>>> >>>> Here you are >>>> https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ >>>> >>> >>> To just bring this full circle, the latest sssd release reads group membership >> correctly without a Kerberos ticket. I tested this release on 6.6 and tested a >> 7.1 box and both worked without issue. >>> >> I'm glad it works for you. >> >>> I just can't roll them in production yet :/ >>> >> I see. >> > > You have any insight into when 6.7 will be released? We cannot give any exact date at the moment, but given that 6.7 Beta is already out, the GA should be out summer-ish. You can try to use the Beta packages now or wait until it really hits GA. HTH, Martin From vangass at gazeta.pl Mon May 18 15:11:01 2015 From: vangass at gazeta.pl (Vangass) Date: Mon, 18 May 2015 17:11:01 +0200 Subject: [Freeipa-users] LDAP uid to cn modify In-Reply-To: <5559F149.9040500@redhat.com> References: <5559F149.9040500@redhat.com> Message-ID: Yes, I saw that discussion but there is no solution. So how to create compat tree? In my ldap there is somenting like "uid=bartosz,cn=users,cn=compat,dc=example,dc=com" - but it is still with uid. PS. I have fresh instalation CentOS 7.1 and IPA 4.1. 2015-05-18 16:03 GMT+02:00 Rob Crittenden : > Vangass wrote: > >> Hi, >> >> I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO >> client sends dn as "cn=bartosz,cn=users,cn=accounts,dc=example,dc=com" >> but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other >> user I create is uid). Is it possible to modify uid to cn or is there >> any other option? >> >> Thanks, >> Bartosz Witkowski >> >> >> > Others have had the same issue, > https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html > > If you are running EL 7+ you should be able to create a compat > configuration to make it work but it isn't clear if anyone has done this > work on IPA 3.3+ or not yet (IIRC the users in this thread were all still > on RHEL 6). > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.topping at gmail.com Mon May 18 15:12:02 2015 From: brian.topping at gmail.com (Brian Topping) Date: Mon, 18 May 2015 22:12:02 +0700 Subject: [Freeipa-users] Securing IPA Redux In-Reply-To: <5559FD7A.3050300@redhat.com> References: <7B765750-7688-4643-B86E-27F40E8582E0@gmail.com> <5559AC6E.5060607@redhat.com> <14071628-9A9D-4D2F-8C23-03E342530B93@gmail.com> <5559F6A5.7070906@redhat.com> <5559FD7A.3050300@redhat.com> Message-ID: > On May 18, 2015, at 9:55 PM, Rich Megginson > wrote: > > Not necessarily. > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections I think that covers what I need in combination with what Martin previously provided. Thanks guys! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From janellenicole80 at gmail.com Mon May 18 15:46:45 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 18 May 2015 10:46:45 -0500 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <1431960467.7868.6.camel@redhat.com> References: <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> <1431958026.7868.3.camel@redhat.com> <20150518141815.GC21881@redhat.com> <1431958750.7868.4.camel@redhat.com> <20150518142605.GD21881@redhat.com> <20E130CE-9542-48FA-A35F-1E8E1E662FF5@gmail.com> <1431960467.7868.6.camel@redhat.com> Message-ID: > On May 18, 2015, at 09:47, Nathaniel McCallum wrote: > >> On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: >> Ok, let me ask this a different way, because maybe there is a way, >> and I am just not seeing it. >> >> I have 2 datacenters with typical bastions in each. I have enabled >> OTP and that works fine via ssh. But the user has to login to both >> and opening ssh tunnels is problematic at best. >> >> Using all the creativity in this list, maybe someone knows of another >> way to have a user authenticate from a Mac where they would only have >> to do it once to get their ticket? >> >> I guess I can't think of anything, but no harm in asking. > > Without support for the OTP pre-authentication mechanism, I don't know > of any way to do this while still retaining the security properties of > Kerberos. Basically, you'll have to hand over your password to a third > party (which has OTP support). This is ill advised. > > Nathaniel Excellent point. Thanks for all the tips and advice. And of course for a great product that continues to get better. ~J From notify.sina at gmail.com Mon May 18 16:17:57 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 18 May 2015 17:17:57 +0100 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <5559F1B6.4030207@redhat.com> References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> Message-ID: Hi Rob There are some logs in /var/log/pki-ca/catalina.out that appear to indicate a problem: CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. SEVERE: A web application appears to have started a thread named [Timer-0] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/signedAudit/ca_audit.flush-3] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/signedAudit/ca_audit.rollover-4] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/system.flush-5] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/system.rollover-6] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/transactions.flush-7] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/transactions.rollover-8] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/selftests.log.flush-9] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/selftests.log.rollover-10] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-2 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-3 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-4 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-5 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-6 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-8 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads May 24, 2013 11:48:10 AM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib SEVERE: A web application created a ThreadLocal with key of type [null] (value [com.netscape.cmscore.util.Debug$1 at 7e8905bd]) and a value of type [java.text.SimpleDateFormat] (value [java.text.SimpleDateFormat at d1b317c9]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. May 24, 2013 12:17:01 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [null] (value [com.netscape.cmscore.util.Debug$1 at 7e8905bd]) and a value of type [java.text.SimpleDateFormat] (value [java.text.SimpleDateFormat at d1b317c9]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. May 24, 2013 12:17:01 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [null] (value [com.netscape.cmscore.util.Debug$1 at 7e8905bd]) and a value of type [java.text.SimpleDateFormat] (value [java.text.SimpleDateFormat at d1b317c9]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Also running "getcert list" tells me there are two expired certs: Request ID '20130524104636': status: CA_UNREACHABLE ca-error: Server at https://dc.ourdom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no Request ID '20130524104828': status: CA_UNREACHABLE ca-error: Server at https://dc.ourdom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no I'd be grateful to know what to do. On Mon, May 18, 2015 at 3:05 PM, Rob Crittenden wrote: > Sina Owolabi wrote: >> >> Yes CA is running, and it's on the same machine. >> >> [root at dc ~]# ipa-replica-prepare dc01.ourdom.com >> --ip-address 192.168.2.40 >> >> Directory Manager (existing master) password: >> >> >> Preparing replica for dc01.ourdom.com from >> dc.ourdom.com >> >> Creating SSL certificate for the Directory Server >> >> Certificate operation cannot be completed: Unable to communicate with >> CMS (Not Found) >> >> [root at dc ~]# ipactl status >> >> Directory Service: RUNNING >> >> KDC Service: RUNNING >> >> KPASSWD Service: RUNNING >> >> DNS Service: RUNNING >> >> MEMCACHE Service: RUNNING >> >> HTTP Service: RUNNING >> >> CA Service: RUNNING >> >> [root at dc ~]# > > > This suggests that while the process is running the CA isn't actually > operational. You'll need to poke through the logs in /var/log/pki* to see if > there are any errors. > > I'd also see if the certificates are expired by running `getcert list` as > root. > > rob > From thewebbie at gmail.com Mon May 18 16:38:47 2015 From: thewebbie at gmail.com (thewebbie) Date: Mon, 18 May 2015 12:38:47 -0400 Subject: [Freeipa-users] Apache htaccess replacement Message-ID: Hello I have been attempting to use my 4.1.4 FreeIPA server to authenticate folders on a web server as a replacement for the normal htaccess feature. I do require group authentication. I have tried just about online example and have only been able to get basic ldap and basic kerbos authentication. How do I go about getting group based authentication working. I have tried to add the following to either example below and no luck. I added the httpbind user from an ldif file from examples. I created a user group named htaccess and added the users to it. AuthLDAPBindDN uid=httpbind,cn=sysaccounts,cn=etc,dc=test,dc=com AuthLDAPBindPassword XXXXXXXXXX AuthLDAPGroupAttributeIsDN off AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?uid Require ldap-group cn=htaccess,cn=groups,cn=compat,dc=test,dc=com My error logs look like [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(1944): [client xxx.xxx.xxx.xxx] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(1032): [client xxx.xxx.xxx.xxx] Using HTTP/server1.test.com at test.COM as server principal for password verification [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(736): [client xxx.xxx.xxx.xxx] Trying to get TGT for user jsnow at test.COM [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(646): [client xxx.xxx.xxx.xxx] Trying to verify authenticity of KDC using principal HTTP/server1.test.com at test.COM [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(1111): [client xxx.xxx.xxx.xxx] kerb_authenticate_user_krb5pwd ret=0 user=jsnow at test.COM authtype=Basic [Mon May 18 14:31:19 2015] [debug] mod_authnz_ldap.c(727): [client xxx.xxx.xxx.xxx] ldap authorize: Creating LDAP req structure [Mon May 18 14:31:19 2015] [debug] mod_authnz_ldap.c(739): [client xxx.xxx.xxx.xxx] auth_ldap authorise: User DN not found, LDAP: ldap_simple_bind_s() failed I have this working. SSLRequireSSL AuthName "LDAP Authentication" AuthType Basic AuthzLDAPMethod ldap AuthzLDAPServer ipa.test.com AuthzLDAPUserBase cn=users,cn=compat,dc=test,dc=com AuthzLDAPUserKey uid AuthzLDAPUserScope base require valid-user And this is working SSLRequireSSL AuthName "KERBEROS Authentication" AuthType Kerberos KrbServiceName HTTP KrbMethodK5Passwd On KrbSaveCredentials On KrbMethodNegotiate On KrbAuthRealms TEST.COM Krb5KeyTab /etc/httpd/conf.d/keytab AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?krbPrincipalName Require valid-user -- ================= Matthew Feinberg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon May 18 17:53:22 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 May 2015 13:53:22 -0400 Subject: [Freeipa-users] Securing IPA Redux In-Reply-To: <5559FD7A.3050300@redhat.com> References: <7B765750-7688-4643-B86E-27F40E8582E0@gmail.com> <5559AC6E.5060607@redhat.com> <14071628-9A9D-4D2F-8C23-03E342530B93@gmail.com> <5559F6A5.7070906@redhat.com> <5559FD7A.3050300@redhat.com> Message-ID: <555A2712.8@redhat.com> Rich Megginson wrote: > On 05/18/2015 08:26 AM, Martin Kosek wrote: >> Adding freeipa-users list back, to keep others in the loop. >> >> On 05/18/2015 12:32 PM, Brian Topping wrote: >>> Thanks for taking the time to write that, Martin. It's good to have a >>> reference to build from. >>> >>> Result of "ida-client-install" outside the firewall with port 636 >>> accessible: >> Ah, I mostly just use 636 as a convenience port to show the supported >> cryptos, >> 389 is really the port we should be using by default. >> >> Of course, 389 port + STARTTLS environment turned on, to make sure >> passwords do >> not go in clean over the wire. >> >>>> Please make sure the following ports are opened in the firewall >>>> settings: >>>> TCP: 80, 88, 389 >>>> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) >>>> Also note that following ports are necessary for ipa-client working >>>> properly after enrollment: >>>> TCP: 464 >>>> UDP: 464, 123 (if NTP enabled) >>> No mention of 636, confirmed by tcpdump that it's not trying. Also no >>> option on command line to specify 636. >>> >>> Opening up 389 means that some misconfigured client could expose >>> passwords. > > Not necessarily. > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections > > >>> It's possible to remove null ciphers, but then there's really no >>> reason not to use 636. >>> >>> Seems like ipa-client-install should try 636 by default, then fall >>> back to 389 in it's various forms, no? >> I think the general direction here was the opposite. To work on the >> port 389 as >> the common denominator, offering both password-less traffic and encrypted >> traffic. I am not sure if there were other reasons too, I would let >> Rob or >> Ludwig reply here if they know. ldaps / port 636 is deprecated in favor of StartTLS. For OpenLDAP's take on it see http://www.openldap.org/faq/data/cache/605.html rob From rcritten at redhat.com Mon May 18 17:55:08 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 May 2015 13:55:08 -0400 Subject: [Freeipa-users] LDAP uid to cn modify In-Reply-To: References: <5559F149.9040500@redhat.com> Message-ID: <555A277C.5050306@redhat.com> Vangass wrote: > Yes, I saw that discussion but there is no solution. > So how to create compat tree? > In my ldap there is somenting like > "uid=bartosz,cn=users,cn=compat,dc=example,dc=com" - but it is still > with uid. > PS. I have fresh instalation CentOS 7.1 and IPA 4.1. Take a look at /usr/share/doc/slapi-nis/sch-getting-started.txt You'll need to write your own set of rules to create new compat tree entries. rob > > 2015-05-18 16:03 GMT+02:00 Rob Crittenden >: > > Vangass wrote: > > Hi, > > I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO > client sends dn as > "cn=bartosz,cn=users,cn=accounts,dc=example,dc=com" > but in FreeIPA there is no cn=bartosz just uid=bartosz (as for > any other > user I create is uid). Is it possible to modify uid to cn or is > there > any other option? > > Thanks, > Bartosz Witkowski > > > > Others have had the same issue, > https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html > > If you are running EL 7+ you should be able to create a compat > configuration to make it work but it isn't clear if anyone has done > this work on IPA 3.3+ or not yet (IIRC the users in this thread were > all still on RHEL 6). > > rob > > > > From rcritten at redhat.com Mon May 18 18:00:19 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 May 2015 14:00:19 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> Message-ID: <555A28B3.8080503@redhat.com> Sina Owolabi wrote: > Hi Rob > > There are some logs in /var/log/pki-ca/catalina.out that appear to > indicate a problem: [SNIP] These are mostly white noise from tomcat and can be ignored. > > > Also running "getcert list" tells me there are two expired certs: > > Request ID '20130524104636': > status: CA_UNREACHABLE > ca-error: Server at https://dc.ourdom.com/ipa/xml failed > request, will retry: 907 (RPC failed at server. cannot connect to > 'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno > -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your > certificate as expired.). > stuck: no > > > Request ID '20130524104828': > status: CA_UNREACHABLE > ca-error: Server at https://dc.ourdom.com/ipa/xml failed > request, will retry: 907 (RPC failed at server. cannot connect to > 'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno > -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your > certificate as expired.). > stuck: no > > I'd be grateful to know what to do. Your CA subsystem certificates are expired so while the process is up the CA won't serve requests. See http://www.freeipa.org/page/Howto/CA_Certificate_Renewal rob From janellenicole80 at gmail.com Mon May 18 20:04:02 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 18 May 2015 13:04:02 -0700 Subject: [Freeipa-users] interesting Kerberos issue In-Reply-To: <1431960467.7868.6.camel@redhat.com> References: <1430787978.4335.7.camel@redhat.com> <55481F15.9090507@gmail.com> <5548C9E6.6050306@redhat.com> <554FFB7A.1040701@gmail.com> <20150511065759.GA5152@redhat.com> <5559EB76.9080100@gmail.com> <20150518140318.GB21881@redhat.com> <1431958026.7868.3.camel@redhat.com> <20150518141815.GC21881@redhat.com> <1431958750.7868.4.camel@redhat.com> <20150518142605.GD21881@redhat.com> <20E130CE-9542-48FA-A35F-1E8E1E662FF5@gmail.com> <1431960467.7868.6.camel@redhat.com> Message-ID: <555A45B2.9090607@gmail.com> On 5/18/15 7:47 AM, Nathaniel McCallum wrote: > On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: >> Ok, let me ask this a different way, because maybe there is a way, >> and I am just not seeing it. >> >> I have 2 datacenters with typical bastions in each. I have enabled >> OTP and that works fine via ssh. But the user has to login to both >> and opening ssh tunnels is problematic at best. >> >> Using all the creativity in this list, maybe someone knows of another >> way to have a user authenticate from a Mac where they would only have >> to do it once to get their ticket? >> >> I guess I can't think of anything, but no harm in asking. > Without support for the OTP pre-authentication mechanism, I don't know > of any way to do this while still retaining the security properties of > Kerberos. Basically, you'll have to hand over your password to a third > party (which has OTP support). This is ill advised. > > Nathaniel Going to see about installing MIT version from source on Yosemite and see what happens.. Current is 1.13.2 Will let you know ~J From janellenicole80 at gmail.com Tue May 19 01:23:15 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 18 May 2015 18:23:15 -0700 Subject: [Freeipa-users] replication again :-( Message-ID: <555A9083.5010804@gmail.com> Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run "ipa user-show --all username" on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J From janellenicole80 at gmail.com Tue May 19 01:42:40 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 18 May 2015 18:42:40 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555A9083.5010804@gmail.com> References: <555A9083.5010804@gmail.com> Message-ID: <555A9510.6040403@gmail.com> On 5/18/15 6:23 PM, Janelle wrote: > Once again, replication/sync has been lost. I really wish the product > was more stable, it is so much potential and yet. > > Servers running for 6 days no issues. No new accounts or changes > (maybe a few users changing passwords) and again, 5 out of 16 servers > are no longer in sync. > > I can test it easily by adding an account and then waiting a few > minutes, then run "ipa user-show --all username" on all the servers, > and only a few of them have the account. I have now waited 15 > minutes, still no luck. > > Oh well.. I guess I will go look at alternatives. I had such high > hopes for this tool. Thanks so much everyone for all your help in > trying to get things stable, but for whatever reason, there is a > random loss of sync among the servers and obviously this is not > acceptable. > > regards > ~J A new error: [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: Invalid credentials] From dewanggaba at xtremenitro.org Tue May 19 02:04:43 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Tue, 19 May 2015 09:04:43 +0700 Subject: [Freeipa-users] Reinstall ipa client, problem with old CA Message-ID: <555A9A3B.7050301@xtremenitro.org> Hello! I'm trying to reinstall ipa client, but have a problem with old/existing ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA server still on development and always reinstalled, I need to reproduce any possible problem/error on FreeIPA 4.x on CentOS 7. The error was : LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Currently, I was renamed ca.crt to ca.crt.old and the ipa client successfully reconnected to new FreeIPA Server using dns discovery. Is it normal? And why the ipa-client-install --uninstall didn't completely remove the old ca.crt? Thank you. From mkosek at redhat.com Tue May 19 05:47:48 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 07:47:48 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555A9083.5010804@gmail.com> References: <555A9083.5010804@gmail.com> Message-ID: <555ACE84.3030105@redhat.com> On 05/19/2015 03:23 AM, Janelle wrote: > Once again, replication/sync has been lost. I really wish the product was more > stable, it is so much potential and yet. > > Servers running for 6 days no issues. No new accounts or changes (maybe a few > users changing passwords) and again, 5 out of 16 servers are no longer in sync. > > I can test it easily by adding an account and then waiting a few minutes, then > run "ipa user-show --all username" on all the servers, and only a few of them > have the account. I have now waited 15 minutes, still no luck. > > Oh well.. I guess I will go look at alternatives. I had such high hopes for > this tool. Thanks so much everyone for all your help in trying to get things > stable, but for whatever reason, there is a random loss of sync among the > servers and obviously this is not acceptable. Hello Janelle, I am very sorry to hear about your troubles. Would you be still OK with helping us (mostly Ludwig and Thierry) investigate what is the root cause of the instability of the replication agreements? This is obviously something that should not be happening at this rate as in your deployment, so I would really like to be able to identity and fix this issue in the 389 DS. From mkosek at redhat.com Tue May 19 05:53:38 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 07:53:38 +0200 Subject: [Freeipa-users] Reinstall ipa client, problem with old CA In-Reply-To: <555A9A3B.7050301@xtremenitro.org> References: <555A9A3B.7050301@xtremenitro.org> Message-ID: <555ACFE2.60808@redhat.com> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: > Hello! > > I'm trying to reinstall ipa client, but have a problem with old/existing > ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA > server still on development and always reinstalled, I need to reproduce > any possible problem/error on FreeIPA 4.x on CentOS 7. > > The error was : > LDAP Error: Connect error: TLS error -8054:You are attempting to import > a cert with the same issuer/serial as an existing cert, but that is not > the same cert. > > Currently, I was renamed ca.crt to ca.crt.old and the ipa client > successfully reconnected to new FreeIPA Server using dns discovery. > > Is it normal? And why the ipa-client-install --uninstall didn't > completely remove the old ca.crt? Hello, ipa-client-install uninstall the CA certificate properly since FreeIPA 3.2. This is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3537 CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x versions, you need to delete the certificate manually if you reinstalled the IPA server. HTH, Martin From tbordaz at redhat.com Tue May 19 06:58:07 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 19 May 2015 08:58:07 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555ACE84.3030105@redhat.com> References: <555A9083.5010804@gmail.com> <555ACE84.3030105@redhat.com> Message-ID: <555ADEFF.5090304@redhat.com> On 05/19/2015 07:47 AM, Martin Kosek wrote: > On 05/19/2015 03:23 AM, Janelle wrote: >> Once again, replication/sync has been lost. I really wish the product >> was more >> stable, it is so much potential and yet. >> >> Servers running for 6 days no issues. No new accounts or changes >> (maybe a few >> users changing passwords) and again, 5 out of 16 servers are no >> longer in sync. >> >> I can test it easily by adding an account and then waiting a few >> minutes, then >> run "ipa user-show --all username" on all the servers, and only a >> few of them >> have the account. I have now waited 15 minutes, still no luck. >> >> Oh well.. I guess I will go look at alternatives. I had such high >> hopes for >> this tool. Thanks so much everyone for all your help in trying to get >> things >> stable, but for whatever reason, there is a random loss of sync among >> the >> servers and obviously this is not acceptable. > > Hello Janelle, > > I am very sorry to hear about your troubles. Would you be still OK > with helping us (mostly Ludwig and Thierry) investigate what is the > root cause of the instability of the replication agreements? This is > obviously something that should not be happening at this rate as in > your deployment, so I would really like to be able to identity and fix > this issue in the 389 DS. Hello Janelle, I can only join my voice to Martin to say how I am sorry to read this. Would you turn on replication logging level (8192) on the master/consumer and provide us the logs(access/error) and config (dse.ldif). The master is the instance where you can see the update and the that is linked (replica agreement) to a replica(aka consumer) where the update is not received. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Tue May 19 07:04:09 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 19 May 2015 09:04:09 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555A9510.6040403@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> Message-ID: <555AE069.4010901@redhat.com> On 05/19/2015 03:42 AM, Janelle wrote: > On 5/18/15 6:23 PM, Janelle wrote: >> Once again, replication/sync has been lost. I really wish the product >> was more stable, it is so much potential and yet. >> >> Servers running for 6 days no issues. No new accounts or changes >> (maybe a few users changing passwords) and again, 5 out of 16 servers >> are no longer in sync. >> >> I can test it easily by adding an account and then waiting a few >> minutes, then run "ipa user-show --all username" on all the servers, >> and only a few of them have the account. I have now waited 15 >> minutes, still no luck. >> >> Oh well.. I guess I will go look at alternatives. I had such high >> hopes for this tool. Thanks so much everyone for all your help in >> trying to get things stable, but for whatever reason, there is a >> random loss of sync among the servers and obviously this is not >> acceptable. >> >> regards >> ~J > A new error: > > [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: > Invalid credentials] > > can you see the update on ipa03.example.com ? It is looking like the replica agreement from this host is failing to bind to a replica. This could explain why the replica do not receive the update (disabled account, password/certificate expiration, ...) Again logs/config would help. thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Tue May 19 07:17:45 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 19 May 2015 09:17:45 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555ADEFF.5090304@redhat.com> References: <555A9083.5010804@gmail.com> <555ACE84.3030105@redhat.com> <555ADEFF.5090304@redhat.com> Message-ID: <555AE399.1050901@redhat.com> On 05/19/2015 08:58 AM, thierry bordaz wrote: > On 05/19/2015 07:47 AM, Martin Kosek wrote: >> On 05/19/2015 03:23 AM, Janelle wrote: >>> Once again, replication/sync has been lost. I really wish the >>> product was more >>> stable, it is so much potential and yet. >>> >>> Servers running for 6 days no issues. No new accounts or changes >>> (maybe a few >>> users changing passwords) and again, 5 out of 16 servers are no >>> longer in sync. >>> >>> I can test it easily by adding an account and then waiting a few >>> minutes, then >>> run "ipa user-show --all username" on all the servers, and only a >>> few of them >>> have the account. I have now waited 15 minutes, still no luck. >>> >>> Oh well.. I guess I will go look at alternatives. I had such high >>> hopes for >>> this tool. Thanks so much everyone for all your help in trying to >>> get things >>> stable, but for whatever reason, there is a random loss of sync >>> among the >>> servers and obviously this is not acceptable. >> >> Hello Janelle, >> >> I am very sorry to hear about your troubles. Would you be still OK >> with helping us (mostly Ludwig and Thierry) investigate what is the >> root cause of the instability of the replication agreements? This is >> obviously something that should not be happening at this rate as in >> your deployment, so I would really like to be able to identity and >> fix this issue in the 389 DS. > Hello Janelle, > > I can only join my voice to Martin to say how I am sorry to read this. > Would you turn on replication logging level (8192) on the > master/consumer and provide us the logs(access/error) and config > (dse.ldif). > The master is the instance where you can see the update and the that > is linked (replica agreement) to a replica(aka consumer) where the > update is not received. what puzzles me most, is that replication is working for quite some time and then breaks, so we need to find out about the dynamics which lead to that state. You reported errors about invalid credentials or about a bind dn entry not found, these credentials don't get changed by ds or entries are not deleted by ds, so what triggers these changes. also for the suggestion by Thierry to debug, we need to determine where replication breaks, if you add an account and it is propageted to some servers and not to others, where does it stop ? This depends on your replication topology, you said in anotehr post that you have a ring topology, does it mean all 16 servers are conencted in a ring only, and if two links break the topology is disconnected ? > > thanks > thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Tue May 19 08:03:15 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 19 May 2015 10:03:15 +0200 Subject: [Freeipa-users] Apache htaccess replacement In-Reply-To: References: Message-ID: <20150519080315.GK6587@redhat.com> On Mon, May 18, 2015 at 12:38:47PM -0400, thewebbie wrote: > > I have been attempting to use my 4.1.4 FreeIPA server to authenticate > folders on a web server as a replacement for the normal htaccess feature. I > do require group authentication. I have tried just about online example and > have only been able to get basic ldap and basic kerbos authentication. How > do I go about getting group based authentication working. If you do not insist on group based authentication but can use the more generic host-based access control (which you should be able to do because you have IPA), you can use mod_authnz_pam: http://www.adelton.com/apache/mod_authnz_pam/ http://www.freeipa.org/page/Web_App_Authentication The module is packaged in Fedoras, RHEL, and CentOS. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From dkupka at redhat.com Tue May 19 08:21:31 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 19 May 2015 10:21:31 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555AE069.4010901@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> Message-ID: <555AF28B.9010407@redhat.com> On 05/19/2015 09:04 AM, thierry bordaz wrote: > On 05/19/2015 03:42 AM, Janelle wrote: >> On 5/18/15 6:23 PM, Janelle wrote: >>> Once again, replication/sync has been lost. I really wish the product >>> was more stable, it is so much potential and yet. >>> >>> Servers running for 6 days no issues. No new accounts or changes >>> (maybe a few users changing passwords) and again, 5 out of 16 servers >>> are no longer in sync. >>> >>> I can test it easily by adding an account and then waiting a few >>> minutes, then run "ipa user-show --all username" on all the servers, >>> and only a few of them have the account. I have now waited 15 >>> minutes, still no luck. >>> >>> Oh well.. I guess I will go look at alternatives. I had such high >>> hopes for this tool. Thanks so much everyone for all your help in >>> trying to get things stable, but for whatever reason, there is a >>> random loss of sync among the servers and obviously this is not >>> acceptable. >>> >>> regards >>> ~J >> A new error: >> >> [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: >> Invalid credentials] >> >> > can you see the update on ipa03.example.com ? > It is looking like the replica agreement from this host is failing to > bind to a replica. This could explain why the replica do not receive the > update (disabled account, password/certificate expiration, ...) > Again logs/config would help. > > thierry > > > Hello, maybe stupid question: Is time on all your replicas in sync? Usually when the time is not synced between KDC and client the ticket is rejected thus preventing login. -- David Kupka From dewanggaba at xtremenitro.org Tue May 19 08:53:55 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Tue, 19 May 2015 15:53:55 +0700 Subject: [Freeipa-users] Reinstall ipa client, problem with old CA In-Reply-To: <555ACFE2.60808@redhat.com> References: <555A9A3B.7050301@xtremenitro.org> <555ACFE2.60808@redhat.com> Message-ID: <555AFA23.50900@xtremenitro.org> Hello! On 05/19/2015 12:53 PM, Martin Kosek wrote: > On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: >> Hello! >> >> I'm trying to reinstall ipa client, but have a problem with old/existing >> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA >> server still on development and always reinstalled, I need to reproduce >> any possible problem/error on FreeIPA 4.x on CentOS 7. >> >> The error was : >> LDAP Error: Connect error: TLS error -8054:You are attempting to import >> a cert with the same issuer/serial as an existing cert, but that is not >> the same cert. >> >> Currently, I was renamed ca.crt to ca.crt.old and the ipa client >> successfully reconnected to new FreeIPA Server using dns discovery. >> >> Is it normal? And why the ipa-client-install --uninstall didn't >> completely remove the old ca.crt? > > Hello, > > ipa-client-install uninstall the CA certificate properly since FreeIPA > 3.2. This is the upstream ticket: > https://fedorahosted.org/freeipa/ticket/3537 > > CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x > versions, you need to delete the certificate manually if you reinstalled > the IPA server. > > HTH, > Martin Could you gimme advice, which version is suitable on production? 3.x or 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). From thibaut.pouzet at lyra-network.com Tue May 19 08:54:28 2015 From: thibaut.pouzet at lyra-network.com (Thibaut Pouzet) Date: Tue, 19 May 2015 10:54:28 +0200 Subject: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports) In-Reply-To: <5553083E.3050203@lyra-network.com> References: <5550C748.3090903@lyra-network.com> <20150512160952.GA23769@redhat.com> <55522CB1.2090805@lyra-network.com> <20150512181142.GB23769@redhat.com> <5553083E.3050203@lyra-network.com> Message-ID: <555AFA44.70601@lyra-network.com> Le 13/05/2015 10:15, Thibaut Pouzet a ?crit : > Le 12/05/2015 20:11, Nalin Dahyabhai a ?crit : >> On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote: >>> After doing what you recommended, the CSR have changed in the debug log : >>> >>> Certificate Request: >>> Data: >>> Version: 0 (0x0) >>> Subject: O=ipa_domain, CN=ipa_server >>> Subject Public Key Info: >>> Public Key Algorithm: rsaEncryption >>> Public-Key: (2048 bit) >>> Modulus: >>> 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: >>> 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: >>> 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: >>> 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: >>> 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: >>> 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: >>> 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: >>> d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: >>> 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: >>> 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: >>> f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: >>> c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: >>> 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: >>> b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: >>> 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: >>> 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: >>> 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: >>> 1b:fb >>> Exponent: 65537 (0x10001) >>> Attributes: >>> a0:00 >>> Signature Algorithm: sha256WithRSAEncryption >>> 10:ef:cf:ff:6c:63:72:61:c3:b5:5e:8e:b0:20:f0:63:13:43: >>> bb:3b:63:c8:4e:6f:34:63:33:cc:47:af:8a:dc:2d:13:2a:58: >>> 87:7c:d7:5e:e9:b3:e7:f4:47:b7:7b:eb:77:0b:7c:0e:58:20: >>> dd:62:a8:a0:8b:31:1e:54:f0:dd:3f:44:4a:e7:a2:a6:64:85: >>> 9f:10:0e:06:75:33:94:82:f3:8f:89:66:e1:7f:65:21:85:b8: >>> 69:6d:e7:35:a5:a7:08:1d:51:55:48:13:b8:e3:2d:6f:99:c1: >>> ce:1e:81:e3:fb:93:3a:f0:86:0d:43:96:31:93:fb:87:fb:53: >>> 46:02:e1:dd:05:55:85:72:35:fa:72:6d:c6:35:d4:6d:9e:be: >>> db:ee:e6:8c:7b:b1:5a:cd:4d:cc:8e:3e:10:4e:a7:d3:61:36: >>> ae:86:59:df:51:a3:0f:38:79:b8:e0:bd:eb:25:44:a4:43:b0: >>> 93:7f:1e:43:aa:d5:30:d3:e3:a0:bd:ee:08:b7:88:9a:cd:a0: >>> 8c:ac:2a:8f:71:ec:64:70:72:91:f8:d2:e8:55:5b:22:1f:2e: >>> 60:6c:a4:be:ee:42:09:a6:71:25:ec:37:43:a1:e6:15:63:8f: >>> 05:97:61:1d:8e:25:5d:76:df:8b:66:7f:85:27:8b:93:98:a9: >>> 3e:cc:cb:d8 >>> >>> There is no more this weird "friendlyName :unable to print >>> attribute" thing, but the NoSuchTokenException is still in the debug log >>> of pki-ca >>> >>> Thank you for you answer though, we've still made some progress in >>> identifying that I messed the CA used for this certificate ! >> >> Hmm, so what you've got there looks pretty normal for a renewal request. >> Just to rule out a problem with the request's signature or the encoding >> of the subject name in the request (the latter is a bug in versions of >> certmonger before 0.72), can you check the version of the certmonger >> package and show us the base64-encoded form of the signing request? > > Before going further and asking the ML, I got these packages updated > 'just in case' : > rpm -qa | egrep "certmonger|jss" > tomcatjss-2.1.0-3.el6.noarch > certmonger-0.75.13-1.el6.x86_64 > jss-4.2.6-24.el6.x86_64 > >> >> I'm just about grasping at straws here, but the NoSuchTokenException >> exception appears to be coming from the jss library, and is thrown when >> it can't find the software module that is used for accessing the >> server's keys. Can you verify that your /etc/pki-ca/CS.cfg file >> contains these lines? >> >> jss.configDir=/var/lib/pki-ca/alias/ >> jss.enable=true >> jss.secmodName=secmod.db >> > > These lines are exactly as is inside the CS.cfg file > >> Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg? I >> don't have one. The Dogtag logic looks like it would try to use one set >> there rather than the default, but letting it use the default looks like >> the intended way of doing things. > > I cannot find this line, this is all I've got that seems somehow related > to a token notion : > > fgrep token /etc/pki-ca/CS.cfg > ca.audit_signing.tokenname=Internal Key Storage Token > ca.ocsp_signing.tokenname=Internal Key Storage Token > ca.signing.tokenname=Internal Key Storage Token > ca.sslserver.tokenname=Internal Key Storage Token > ca.subsystem.tokenname=Internal Key Storage Token > cloning.module.token=Internal Key Storage Token > >> >> Which version of the jss and tomcatjss packages are installed? I'm >> using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here. >> >> If none of this turns up anything, then I'm going to have to defer to >> the Dogtag team, too. >> >> Nalin >> > > I do not wish to give away too much information on this ML, so I will > send the base64 CSR and CS.cfg file to you personally. I am sorry for > the other people watching this discussions... I will take care to submit > relevant information if anything is found with this. > > Cheers, > Hi, It appeared that the NSS DB had fips enabled due to the troubleshooting of an old problem : # modutil -dbdir /var/lib/pki-ca/alias/ -list Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal FIPS PKCS #11 Module slots: 1 slot attached status: loaded slot: NSS FIPS 140-2 User Private Key Services token: NSS FIPS 140-2 Certificate DB ----------------------------------------------------------- I disabled it : modutil -dbdir /var/lib/pki-ca/alias -fips false And no longer have the stack trace in the debug logs while re-sumbitting the certificate with certmonger. This is a first step in this certificate renewal, as I still cannot renew it, I have a new error : status: CA_UNREACHABLE ca-error: Error 60 connecting to https://ipa_server:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates. This looks like a chicken and egg problem, the certificate served on ipa_server:9443 is the one that needs to be renewed. I tried to step back in time when the certificate was still valid with no luck. So if anyone has an idea here... Cheers, -- Thibaut Pouzet Lyra Network Ing?nieur Syst?mes et R?seaux (+33) 5 31 22 40 08 www.lyra-network.com From thewebbie at gmail.com Tue May 19 09:29:21 2015 From: thewebbie at gmail.com (thewebbie) Date: Tue, 19 May 2015 05:29:21 -0400 Subject: [Freeipa-users] Apache htaccess replacement In-Reply-To: <20150519080315.GK6587@redhat.com> References: <20150519080315.GK6587@redhat.com> Message-ID: My requirements is to replace dozens of htaccess folders on one server. Each folder requiring a user group. So Host based will not work in this case Matthew Feinberg On May 19, 2015 4:03 AM, "Jan Pazdziora" wrote: > On Mon, May 18, 2015 at 12:38:47PM -0400, thewebbie wrote: > > > > I have been attempting to use my 4.1.4 FreeIPA server to authenticate > > folders on a web server as a replacement for the normal htaccess > feature. I > > do require group authentication. I have tried just about online example > and > > have only been able to get basic ldap and basic kerbos authentication. > How > > do I go about getting group based authentication working. > > If you do not insist on group based authentication but can use > the more generic host-based access control (which you should be able > to do because you have IPA), you can use mod_authnz_pam: > > http://www.adelton.com/apache/mod_authnz_pam/ > > http://www.freeipa.org/page/Web_App_Authentication > > The module is packaged in Fedoras, RHEL, and CentOS. > > -- > Jan Pazdziora > Senior Principal Software Engineer, Identity Management Engineering, Red > Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoshi314 at gmail.com Tue May 19 10:34:47 2015 From: yoshi314 at gmail.com (marcin kowalski) Date: Tue, 19 May 2015 12:34:47 +0200 Subject: [Freeipa-users] certmonger + dogtag, bad parsing of returned certificate Message-ID: Hi, all. I am trying to integrate certmonger with dogtag instance, and so far i've stumbled on one odd problem. Hopefully this is the right list. I've generated some random cert with getcert request, it has communicated with dogtag, and i approved it there. However, when certmonger retrieves it, it cannot save it to disk ( NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) Upon inspection of certmonger's request file (in /var/lib/certmonger/requests ), it turns out that there is an extra empty line before end certificate marker line. There is no such line when looking at the cert in dogtag web interface. Is there some method/hook i could use to post process such request files to fix them up? Currently i have to stop certmonger, remove the unnecessary blank line and restart it. Then it manages to save the cert to disk and starts tracking it correctly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notify.sina at gmail.com Tue May 19 13:13:52 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Tue, 19 May 2015 14:13:52 +0100 Subject: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot In-Reply-To: <5559F77C.5000003@redhat.com> References: <5559ADCC.8050001@redhat.com> <5559F77C.5000003@redhat.com> Message-ID: Thank you very much Martin I will get back to you very soon with what I've found out. On Mon, May 18, 2015 at 3:30 PM, Martin Kosek wrote: > On 05/18/2015 02:17 PM, Sina Owolabi wrote: >> Hi Martin >> >> And thanks for getting back, greatly appreciated. >> I tore down the replica and reinstalled from scratch, using an old >> replica-info file >> I had on the primary. Im not sure if this is a good thing to do, but I >> would appreciate >> if you could point me to the logs you'd be interested in seeing. >> I had to reinstall the replica without CA before it would complete, too. >> >> Thanks again for your precious time. > > It depends what component you are actually fighting with. There is a separate > log for LDAP server, KDC server, Apache and PKI servers. > > Most directions are specific here > http://www.freeipa.org/page/Troubleshooting > > We need to know first what specific error you are dealing with right now, to > point you to right direction. > > Martin > >> >> On Mon, May 18, 2015 at 10:15 AM, Martin Kosek wrote: >>> On 05/16/2015 12:19 PM, Sina Owolabi wrote: >>>> Please help me. I am in dire straits, this is the linchpin of our >>>> network and we are suffering. >>> >>> I am sorry for delay in answering, but not many people here show up on the >>> weekend. Comments below. >>> >>>> On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi wrote: >>>>> Hi! >>>>> >>>>> I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, >>>>> with the following versions: >>>>> libipa_hbac-1.11.6-30.el6_6.4.x86_64 >>>>> ipa-server-selinux-3.0.0-42.el6.x86_64 >>>>> libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 >>>>> ipa-admintools-3.0.0-42.el6.x86_64 >>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>> ipa-client-3.0.0-42.el6.x86_64 >>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>> device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 >>>>> device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 >>>>> ipa-server-3.0.0-42.el6.x86_64 >>>>> ipa-python-3.0.0-42.el6.x86_64 >>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>> sssd-ipa-1.11.6-30.el6_6.4.x86_64 >>>>> >>>>> >>>>> I noticed the replica did not seem to be in sync with the primary IPA >>>>> server, as login requests to ipa clients using the replica for domain >>>>> authentication failed with >>>>> "Too many authentication failures for user UNKNOWN". >>>>> I forced a sync with the primary server and rebooted the replica afterwards. >>>>> Now the replica is back up, but when I run "ipactl status", only >>>>> dirsrv is running: >>>>> # ipactl status >>>>> Directory Service: RUNNING >>> >>> This is strange, try >>> >>> # ipactl restart >>> >>> see which services fail to start and see the logs they produce. >>> >>>>> No other service shows up. I also tried editing /etc/krb5.conf to >>>>> change the [realms] information to point to the primary server, but >>>>> while I can now kinit admin, >>>>> nothing else works. >>>>> >>>>> Please how can I fix this problem? >>>>> >>>>> Please what can I do fix this? >>> >>> First things first. You need to first see if all service start and operate >>> properly, if not, we need to see their logs in order to help or advise. >>> >>> Martin > From mkosek at redhat.com Tue May 19 13:14:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 15:14:13 +0200 Subject: [Freeipa-users] Reinstall ipa client, problem with old CA In-Reply-To: <555AFA23.50900@xtremenitro.org> References: <555A9A3B.7050301@xtremenitro.org> <555ACFE2.60808@redhat.com> <555AFA23.50900@xtremenitro.org> Message-ID: <555B3725.7070402@redhat.com> On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote: > Hello! > > On 05/19/2015 12:53 PM, Martin Kosek wrote: >> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: >>> Hello! >>> >>> I'm trying to reinstall ipa client, but have a problem with old/existing >>> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA >>> server still on development and always reinstalled, I need to reproduce >>> any possible problem/error on FreeIPA 4.x on CentOS 7. >>> >>> The error was : >>> LDAP Error: Connect error: TLS error -8054:You are attempting to import >>> a cert with the same issuer/serial as an existing cert, but that is not >>> the same cert. >>> >>> Currently, I was renamed ca.crt to ca.crt.old and the ipa client >>> successfully reconnected to new FreeIPA Server using dns discovery. >>> >>> Is it normal? And why the ipa-client-install --uninstall didn't >>> completely remove the old ca.crt? >> >> Hello, >> >> ipa-client-install uninstall the CA certificate properly since FreeIPA >> 3.2. This is the upstream ticket: >> https://fedorahosted.org/freeipa/ticket/3537 >> >> CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x >> versions, you need to delete the certificate manually if you reinstalled >> the IPA server. >> >> HTH, >> Martin > > Could you gimme advice, which version is suitable on production? 3.x or > 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). All versions in RHEL should be suitable for production - RHEL is an OS targeting production/stable environment. For FreeIPA, I would recommend using environment built on top of RHEL-7.1 version (FreeIPA 4.1) as it contains the most fixes and most functionality to be offered. I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have limited capabilities of your infrastructure as most of the new server features are not backported to RHEL-6.x and clients connected to these servers could not use them. Martin From dewanggaba at xtremenitro.org Tue May 19 13:21:10 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Tue, 19 May 2015 20:21:10 +0700 Subject: [Freeipa-users] Reinstall ipa client, problem with old CA In-Reply-To: <555B3725.7070402@redhat.com> References: <555A9A3B.7050301@xtremenitro.org> <555ACFE2.60808@redhat.com> <555AFA23.50900@xtremenitro.org> <555B3725.7070402@redhat.com> Message-ID: <555B38C6.4000501@xtremenitro.org> Thank you Martin, Yes, the IPA Server was built on CentOS 7.1. But, some client still using CentOS 6.x, but I have plan upgrade them to 7.x. Is it gave a problem if some client still on CentOS 6.x and the IPA Server built on CentOS 7.x ? On 05/19/2015 08:14 PM, Martin Kosek wrote: > On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote: >> Hello! >> >> On 05/19/2015 12:53 PM, Martin Kosek wrote: >>> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: >>>> Hello! >>>> >>>> I'm trying to reinstall ipa client, but have a problem with old/existing >>>> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA >>>> server still on development and always reinstalled, I need to reproduce >>>> any possible problem/error on FreeIPA 4.x on CentOS 7. >>>> >>>> The error was : >>>> LDAP Error: Connect error: TLS error -8054:You are attempting to import >>>> a cert with the same issuer/serial as an existing cert, but that is not >>>> the same cert. >>>> >>>> Currently, I was renamed ca.crt to ca.crt.old and the ipa client >>>> successfully reconnected to new FreeIPA Server using dns discovery. >>>> >>>> Is it normal? And why the ipa-client-install --uninstall didn't >>>> completely remove the old ca.crt? >>> >>> Hello, >>> >>> ipa-client-install uninstall the CA certificate properly since FreeIPA >>> 3.2. This is the upstream ticket: >>> https://fedorahosted.org/freeipa/ticket/3537 >>> >>> CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x >>> versions, you need to delete the certificate manually if you reinstalled >>> the IPA server. >>> >>> HTH, >>> Martin >> >> Could you gimme advice, which version is suitable on production? 3.x or >> 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). > > All versions in RHEL should be suitable for production - RHEL is an OS > targeting production/stable environment. > > For FreeIPA, I would recommend using environment built on top of RHEL-7.1 > version (FreeIPA 4.1) as it contains the most fixes and most functionality to > be offered. > > I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have > limited capabilities of your infrastructure as most of the new server features > are not backported to RHEL-6.x and clients connected to these servers could not > use them. > > Martin > From mkosek at redhat.com Tue May 19 13:23:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 15:23:53 +0200 Subject: [Freeipa-users] Reinstall ipa client, problem with old CA In-Reply-To: <555B38C6.4000501@xtremenitro.org> References: <555A9A3B.7050301@xtremenitro.org> <555ACFE2.60808@redhat.com> <555AFA23.50900@xtremenitro.org> <555B3725.7070402@redhat.com> <555B38C6.4000501@xtremenitro.org> Message-ID: <555B3969.5050003@redhat.com> On 05/19/2015 03:21 PM, Dewangga Bachrul Alam wrote: > Thank you Martin, > > Yes, the IPA Server was built on CentOS 7.1. But, some client still > using CentOS 6.x, but I have plan upgrade them to 7.x. > > Is it gave a problem if some client still on CentOS 6.x and the IPA > Server built on CentOS 7.x ? No, I do not see a problem with this setup. Clients will just simply use the capabilities they can do. We still tend to backport client features to RHEL-6.x, so it keeps getting the selected functionality (server does not). > > On 05/19/2015 08:14 PM, Martin Kosek wrote: >> On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote: >>> Hello! >>> >>> On 05/19/2015 12:53 PM, Martin Kosek wrote: >>>> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: >>>>> Hello! >>>>> >>>>> I'm trying to reinstall ipa client, but have a problem with old/existing >>>>> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA >>>>> server still on development and always reinstalled, I need to reproduce >>>>> any possible problem/error on FreeIPA 4.x on CentOS 7. >>>>> >>>>> The error was : >>>>> LDAP Error: Connect error: TLS error -8054:You are attempting to import >>>>> a cert with the same issuer/serial as an existing cert, but that is not >>>>> the same cert. >>>>> >>>>> Currently, I was renamed ca.crt to ca.crt.old and the ipa client >>>>> successfully reconnected to new FreeIPA Server using dns discovery. >>>>> >>>>> Is it normal? And why the ipa-client-install --uninstall didn't >>>>> completely remove the old ca.crt? >>>> >>>> Hello, >>>> >>>> ipa-client-install uninstall the CA certificate properly since FreeIPA >>>> 3.2. This is the upstream ticket: >>>> https://fedorahosted.org/freeipa/ticket/3537 >>>> >>>> CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x >>>> versions, you need to delete the certificate manually if you reinstalled >>>> the IPA server. >>>> >>>> HTH, >>>> Martin >>> >>> Could you gimme advice, which version is suitable on production? 3.x or >>> 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). >> >> All versions in RHEL should be suitable for production - RHEL is an OS >> targeting production/stable environment. >> >> For FreeIPA, I would recommend using environment built on top of RHEL-7.1 >> version (FreeIPA 4.1) as it contains the most fixes and most functionality to >> be offered. >> >> I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have >> limited capabilities of your infrastructure as most of the new server features >> are not backported to RHEL-6.x and clients connected to these servers could not >> use them. >> >> Martin >> From janellenicole80 at gmail.com Tue May 19 13:24:40 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 19 May 2015 06:24:40 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555AE399.1050901@redhat.com> References: <555A9083.5010804@gmail.com> <555ACE84.3030105@redhat.com> <555ADEFF.5090304@redhat.com> <555AE399.1050901@redhat.com> Message-ID: <555B3998.6060706@gmail.com> On 5/19/15 12:17 AM, Ludwig Krispenz wrote: > > On 05/19/2015 08:58 AM, thierry bordaz wrote: >> On 05/19/2015 07:47 AM, Martin Kosek wrote: >>> On 05/19/2015 03:23 AM, Janelle wrote: >>>> Once again, replication/sync has been lost. I really wish the >>>> product was more >>>> stable, it is so much potential and yet. >>>> >>>> Servers running for 6 days no issues. No new accounts or changes >>>> (maybe a few >>>> users changing passwords) and again, 5 out of 16 servers are no >>>> longer in sync. >>>> >>>> I can test it easily by adding an account and then waiting a few >>>> minutes, then >>>> run "ipa user-show --all username" on all the servers, and only a >>>> few of them >>>> have the account. I have now waited 15 minutes, still no luck. >>>> >>>> Oh well.. I guess I will go look at alternatives. I had such high >>>> hopes for >>>> this tool. Thanks so much everyone for all your help in trying to >>>> get things >>>> stable, but for whatever reason, there is a random loss of sync >>>> among the >>>> servers and obviously this is not acceptable. >>> >>> Hello Janelle, >>> >>> I am very sorry to hear about your troubles. Would you be still OK >>> with helping us (mostly Ludwig and Thierry) investigate what is the >>> root cause of the instability of the replication agreements? This is >>> obviously something that should not be happening at this rate as in >>> your deployment, so I would really like to be able to identity and >>> fix this issue in the 389 DS. >> Hello Janelle, >> >> I can only join my voice to Martin to say how I am sorry to read this. >> Would you turn on replication logging level (8192) on the >> master/consumer and provide us the logs(access/error) and config >> (dse.ldif). >> The master is the instance where you can see the update and the that >> is linked (replica agreement) to a replica(aka consumer) where the >> update is not received. > what puzzles me most, is that replication is working for quite some > time and then breaks, so we need to find out about the dynamics which > lead to that state. You reported errors about invalid credentials or > about a bind dn entry not found, these credentials don't get changed > by ds or entries are not deleted by ds, so what triggers these changes. > also for the suggestion by Thierry to debug, we need to determine > where replication breaks, if you add an account and it is propageted > to some servers and not to others, where does it stop ? This depends > on your replication topology, you said in anotehr post that you have a > ring topology, does it mean all 16 servers are conencted in a ring > only, and if two links break the topology is disconnected ? >> >> thanks >> thierry > Let me see about getting some debug logs going to provide more info. As for topology -- yes, ring, but also within the DC - the 3 servers are connected in an internal ring. There have been no outages on the WAN connections, as I have logs showing network data at all times, so this is not an issue. If I did lose a WAN, dozens of other inter-DC apps would blow up too, and they have not. However, I guess you are right, I have not provided enough logging data to help diagnose this. Let me see what I can do. Not sure if this helps -- I do try and do all updates from a single master, never from different ones. Users are also forced to the same master to change passwords and update things. So the "source" of changes is always the same. Time to go do some log enabling... ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue May 19 13:27:08 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 15:27:08 +0200 Subject: [Freeipa-users] certmonger + dogtag, bad parsing of returned certificate In-Reply-To: References: Message-ID: <555B3A2C.4050407@redhat.com> On 05/19/2015 12:34 PM, marcin kowalski wrote: > Hi, all. I am trying to integrate certmonger with dogtag instance, and so > far i've stumbled on one odd problem. Hopefully this is the right list. > > > I've generated some random cert with getcert request, it has communicated > with dogtag, and i approved it there. > > However, when certmonger retrieves it, it cannot save it to disk ( > NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) > > Upon inspection of certmonger's request file (in > /var/lib/certmonger/requests ), it turns out that there is an extra empty > line before end certificate marker line. There is no such line when > looking at the cert in dogtag web interface. > > Is there some method/hook i could use to post process such request files to > fix them up? > > Currently i have to stop certmonger, remove the unnecessary blank line and > restart it. Then it manages to save the cert to disk and starts tracking it > correctly. CCing Nalin here. What is the your environment and versions of the FreeIPA/Dogtag packages you are using? Seeing your description, it looks you are following some own way - Certmonger for FreeIPA clients do not need any confirmation on Dogtag side, it is approved automatically. It looks like you are using Dogtag UI directly and not the FreeIPA integration. From dewanggaba at xtremenitro.org Tue May 19 13:30:59 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Tue, 19 May 2015 20:30:59 +0700 Subject: [Freeipa-users] Problem installing external SSL Certificate Message-ID: <555B3B13.9090301@xtremenitro.org> Hello! I was build FreeIPA 4.1.4 on CentOS 7.1, the deployment was done, but could I changes the HTTP and dirsv certificate? I have wildcard certificate (thawte SSL CA - G2). It is compatible for FreeIPA (http and dirsv)? I've tried to follow the instruction https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but no luck. $ ipa-server-certinstall -wd mydomain.co.id.key \ mydomain.co.id-bundled.crt Directory Manager password: Enter private key unlock password: The full certificate chain is not present in mydomain.co.id.key, mydomain.co.id-bundled.crt FYI, mydomain.co.id-bundled.crt chain have SIGNED then INTERMEDIATE certificate order. (2 chain) I've tried to bundling them using root certificate, still have no luck. (3 chain, SIGNEDCERT, INTERMEDIATE, ROOTCERT). Any comments will be appreciated :) Thanks From dewanggaba at xtremenitro.org Tue May 19 13:34:08 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Tue, 19 May 2015 20:34:08 +0700 Subject: [Freeipa-users] Reinstall ipa client, problem with old CA In-Reply-To: <555B3969.5050003@redhat.com> References: <555A9A3B.7050301@xtremenitro.org> <555ACFE2.60808@redhat.com> <555AFA23.50900@xtremenitro.org> <555B3725.7070402@redhat.com> <555B38C6.4000501@xtremenitro.org> <555B3969.5050003@redhat.com> Message-ID: <555B3BD0.8000707@xtremenitro.org> Well, thanks Martin for the info :) On 05/19/2015 08:23 PM, Martin Kosek wrote: > On 05/19/2015 03:21 PM, Dewangga Bachrul Alam wrote: >> Thank you Martin, >> >> Yes, the IPA Server was built on CentOS 7.1. But, some client still >> using CentOS 6.x, but I have plan upgrade them to 7.x. >> >> Is it gave a problem if some client still on CentOS 6.x and the IPA >> Server built on CentOS 7.x ? > > No, I do not see a problem with this setup. Clients will just simply use the > capabilities they can do. We still tend to backport client features to > RHEL-6.x, so it keeps getting the selected functionality (server does not). > >> >> On 05/19/2015 08:14 PM, Martin Kosek wrote: >>> On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote: >>>> Hello! >>>> >>>> On 05/19/2015 12:53 PM, Martin Kosek wrote: >>>>> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: >>>>>> Hello! >>>>>> >>>>>> I'm trying to reinstall ipa client, but have a problem with old/existing >>>>>> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA >>>>>> server still on development and always reinstalled, I need to reproduce >>>>>> any possible problem/error on FreeIPA 4.x on CentOS 7. >>>>>> >>>>>> The error was : >>>>>> LDAP Error: Connect error: TLS error -8054:You are attempting to import >>>>>> a cert with the same issuer/serial as an existing cert, but that is not >>>>>> the same cert. >>>>>> >>>>>> Currently, I was renamed ca.crt to ca.crt.old and the ipa client >>>>>> successfully reconnected to new FreeIPA Server using dns discovery. >>>>>> >>>>>> Is it normal? And why the ipa-client-install --uninstall didn't >>>>>> completely remove the old ca.crt? >>>>> >>>>> Hello, >>>>> >>>>> ipa-client-install uninstall the CA certificate properly since FreeIPA >>>>> 3.2. This is the upstream ticket: >>>>> https://fedorahosted.org/freeipa/ticket/3537 >>>>> >>>>> CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x >>>>> versions, you need to delete the certificate manually if you reinstalled >>>>> the IPA server. >>>>> >>>>> HTH, >>>>> Martin >>>> >>>> Could you gimme advice, which version is suitable on production? 3.x or >>>> 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). >>> >>> All versions in RHEL should be suitable for production - RHEL is an OS >>> targeting production/stable environment. >>> >>> For FreeIPA, I would recommend using environment built on top of RHEL-7.1 >>> version (FreeIPA 4.1) as it contains the most fixes and most functionality to >>> be offered. >>> >>> I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have >>> limited capabilities of your infrastructure as most of the new server features >>> are not backported to RHEL-6.x and clients connected to these servers could not >>> use them. >>> >>> Martin >>> > From janellenicole80 at gmail.com Tue May 19 13:53:21 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 19 May 2015 06:53:21 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555AF28B.9010407@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555AF28B.9010407@redhat.com> Message-ID: <555B4051.9090208@gmail.com> On 5/19/15 1:21 AM, David Kupka wrote: > On 05/19/2015 09:04 AM, thierry bordaz wrote: >> On 05/19/2015 03:42 AM, Janelle wrote: >>> On 5/18/15 6:23 PM, Janelle wrote: >>>> Once again, replication/sync has been lost. I really wish the product >>>> was more stable, it is so much potential and yet. >>>> >>>> Servers running for 6 days no issues. No new accounts or changes >>>> (maybe a few users changing passwords) and again, 5 out of 16 servers >>>> are no longer in sync. >>>> >>>> I can test it easily by adding an account and then waiting a few >>>> minutes, then run "ipa user-show --all username" on all the servers, >>>> and only a few of them have the account. I have now waited 15 >>>> minutes, still no luck. >>>> >>>> Oh well.. I guess I will go look at alternatives. I had such high >>>> hopes for this tool. Thanks so much everyone for all your help in >>>> trying to get things stable, but for whatever reason, there is a >>>> random loss of sync among the servers and obviously this is not >>>> acceptable. >>>> >>>> regards >>>> ~J >>> A new error: >>> >>> [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: >>> Invalid credentials] >>> >>> >> can you see the update on ipa03.example.com ? >> It is looking like the replica agreement from this host is failing to >> bind to a replica. This could explain why the replica do not receive the >> update (disabled account, password/certificate expiration, ...) >> Again logs/config would help. >> >> thierry >> >> >> > > Hello, > maybe stupid question: Is time on all your replicas in sync? Usually > when the time is not synced between KDC and client the ticket is > rejected thus preventing login. > within .5 seconds each other at most. From nalin at redhat.com Tue May 19 14:30:33 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 19 May 2015 10:30:33 -0400 Subject: [Freeipa-users] certmonger + dogtag, bad parsing of returned certificate In-Reply-To: References: Message-ID: <20150519143033.GA21934@redhat.com> On Tue, May 19, 2015 at 12:34:47PM +0200, marcin kowalski wrote: > Hi, all. I am trying to integrate certmonger with dogtag instance, and so > far i've stumbled on one odd problem. Hopefully this is the right list. > > I've generated some random cert with getcert request, it has communicated > with dogtag, and i approved it there. > > However, when certmonger retrieves it, it cannot save it to disk ( > NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) > > Upon inspection of certmonger's request file (in > /var/lib/certmonger/requests ), it turns out that there is an extra empty > line before end certificate marker line. There is no such line when > looking at the cert in dogtag web interface. > > Is there some method/hook i could use to post process such request files to > fix them up? There's no hook for doing that with the data files themselves, because they're meant to be internal details of the implementation, but the data coming back from the enrollment helper, which is what's malformed to begin with, can be corrected at the point when the helper is run. Essentially, you'd replace the configured call to dogtag-submit with a script or other program that checked $CERTMONGER_OPERATION for the values "SUBMIT" and "POLL", ran the dogtag-submit helper, filtered its output to fix this mistake, and returned the helper's exit status to keep things in line with the daemon's expectations. Though, if you're running something older than 0.77, please give 0.77.4 (currently in testing for Fedora 20 and 21) or a development snapshot (from the ipa-devel repo) a try. The 0.77 release had a lot of its parsing reworked as part of adding support for SCEP reply formats, which I think fixed this. The development snapshots add more authentication options to the generic Dogtag helper which you may also want, depending on the enrollment profile you're using. HTH, Nalin From yoshi314 at gmail.com Tue May 19 15:19:42 2015 From: yoshi314 at gmail.com (marcin kowalski) Date: Tue, 19 May 2015 17:19:42 +0200 Subject: [Freeipa-users] certmonger + dogtag, bad parsing of returned certificate In-Reply-To: <20150519143033.GA21934@redhat.com> References: <20150519143033.GA21934@redhat.com> Message-ID: Thanks for the tip, I am using whatever is in current fedora, which is 0.76 or similar version. I'll give an updated version a shot. I had similar results with ubuntu's 0.75.x 2015-05-19 16:30 GMT+02:00 Nalin Dahyabhai : > On Tue, May 19, 2015 at 12:34:47PM +0200, marcin kowalski wrote: > > Hi, all. I am trying to integrate certmonger with dogtag instance, and so > > far i've stumbled on one odd problem. Hopefully this is the right list. > > > > I've generated some random cert with getcert request, it has communicated > > with dogtag, and i approved it there. > > > > However, when certmonger retrieves it, it cannot save it to disk ( > > NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) > > > > Upon inspection of certmonger's request file (in > > /var/lib/certmonger/requests ), it turns out that there is an extra empty > > line before end certificate marker line. There is no such line when > > looking at the cert in dogtag web interface. > > > > Is there some method/hook i could use to post process such request files > to > > fix them up? > > There's no hook for doing that with the data files themselves, because > they're meant to be internal details of the implementation, but the data > coming back from the enrollment helper, which is what's malformed to > begin with, can be corrected at the point when the helper is run. > > Essentially, you'd replace the configured call to dogtag-submit with a > script or other program that checked $CERTMONGER_OPERATION for the > values "SUBMIT" and "POLL", ran the dogtag-submit helper, filtered its > output to fix this mistake, and returned the helper's exit status to > keep things in line with the daemon's expectations. > > Though, if you're running something older than 0.77, please give 0.77.4 > (currently in testing for Fedora 20 and 21) or a development snapshot > (from the ipa-devel repo) a try. The 0.77 release had a lot of its > parsing reworked as part of adding support for SCEP reply formats, which > I think fixed this. The development snapshots add more authentication > options to the generic Dogtag helper which you may also want, depending > on the enrollment profile you're using. > > HTH, > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue May 19 15:25:18 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 May 2015 11:25:18 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> <555A28B3.8080503@redhat.com> Message-ID: <555B55DE.8070007@redhat.com> Sina Owolabi wrote: > Hi Rob > > Ive been to the URL but its a little difficult applying these commands > to RHEL6 systems. > For instance there is no /etc/pki-tomcat directory in RHEL6, and I > cannot find the ipa.crt > > Im sure as a noob I am overlooking some very obvious stuff, but could > you please guide me on what to do? Sorry, I think I pointed you at the wrong page. Check out http://www.freeipa.org/page/IPA_2x_Certificate_Renewal Your CA subsystem are expired, or nearly expired. They are valid for two years. Based on the request ID in the snippet you posted at least some are valid for another few days. What I'd suggest is to send the machine back in time and restart the services. This should bring things up so that certmonger can do the renewal: # ipactl stop # /sbin/service ntpd stop # date 0501hhm where hhmm are the current hour and minute # ipactl start Hopefully ntpd isn't started by ipactl. If it is then it will undo your going back in time, and you'll need to start the services manually: # service dirsrv at YOURREALM start # service krb5kdc # service httpd start # service pki-tomcatd start Restart certmonger # service certmonger restart Wait a bit # getcert list Watch the status. They should go to MODIFIED Once done: # ipactl stop Return date to present, either by restarting ntpd or date or whatever method you'd like. I'm taking a completely wild guess on the date to go back to. The expiration date is listed in the getcert output. I'd go back a week before the oldest expiration. rob From nagemnna at gmail.com Tue May 19 16:10:15 2015 From: nagemnna at gmail.com (Megan .) Date: Tue, 19 May 2015 12:10:15 -0400 Subject: [Freeipa-users] getting rid of nsds5ReplConflict Message-ID: I'm struggling with a replication conflict. I had three masters, dir1, dir2, dir3. There were some weird issues with dir2 where I was getting "error 49 (Invalid credentials)" without any real information. When i did " ipa-replica-manage list-ruv" i saw dir2 twice. I couldn't get it straight so i decided to try to re-create the replica. I disconnected the replica, ran the del for the replica. When i check for replication conflicts i still see it in there and I can't seem to get it to go away. It only shows up on one of the remaining masters. I was trying to follow the documentation and use ldapmodify to change the dn to cn=olddir2.somewhere.example.something.com7475d90c but everything i seem to be trying doesn't work. I'm assuming this entry needs to be cleared up before i can successfully setup dir2 again as a replica. Any help would be greatly appreciated. Thanks! [root at dir1 ~]# ldapsearch -x -D "cn=directory manager" -W -b "dc=somewhere,dc=example,dc=something,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # dir2.somewhere.example.something.com + 7475d90c-f34911e4-99a0ab24-58022cdf, masters , ipa, etc, somewhere.example.something.com dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict: namingConflict cn=dir2.somewhere.example.something.com,cn=masters,c n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com objectClass: top objectClass: nsContainer cn: dir2.somewhere.example.something.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 From rmeggins at redhat.com Tue May 19 16:37:41 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 19 May 2015 10:37:41 -0600 Subject: [Freeipa-users] getting rid of nsds5ReplConflict In-Reply-To: References: Message-ID: <555B66D5.2060604@redhat.com> On 05/19/2015 10:10 AM, Megan . wrote: > I'm struggling with a replication conflict. I had three masters, > dir1, dir2, dir3. There were some weird issues with dir2 where I was > getting "error 49 (Invalid credentials)" without any real > information. Where did you see this? command line output? Of what command? In a log file? Which log file? Can you post the exact error message along with the context? > When i did " ipa-replica-manage list-ruv" i saw dir2 > twice. Can you post the output? > I couldn't get it straight What does "get it straight" mean? Does it mean you ran some commands? If so, what commands did you run and what was the result? > so i decided to try to re-create > the replica. I disconnected the replica, ran the del for the replica. > When i check for replication conflicts i still see it in there and I > can't seem to get it to go away. Deleting and recreating the replica will not remove the replication conflict if the conflict has been replicated to other servers. This document doesn't say anything about resolving replica conflict entries by deleting and re-adding replicas: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > It only shows up on one of the > remaining masters. > > I was trying to follow the documentation The link above? > and use ldapmodify to change > the dn to cn=olddir2.somewhere.example.something.com7475d90c but > everything i seem to be trying doesn't work. What exactly did you do? > > I'm assuming this entry needs to be cleared up before i can > successfully setup dir2 again as a replica. No, not necessarily. > > Any help would be greatly appreciated. > > Thanks! > > > [root at dir1 ~]# ldapsearch -x -D "cn=directory manager" -W -b > "dc=somewhere,dc=example,dc=something,dc=com" "nsds5ReplConflict=*" \* > nsds5ReplConflict > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: nsds5ReplConflict=* > # requesting: * nsds5ReplConflict > # > > # dir2.somewhere.example.something.com + > 7475d90c-f34911e4-99a0ab24-58022cdf, masters > , ipa, etc, somewhere.example.something.com > dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 > 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com > nsds5ReplConflict: namingConflict > cn=dir2.somewhere.example.something.com,cn=masters,c > n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com > objectClass: top > objectClass: nsContainer > cn: dir2.somewhere.example.something.com > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > From nagemnna at gmail.com Tue May 19 18:27:32 2015 From: nagemnna at gmail.com (Megan .) Date: Tue, 19 May 2015 14:27:32 -0400 Subject: [Freeipa-users] getting rid of nsds5ReplConflict In-Reply-To: <555B66D5.2060604@redhat.com> References: <555B66D5.2060604@redhat.com> Message-ID: Thank you for the reply. I think I just got frustrated. I uninstalled ipa on the dir2 replica then set it back up again as a replica. Everything seems to be replicating just fine without errors now. I know that this isn't the preferred or documented solution but i needed the server back online asap. When i run "ipa-replica-manage list-ruv" i see dir2 listed twice. Is this a concern? [root at dir1 ipa]# ipa-replica-manage list-ruv dir1.example.com:389: 4 dir3.example.com:389: 5 dir2.example.com:389: 6 dir2.example.com:389: 8 On Tue, May 19, 2015 at 12:37 PM, Rich Megginson wrote: > On 05/19/2015 10:10 AM, Megan . wrote: >> >> I'm struggling with a replication conflict. I had three masters, >> dir1, dir2, dir3. There were some weird issues with dir2 where I was >> getting "error 49 (Invalid credentials)" without any real >> information. > > > Where did you see this? command line output? Of what command? In a log > file? Which log file? Can you post the exact error message along with the > context? > >> When i did " ipa-replica-manage list-ruv" i saw dir2 >> twice. > > > Can you post the output? > >> I couldn't get it straight > > > What does "get it straight" mean? Does it mean you ran some commands? If > so, what commands did you run and what was the result? > >> so i decided to try to re-create >> the replica. I disconnected the replica, ran the del for the replica. >> When i check for replication conflicts i still see it in there and I >> can't seem to get it to go away. > > > Deleting and recreating the replica will not remove the replication conflict > if the conflict has been replicated to other servers. > > This document doesn't say anything about resolving replica conflict entries > by deleting and re-adding replicas: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > >> It only shows up on one of the >> remaining masters. >> >> I was trying to follow the documentation > > > The link above? > >> and use ldapmodify to change >> the dn to cn=olddir2.somewhere.example.something.com7475d90c but >> everything i seem to be trying doesn't work. > > > What exactly did you do? > >> >> I'm assuming this entry needs to be cleared up before i can >> successfully setup dir2 again as a replica. > > > No, not necessarily. > > >> >> Any help would be greatly appreciated. >> >> Thanks! >> >> >> [root at dir1 ~]# ldapsearch -x -D "cn=directory manager" -W -b >> "dc=somewhere,dc=example,dc=something,dc=com" "nsds5ReplConflict=*" \* >> nsds5ReplConflict >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: nsds5ReplConflict=* >> # requesting: * nsds5ReplConflict >> # >> >> # dir2.somewhere.example.something.com + >> 7475d90c-f34911e4-99a0ab24-58022cdf, masters >> , ipa, etc, somewhere.example.something.com >> dn: >> cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 >> >> 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com >> nsds5ReplConflict: namingConflict >> cn=dir2.somewhere.example.something.com,cn=masters,c >> n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com >> objectClass: top >> objectClass: nsContainer >> cn: dir2.somewhere.example.something.com >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> > > -- > 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 From rmeggins at redhat.com Tue May 19 18:32:20 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 19 May 2015 12:32:20 -0600 Subject: [Freeipa-users] getting rid of nsds5ReplConflict In-Reply-To: References: <555B66D5.2060604@redhat.com> Message-ID: <555B81B4.7040203@redhat.com> On 05/19/2015 12:27 PM, Megan . wrote: > Thank you for the reply. I think I just got frustrated. I > uninstalled ipa on the dir2 replica then set it back up again as a > replica. Everything seems to be replicating just fine without errors > now. I know that this isn't the preferred or documented solution but > i needed the server back online asap. > > When i run "ipa-replica-manage list-ruv" i see dir2 listed twice. Is > this a concern? No. When you get a chance, you can remove the one that is no longer used with the documented clean ruv procedure. I believe there is an ipa command for that. > > [root at dir1 ipa]# ipa-replica-manage list-ruv > dir1.example.com:389: 4 > dir3.example.com:389: 5 > dir2.example.com:389: 6 > dir2.example.com:389: 8 > > On Tue, May 19, 2015 at 12:37 PM, Rich Megginson wrote: >> On 05/19/2015 10:10 AM, Megan . wrote: >>> I'm struggling with a replication conflict. I had three masters, >>> dir1, dir2, dir3. There were some weird issues with dir2 where I was >>> getting "error 49 (Invalid credentials)" without any real >>> information. >> >> Where did you see this? command line output? Of what command? In a log >> file? Which log file? Can you post the exact error message along with the >> context? >> >>> When i did " ipa-replica-manage list-ruv" i saw dir2 >>> twice. >> >> Can you post the output? >> >>> I couldn't get it straight >> >> What does "get it straight" mean? Does it mean you ran some commands? If >> so, what commands did you run and what was the result? >> >>> so i decided to try to re-create >>> the replica. I disconnected the replica, ran the del for the replica. >>> When i check for replication conflicts i still see it in there and I >>> can't seem to get it to go away. >> >> Deleting and recreating the replica will not remove the replication conflict >> if the conflict has been replicated to other servers. >> >> This document doesn't say anything about resolving replica conflict entries >> by deleting and re-adding replicas: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> >>> It only shows up on one of the >>> remaining masters. >>> >>> I was trying to follow the documentation >> >> The link above? >> >>> and use ldapmodify to change >>> the dn to cn=olddir2.somewhere.example.something.com7475d90c but >>> everything i seem to be trying doesn't work. >> >> What exactly did you do? >> >>> I'm assuming this entry needs to be cleared up before i can >>> successfully setup dir2 again as a replica. >> >> No, not necessarily. >> >> >>> Any help would be greatly appreciated. >>> >>> Thanks! >>> >>> >>> [root at dir1 ~]# ldapsearch -x -D "cn=directory manager" -W -b >>> "dc=somewhere,dc=example,dc=something,dc=com" "nsds5ReplConflict=*" \* >>> nsds5ReplConflict >>> Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree >>> # filter: nsds5ReplConflict=* >>> # requesting: * nsds5ReplConflict >>> # >>> >>> # dir2.somewhere.example.something.com + >>> 7475d90c-f34911e4-99a0ab24-58022cdf, masters >>> , ipa, etc, somewhere.example.something.com >>> dn: >>> cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 >>> >>> 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com >>> nsds5ReplConflict: namingConflict >>> cn=dir2.somewhere.example.something.com,cn=masters,c >>> n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com >>> objectClass: top >>> objectClass: nsContainer >>> cn: dir2.somewhere.example.something.com >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 2 >>> # numEntries: 1 >>> >> -- >> 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 From george.boyce at nasa.gov Tue May 19 19:53:41 2015 From: george.boyce at nasa.gov (Boyce, George Robert. (GSFC-762.0)[NICS]) Date: Tue, 19 May 2015 19:53:41 +0000 Subject: [Freeipa-users] confused by ldapsearch results Message-ID: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> I don't understand what is happening... If I use a compound OR filter to search for "cn" or "uid", I only get back the match for uid. I expect to get both. If I add a search for a nonexistent attribute like "name", I get nothing back. I expect to get back the entry matched by the other term. # l "(cn=gboyce)" dn dn: cn=gboyce,cn=groups,cn=accounts,dc=... # l "(uid=gboyce)" dn dn: uid=gboyce,cn=users,cn=accounts,dc=... # l "(|(uid=gboyce)(cn=gboyce))" dn dn: uid=gboyce,cn=users,cn=accounts,dc=... # l "(|(cn=gboyce)(uid=gboyce))" dn dn: uid=gboyce,cn=users,cn=accounts,dc=... # l "(|(uid=gboyce)(name=gboyce))" dn # This is on a new deployment of ipa on centos, with just a couple of test records. I don't have much recent experience with LDAP, but I don't see what I'm doing wrong. Dirsrv on centos 6.5 works as expected. # ipa --version VERSION: 4.1.0, API_VERSION: 2.112 # cat /etc/centos-release CentOS Linux release 7.1.1503 (Core) George Boyce, SAIC/NICS GCC Systems Support NASA GSFC Code 762 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue May 19 19:58:31 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 19 May 2015 13:58:31 -0600 Subject: [Freeipa-users] confused by ldapsearch results In-Reply-To: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> References: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> Message-ID: <555B95E7.5040109@redhat.com> On 05/19/2015 01:53 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: > > I don?t understand what is happening? > > If I use a compound OR filter to search for ?cn? or ?uid?, I only get > back the match for uid. I expect to get both. If I add a search for a > nonexistent attribute like ?name?, I get nothing back. I expect to get > back the entry matched by the other term. > > # l "(cn=gboyce)" dn > > dn: cn=gboyce,cn=groups,cn=accounts,dc=? > > # l "(uid=gboyce)" dn > > dn: uid=gboyce,cn=users,cn=accounts,dc=? > > # l "(|(uid=gboyce)(cn=gboyce))" dn > > dn: uid=gboyce,cn=users,cn=accounts,dc=? > > # l "(|(cn=gboyce)(uid=gboyce))" dn > > dn: uid=gboyce,cn=users,cn=accounts,dc=? > > # l "(|(uid=gboyce)(name=gboyce))" dn > > # > Does this give an error message or does ldapsearch exit with a non-zero value? Can you check the dirsrv access log to see what is the result of this operation? > This is on a new deployment of ipa on centos, with just a couple of > test records. I don?t have much recent experience with LDAP, but I > don?t see what I?m doing wrong. Dirsrv on centos 6.5 works as expected. > > # ipa --version > > VERSION: 4.1.0, API_VERSION: 2.112 > > # cat /etc/centos-release > > CentOS Linux release 7.1.1503 (Core) > > George Boyce, SAIC/NICS > > GCC Systems Support > > NASA GSFC Code 762 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue May 19 20:25:56 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 May 2015 16:25:56 -0400 Subject: [Freeipa-users] confused by ldapsearch results In-Reply-To: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> References: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> Message-ID: <555B9C54.6050302@redhat.com> Boyce, George Robert. (GSFC-762.0)[NICS] wrote: > I don?t understand what is happening? > > If I use a compound OR filter to search for ?cn? or ?uid?, I only get > back the match for uid. I expect to get both. If I add a search for a > nonexistent attribute like ?name?, I get nothing back. I expect to get > back the entry matched by the other term. > > # l "(cn=gboyce)" dn > > dn: cn=gboyce,cn=groups,cn=accounts,dc=? > > # l "(uid=gboyce)" dn > > dn: uid=gboyce,cn=users,cn=accounts,dc=? > > # l "(|(uid=gboyce)(cn=gboyce))" dn > > dn: uid=gboyce,cn=users,cn=accounts,dc=? > > # l "(|(cn=gboyce)(uid=gboyce))" dn > > dn: uid=gboyce,cn=users,cn=accounts,dc=? > > # l "(|(uid=gboyce)(name=gboyce))" dn > > # > > This is on a new deployment of ipa on centos, with just a couple of test > records. I don?t have much recent experience with LDAP, but I don?t see > what I?m doing wrong. Dirsrv on centos 6.5 works as expected. You don't get a separate entry back for each part of the filter that matches. If it matches on any one of the OR elements you get it back, otherwise you don't. In other words, for this type of search you're likely to get either one or zero entries back. I don't see why adding a non-existent attribute in the filter would cause it to do anything odd. That part of the filter should be a no-op. This worked for me: $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm "(|(uid=admin)(name=admin))" dn SASL/GSSAPI authentication started SASL username: admin at EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com Note that cn is Common Name which is set to the user's full name, in this case likely "George Boyce". So that will never match gboyce. rob From rcritten at redhat.com Tue May 19 20:56:53 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 May 2015 16:56:53 -0400 Subject: [Freeipa-users] getting rid of nsds5ReplConflict In-Reply-To: References: <555B66D5.2060604@redhat.com> Message-ID: <555BA395.4040104@redhat.com> Megan . wrote: > Thank you for the reply. I think I just got frustrated. I > uninstalled ipa on the dir2 replica then set it back up again as a > replica. Everything seems to be replicating just fine without errors > now. I know that this isn't the preferred or documented solution but > i needed the server back online asap. > > When i run "ipa-replica-manage list-ruv" i see dir2 listed twice. Is > this a concern? > > [root at dir1 ipa]# ipa-replica-manage list-ruv > dir1.example.com:389: 4 > dir3.example.com:389: 5 > dir2.example.com:389: 6 > dir2.example.com:389: 8 You should clean it up using the clean-ruv option of ipa-replica-manage. You should bind as Directory Manager and look in cn=mapping tree,cn=config for nsDS5ReplicaId you'll be able to see the active IDs. I'd guess that 6 is the one to be removed but a search will tell you for sure. rob From notify.sina at gmail.com Tue May 19 21:52:33 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Tue, 19 May 2015 22:52:33 +0100 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <555B55DE.8070007@redhat.com> References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> <555A28B3.8080503@redhat.com> <555B55DE.8070007@redhat.com> Message-ID: Hi Rob Thanks! I noticed that the problematic records have their expiration in the future! And I also do not have pki-tomcatd, it's pki-cad. >From getcert list, the troublesome IDs are: Request ID '20130524104828': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MYDOM-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:32 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104917': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes On Tue, May 19, 2015 at 4:25 PM, Rob Crittenden wrote: > Sina Owolabi wrote: >> >> Hi Rob >> >> Ive been to the URL but its a little difficult applying these commands >> to RHEL6 systems. >> For instance there is no /etc/pki-tomcat directory in RHEL6, and I >> cannot find the ipa.crt >> >> Im sure as a noob I am overlooking some very obvious stuff, but could >> you please guide me on what to do? > > > Sorry, I think I pointed you at the wrong page. Check out > http://www.freeipa.org/page/IPA_2x_Certificate_Renewal > > Your CA subsystem are expired, or nearly expired. They are valid for two > years. Based on the request ID in the snippet you posted at least some are > valid for another few days. > > What I'd suggest is to send the machine back in time and restart the > services. This should bring things up so that certmonger can do the renewal: > > # ipactl stop > # /sbin/service ntpd stop > # date 0501hhm where hhmm are the current hour and minute > # ipactl start > > Hopefully ntpd isn't started by ipactl. If it is then it will undo your > going back in time, and you'll need to start the services manually: > > # service dirsrv at YOURREALM start > # service krb5kdc > # service httpd start > # service pki-tomcatd start > > Restart certmonger > > # service certmonger restart > > Wait a bit > > # getcert list > > Watch the status. They should go to MODIFIED > > Once done: > > # ipactl stop > > Return date to present, either by restarting ntpd or date or whatever method > you'd like. > > I'm taking a completely wild guess on the date to go back to. The expiration > date is listed in the getcert output. I'd go back a week before the oldest > expiration. > > rob > From dpal at redhat.com Tue May 19 22:13:50 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 19 May 2015 18:13:50 -0400 Subject: [Freeipa-users] Replacing HTTP certs with public CA signed wildcard cert In-Reply-To: References: Message-ID: <555BB59E.1010908@redhat.com> On 05/14/2015 10:15 AM, David Little wrote: > Hi there, > > I was reading this document regarding using 3rd party certificates in > FreeIPA: > > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > Which includes the information "The certificate in mysite.crt must be > signed by the CA used when installing FreeIPA." > > Also this thread: > http://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html > > Which says at the end " I'm wondering if it's because of this from the > doc "The certificate in mysite.crt must be signed by the CA used when > installing FreeIPA." but it might not either... > > In this case you should get a "file.p12 is not signed by > /etc/ipa/ca.crt, or the full certificate chain is not > present in the PKCS#12 file" error in ipa-server-certinstall." > > This brings me to my question... If I have an existing multi-server > FreeIPA setup with multiple IPA client installations, using a > self-signed CA certificate for /etc/ipa/ca.crt, would I need to start > over the FreeIPA installation from scratch using the public root CA, > which signed the wildcard certificate? > > > > Thanks, > Dave > > > Did you get an answer? If not starting 4.1 IPA has a tool that can change the chaining and also convert from CA-less to CA-full. I am not sure it can do the reverse so you might in fact have to start over. http://www.freeipa.org/page/V4/CA-less_to_CA-full_conversion -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notify.sina at gmail.com Tue May 19 22:31:02 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Tue, 19 May 2015 23:31:02 +0100 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> <555A28B3.8080503@redhat.com> <555B55DE.8070007@redhat.com> Message-ID: Another key difference I noticed is that the problematic certs have CA:IPA in them, while the working certs have CA: dogtag-ipa-retrieve-agent-submit. getcert list Number of certificates and requests being tracked: 8. Request ID '20130524104636': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104731': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=CA Audit,O=MYDOM.COM expires: 2015-04-29 23:48:46 UTC key usage: digitalSignature,nonRepudiation pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104732': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=OCSP Subsystem,O=MYDOM.COM expires: 2015-04-29 23:48:45 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104733': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=CA Subsystem,O=MYDOM.COM expires: 2015-04-29 23:48:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104734': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2017-04-06 09:41:48 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104828': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MYDOM-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:32 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104917': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524105011': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=IPA RA,O=MYDOM.COM expires: 2015-04-29 23:49:29 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes On Tue, May 19, 2015 at 10:52 PM, Sina Owolabi wrote: > Hi Rob > > > Thanks! > I noticed that the problematic records have their expiration in the > future! And I also do not have pki-tomcatd, it's pki-cad. > > From getcert list, the troublesome IDs are: > > Request ID '20130524104828': > status: CA_UNREACHABLE > ca-error: Server at https://dc.mydom.com/ipa/xml failed > request, will retry: 907 (RPC failed at server. cannot connect to > 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -8053] > (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.). > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-MYDOM-COM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MYDOM.COM > subject: CN=dc.mydom.com,O=MYDOM.COM > expires: 2015-05-25 10:12:32 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20130524104917': > status: CA_UNREACHABLE > ca-error: Server at https://dc.mydom.com/ipa/xml failed > request, will retry: 907 (RPC failed at server. cannot connect to > 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] > (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as > expired.). > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MYDOM.COM > subject: CN=dc.mydom.com,O=MYDOM.COM > expires: 2015-05-25 10:12:33 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > On Tue, May 19, 2015 at 4:25 PM, Rob Crittenden wrote: >> Sina Owolabi wrote: >>> >>> Hi Rob >>> >>> Ive been to the URL but its a little difficult applying these commands >>> to RHEL6 systems. >>> For instance there is no /etc/pki-tomcat directory in RHEL6, and I >>> cannot find the ipa.crt >>> >>> Im sure as a noob I am overlooking some very obvious stuff, but could >>> you please guide me on what to do? >> >> >> Sorry, I think I pointed you at the wrong page. Check out >> http://www.freeipa.org/page/IPA_2x_Certificate_Renewal >> >> Your CA subsystem are expired, or nearly expired. They are valid for two >> years. Based on the request ID in the snippet you posted at least some are >> valid for another few days. >> >> What I'd suggest is to send the machine back in time and restart the >> services. This should bring things up so that certmonger can do the renewal: >> >> # ipactl stop >> # /sbin/service ntpd stop >> # date 0501hhm where hhmm are the current hour and minute >> # ipactl start >> >> Hopefully ntpd isn't started by ipactl. If it is then it will undo your >> going back in time, and you'll need to start the services manually: >> >> # service dirsrv at YOURREALM start >> # service krb5kdc >> # service httpd start >> # service pki-tomcatd start >> >> Restart certmonger >> >> # service certmonger restart >> >> Wait a bit >> >> # getcert list >> >> Watch the status. They should go to MODIFIED >> >> Once done: >> >> # ipactl stop >> >> Return date to present, either by restarting ntpd or date or whatever method >> you'd like. >> >> I'm taking a completely wild guess on the date to go back to. The expiration >> date is listed in the getcert output. I'd go back a week before the oldest >> expiration. >> >> rob >> From dpal at redhat.com Tue May 19 22:38:54 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 19 May 2015 18:38:54 -0400 Subject: [Freeipa-users] External Self Help Suggestions. In-Reply-To: <55552B3A.1040004@cenic.org> References: <5553E0DE.2010502@cenic.org> <5553E5A3.1080701@redhat.com> <5553E9E8.4060901@cenic.org> <5553EC45.9060101@redhat.com> <55552B3A.1040004@cenic.org> Message-ID: <555BBB7E.6070002@redhat.com> On 05/14/2015 07:09 PM, William Graboyes wrote: > Hi Dmitri, > > No I am sticking to the 90 day, gotta start the change in the right direction somewhere :). > > So I am trying out LBT Self service password, and I am wondering if there is documentation anywhere on how to create a service style account that has the ability to change a password without forcing the user to reset thier password on next login. This would be for if a user forgets thier password and uses a mail token style auth. Sorry for a delay I know there is a way to create such an account. It is not exposed in the UI Here is the ticket to do it in UI/CLI https://fedorahosted.org/freeipa/ticket/2801 But I do not remember the procedure of top of my head. It might be found in the archives as it was explained couple times in the past. > > Thanks, > Bill > On 5/13/15 5:28 PM, Dmitri Pal wrote: >> On 05/13/2015 08:18 PM, William Graboyes wrote: >>> Hi Dmitri, >>> >>> That is quite a bucket of stuff... On the CA-less install, basically I >>> don't want to have my users change their passwords again (they are >>> complaining about the every 90 day password rotation policy), we do >>> not have an internal CA, most of our "desk top support" folks don't >>> even have access to all of the desktops in the place. Like I said >>> this place is mind bending when it comes to standard practices. The >>> CA-less would be good if it were possible to make that change in >>> place, or make the change by standing up a new IPA server and having >>> the ability to import the current data set. >>> >>> I was looking at PWM, and may try to get that implemented. >> Another option is to reset expiration time in the user entry and set it >> some date close to 2038 which is the end of the 32-bit time. >> If the problem is 90 day policy you can just change the policy to be >> 5000 days and then next time people change password they would not be >> bother for another 5000 days or so (make sure it does not roll over). >> For people that already have 90 days in their entry you can run a script >> once and move the date into the future. >> >> People have done it for the same reason and in the same way. >> >>> Thanks, >>> Bill >>> >>> On 5/13/15 5:00 PM, Dmitri Pal wrote: >>>> On 05/13/2015 07:40 PM, William Graboyes wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA512 >>>>> >>>>> Hi List, >>>>> >>>>> I am trying to figure out a method of allowing users who do not have >>>>> shell access to change their own passwords. The GUI that comes with >>>>> FreeIPA is out of the question due to the untrusted CA (yes I know we >>>>> are a strange shop, there is nothing I can do about it, and you would >>>>> want to gouge you eyes out if I told you the full story) becoming a >>>>> "Bad habit forming" method of changing one's password. I have been >>>>> looking around for about a week now, and am somewhat lost and >>>>> perplexed. The old documentation for FreeIPA basically says that it is >>>>> not a good idea to manipulate the password directly in LDAP (and even >>>>> then finding what hash is being used has been next to impossible). >>>>> >>>>> So the question is this, does anyone know of any tools out there that >>>>> can happily, or even with some modification, allow me to set up a >>>>> trusted external ssl site that allows users to change their passwords. >>>> There is no external password reset self service in IPA yet. We will be >>>> starting to look into this effort during summer. >>>> Take a look at the bucket of tickets in the "FreeIPA Community Portal >>>> Release" here https://fedorahosted.org/freeipa/report/3. >>>> >>>> What prevents you from making IPA trusted? You can chain IPA to your CA >>>> or use it CA-less with certs from your own CA. >>>> Then UI would be an option I assume. >>>> >>>> Other option is https://code.google.com/p/pwm/ >>>> >>>>> Thanks, >>>>> Bill >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>>>> Comment: GPGTools - https://gpgtools.org >>>>> >>>>> iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 >>>>> MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc >>>>> bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV >>>>> UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU >>>>> NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm >>>>> zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW >>>>> /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK >>>>> ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml >>>>> 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ >>>>> 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 >>>>> ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX >>>>> kzyr3+tqYdDbgibcYyhd >>>>> =5KCr >>>>> -----END PGP SIGNATURE----- >>>>> >> -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. From janellenicole80 at gmail.com Wed May 20 00:57:05 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 19 May 2015 17:57:05 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555AE069.4010901@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> Message-ID: <555BDBE1.8060604@gmail.com> On 5/19/15 12:04 AM, thierry bordaz wrote: > On 05/19/2015 03:42 AM, Janelle wrote: >> On 5/18/15 6:23 PM, Janelle wrote: >>> Once again, replication/sync has been lost. I really wish the >>> product was more stable, it is so much potential and yet. >>> >>> Servers running for 6 days no issues. No new accounts or changes >>> (maybe a few users changing passwords) and again, 5 out of 16 >>> servers are no longer in sync. >>> >>> I can test it easily by adding an account and then waiting a few >>> minutes, then run "ipa user-show --all username" on all the >>> servers, and only a few of them have the account. I have now waited >>> 15 minutes, still no luck. >>> >>> Oh well.. I guess I will go look at alternatives. I had such high >>> hopes for this tool. Thanks so much everyone for all your help in >>> trying to get things stable, but for whatever reason, there is a >>> random loss of sync among the servers and obviously this is not >>> acceptable. >>> >>> regards >>> ~J >> All the replicas are happy again. I found these again: unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 What I also found to be interesting is that I have not deleted any masters at all, so this was quite perplexing where the orphaned entries came from. However I did find 3 of the replicas did not show complete RUV lists... While most of the replicas had a list of all 16 servers, a couple of them listed only 4 or 5. (using ipa-replica-manage list-ruv) Once I re-initialized --from servers that showed the correct RUVS everyone is happy again. I have tested replication by creating and deleting accounts, changing group members and a few other things. Everything is working fine. I have enabled additional logging. Now we wait and when it happens again, hopefully we have something. thanks ~Janelle -------------- next part -------------- An HTML attachment was scrubbed... URL: From dewanggaba at xtremenitro.org Wed May 20 02:28:47 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Wed, 20 May 2015 09:28:47 +0700 Subject: [Freeipa-users] Problem installing external SSL Certificate In-Reply-To: <555B3B13.9090301@xtremenitro.org> References: <555B3B13.9090301@xtremenitro.org> Message-ID: <555BF15F.508@xtremenitro.org> This is the verbose log, tried to convert them to p12 format (dont know it's right or not), still no luck. http://fpaste.org/223608/88775143/raw/ Ref: http://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html Any additional hints? On 05/19/2015 08:30 PM, Dewangga Bachrul Alam wrote: > Hello! > > I was build FreeIPA 4.1.4 on CentOS 7.1, the deployment was done, but > could I changes the HTTP and dirsv certificate? I have wildcard > certificate (thawte SSL CA - G2). It is compatible for FreeIPA (http and > dirsv)? > > I've tried to follow the instruction > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > but no luck. > > $ ipa-server-certinstall -wd mydomain.co.id.key \ > mydomain.co.id-bundled.crt > > Directory Manager password: > > Enter private key unlock password: > > The full certificate chain is not present in mydomain.co.id.key, > mydomain.co.id-bundled.crt > > FYI, mydomain.co.id-bundled.crt chain have SIGNED then INTERMEDIATE > certificate order. (2 chain) > > I've tried to bundling them using root certificate, still have no luck. > (3 chain, SIGNEDCERT, INTERMEDIATE, ROOTCERT). > > Any comments will be appreciated :) > Thanks > From sanju.a at tcs.com Wed May 20 06:55:37 2015 From: sanju.a at tcs.com (Sanju A) Date: Wed, 20 May 2015 12:25:37 +0530 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Message-ID: Hi, I am getting the following error while removing a host. --------------------------------------- Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) --------------------------------------- Apache log ------------------- [Wed May 20 12:10:26 2015] [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to communicate with CMS (Not Found) Regards Sanju Abraham =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 8147 bytes Desc: not available URL: From lkrispen at redhat.com Wed May 20 07:54:54 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 20 May 2015 09:54:54 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555BDBE1.8060604@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> Message-ID: <555C3DCE.8060102@redhat.com> On 05/20/2015 02:57 AM, Janelle wrote: > On 5/19/15 12:04 AM, thierry bordaz wrote: >> On 05/19/2015 03:42 AM, Janelle wrote: >>> On 5/18/15 6:23 PM, Janelle wrote: >>>> Once again, replication/sync has been lost. I really wish the >>>> product was more stable, it is so much potential and yet. >>>> >>>> Servers running for 6 days no issues. No new accounts or changes >>>> (maybe a few users changing passwords) and again, 5 out of 16 >>>> servers are no longer in sync. >>>> >>>> I can test it easily by adding an account and then waiting a few >>>> minutes, then run "ipa user-show --all username" on all the >>>> servers, and only a few of them have the account. I have now >>>> waited 15 minutes, still no luck. >>>> >>>> Oh well.. I guess I will go look at alternatives. I had such high >>>> hopes for this tool. Thanks so much everyone for all your help in >>>> trying to get things stable, but for whatever reason, there is a >>>> random loss of sync among the servers and obviously this is not >>>> acceptable. >>>> >>>> regards >>>> ~J >>> > > All the replicas are happy again. I found these again: > > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > > What I also found to be interesting is that I have not deleted any > masters at all, so this was quite perplexing where the orphaned > entries came from. However I did find 3 of the replicas did not show > complete RUV lists... While most of the replicas had a list of all 16 > servers, a couple of them listed only 4 or 5. (using > ipa-replica-manage list-ruv) so this happens "out of the blue" ? Did it happen at the same time, do you know when it started ? The maxcsns in the ruv are quite old: r16: apr,21, r23: may,14 r24: may,9 could it be that there was no change applied to these masters for that time ? > > Once I re-initialized --from servers that showed the correct RUVS > everyone is happy again. I have tested replication by creating and > deleting accounts, changing group members and a few other things. > Everything is working fine. I have enabled additional logging. > > Now we wait and when it happens again, hopefully we have something. > > thanks > ~Janelle > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From opsourcetrail at gmail.com Wed May 20 09:04:10 2015 From: opsourcetrail at gmail.com (opsource trail) Date: Wed, 20 May 2015 11:04:10 +0200 Subject: [Freeipa-users] IPA/AD domain trust - unidirectional or bidirectional? Message-ID: Hello, we plan to deploy IPA (Red Hat IdM) trust with AD domain but at the moment we are kind of confused about what type of trust we will need to deal with. In Red Hat documentation we get an information that: "... Trusts, then, are essentially unidirectional. Active Directory users can access IdM resources and services, but IdM users cannot access Active Directory resources... " ( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html ) On the other hand, when I configure the trust I can clearly see that it is actually bidirectional: [root at ipaserver ~]# ipa trust-add --type=ad adexample.com --admin Administrator --password ------------------------------------------------------ Added Active Directory trust for realm "adexample.com" ------------------------------------------------------ Realm name: adexample.com Domain NetBIOS name: ADEXAMPLE Domain Security Identifier: S-1-5-21-1689615952-3716327440-3249090444 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified I'm afraid that our Windows department will complain and consider this as a security issue. Is there anybody who could help me understand this? Thanks! All the best. Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed May 20 09:39:10 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 20 May 2015 12:39:10 +0300 Subject: [Freeipa-users] IPA/AD domain trust - unidirectional or bidirectional? In-Reply-To: References: Message-ID: <20150520093910.GK21881@redhat.com> On Wed, 20 May 2015, opsource trail wrote: >Hello, >we plan to deploy IPA (Red Hat IdM) trust with AD domain but at the moment >we are kind of confused about what type of trust we will need to deal with. >In Red Hat documentation we get an information that: > >"... Trusts, then, are essentially unidirectional. Active Directory users >can access IdM resources and services, but IdM users cannot access Active >Directory resources... " >( >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html >) I tried to get technical writers to rewrite this sentence but so far unsuccessful. There seems to be some fundamental misunderstanding at hand, unfortunately. >On the other hand, when I configure the trust I can clearly see that it is >actually bidirectional: >[root at ipaserver ~]# ipa trust-add --type=ad adexample.com --admin >Administrator --password >------------------------------------------------------ >Added Active Directory trust for realm "adexample.com" >------------------------------------------------------ > Realm name: adexample.com > Domain NetBIOS name: ADEXAMPLE > Domain Security Identifier: S-1-5-21-1689615952-3716327440-3249090444 > Trust direction: Two-way trust > Trust type: Active Directory domain > Trust status: Established and verified > >I'm afraid that our Windows department will complain and consider this as a >security issue. No, it is not a security issue, regardless what your Windows department would like to think. They may better spend time looking into actual Active Directory protocols documentation at https://msdn.microsoft.com/en-us/library/jj712081.aspx to realise situation is much more complex than a binary division between 'secure' and 'insecure'. >Is there anybody who could help me understand this? You can start with http://www.freeipa.org/page/V4/One-way_trust to get yourself a high level overview and comparison of what two-way and one-way trust mean in the context of IPA and Active Directory. -- / Alexander Bokovoy From opsourcetrail at gmail.com Wed May 20 09:47:05 2015 From: opsourcetrail at gmail.com (opsource trail) Date: Wed, 20 May 2015 11:47:05 +0200 Subject: [Freeipa-users] IPA/AD domain trust - unidirectional or bidirectional? In-Reply-To: <20150520093910.GK21881@redhat.com> References: <20150520093910.GK21881@redhat.com> Message-ID: Hi Alex, thanks for your prompt response. This more/less sums up our arguments, but definitely the AD protocol documentation might be helpful. Best regards, Jan 2015-05-20 11:39 GMT+02:00 Alexander Bokovoy : > On Wed, 20 May 2015, opsource trail wrote: > >> Hello, >> we plan to deploy IPA (Red Hat IdM) trust with AD domain but at the moment >> we are kind of confused about what type of trust we will need to deal >> with. >> In Red Hat documentation we get an information that: >> >> "... Trusts, then, are essentially unidirectional. Active Directory users >> can access IdM resources and services, but IdM users cannot access Active >> Directory resources... " >> ( >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html >> ) >> > I tried to get technical writers to rewrite this sentence but so far > unsuccessful. There seems to be some fundamental misunderstanding at > hand, unfortunately. > > On the other hand, when I configure the trust I can clearly see that it is >> actually bidirectional: >> [root at ipaserver ~]# ipa trust-add --type=ad adexample.com --admin >> Administrator --password >> ------------------------------------------------------ >> Added Active Directory trust for realm "adexample.com" >> ------------------------------------------------------ >> Realm name: adexample.com >> Domain NetBIOS name: ADEXAMPLE >> Domain Security Identifier: S-1-5-21-1689615952-3716327440-3249090444 >> Trust direction: Two-way trust >> Trust type: Active Directory domain >> Trust status: Established and verified >> >> I'm afraid that our Windows department will complain and consider this as >> a >> security issue. >> > No, it is not a security issue, regardless what your Windows department > would like to think. They may better spend time looking into actual > Active Directory protocols documentation at > https://msdn.microsoft.com/en-us/library/jj712081.aspx to realise > situation is much more complex than a binary division between 'secure' > and 'insecure'. > > Is there anybody who could help me understand this? >> > You can start with http://www.freeipa.org/page/V4/One-way_trust to get > yourself a high level overview and comparison of what two-way and > one-way trust mean in the context of IPA and Active Directory. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dewanggaba at xtremenitro.org Wed May 20 09:54:56 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Wed, 20 May 2015 16:54:56 +0700 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env Message-ID: <555C59F0.5020905@xtremenitro.org> Hello! I've tried to setup my IPA server to work on multiple domain env, for the example, I have 20 instance/servers using mydomain.co.id then I have another 10 instance/servers using mydomain.com, I want to manage both of them on same IPA server. On instance with mydomain.com, I've setup and point my DNS to the IPA Server, the DNS Discovery was failed, but if I entered IPA server address manually, the setup was success. --- [root at joyoboyo ~]# getent passwd dewangga dewangga:*:940000001:940000001:Dewangga Alam:/home/dewangga:/bin/bash [root at joyoboyo ~]# uname -a Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux --- Is it normal? Or is there another configuration on krb5.conf? I found something interesting on [domain_realm] section, but before I changes them, better I ask to the mailing list. Thanks for any help and comments, this is my first time to configure IPA Server :D From pspacek at redhat.com Wed May 20 10:30:45 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 May 2015 12:30:45 +0200 Subject: [Freeipa-users] AD-trust and external DNS In-Reply-To: References: <5559F2B0.6050507@dds.nl> Message-ID: <555C6255.50507@redhat.com> Hello, please let me correct this: IPA cares only about correct DNS records. It does not matter if IPA manages the DNS server or if the server is external entity - everything will work as long as all records are in place. IPA installers should give you standard zone file which can be added to existing DNS servers. On 18.5.2015 16:13, Baird, Josh wrote: > You should add your IPA zone as a slave on your 'external' DNS servers so they are able to resolve the IPA zone. If you decide to use IPA DNS then you *most importantly* need to add proper NS records to the parent zone to ensure that DNS delegation is correct. Slave zones are just 'nice to have' for improved resiliency but they should never be used instead of proper NS records. Let me know if you are interested in some other details. Petr^2 Spacek > Josh > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Winfried de Heiden > Sent: Monday, May 18, 2015 10:10 AM > To: Freeipa-users > Subject: [Freeipa-users] AD-trust and external DNS > > Hi all, > > Creating an AD-trust works nicely. However, for some customers both AD and IPA don't have have DNS "for their own", the use external DNS (Infoblox for example) > > Now, is is possible to create an AD trust without a build-in (bind) IPA-DNS? From mkosek at redhat.com Wed May 20 10:30:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 May 2015 12:30:46 +0200 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env In-Reply-To: <555C59F0.5020905@xtremenitro.org> References: <555C59F0.5020905@xtremenitro.org> Message-ID: <555C6256.1090503@redhat.com> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote: > Hello! > > I've tried to setup my IPA server to work on multiple domain env, for > the example, I have 20 instance/servers using mydomain.co.id then I have > another 10 instance/servers using mydomain.com, I want to manage both of > them on same IPA server. This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS TXT record with the ream, Kerberos client should be able to find the right IPA server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA versions add this record to owned DNS zones automatically. > On instance with mydomain.com, I've setup and point my DNS to the IPA > Server, the DNS Discovery was failed, but if I entered IPA server > address manually, the setup was success. If autodiscovery with hosts in your alternate domain does not work, you can also use just # ipa-client-install --domain main.ipa.domain.com and it should find the IPA server. > > --- > [root at joyoboyo ~]# getent passwd dewangga > dewangga:*:940000001:940000001:Dewangga Alam:/home/dewangga:/bin/bash > [root at joyoboyo ~]# uname -a > Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 > 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > --- > > Is it normal? Or is there another configuration on krb5.conf? I found > something interesting on [domain_realm] section, but before I changes > them, better I ask to the mailing list. What I see above looks normal to me. [domain_realm] manual mapping can be used if you have DNS autodiscovery disabled or you miss the DNS TXT record for Kerberos, IIRC. > > Thanks for any help and comments, this is my first time to configure IPA > Server :D Good, I hope you like it :-) From dewanggaba at xtremenitro.org Wed May 20 10:38:32 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Wed, 20 May 2015 17:38:32 +0700 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env In-Reply-To: <555C6256.1090503@redhat.com> References: <555C59F0.5020905@xtremenitro.org> <555C6256.1090503@redhat.com> Message-ID: <555C6428.1060204@xtremenitro.org> Hello! On 05/20/2015 05:30 PM, Martin Kosek wrote: > On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote: >> Hello! >> >> I've tried to setup my IPA server to work on multiple domain env, for >> the example, I have 20 instance/servers using mydomain.co.id then I have >> another 10 instance/servers using mydomain.com, I want to manage both of >> them on same IPA server. > > This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS > TXT record with the ream, Kerberos client should be able to find the right IPA > server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA > versions add this record to owned DNS zones automatically. TXT record said like this : $ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw .. some content skipped .. $ORIGIN mydomain.com. _kerberos TXT "MYDOMAIN.CO.ID" joyoboyo A 103.xx.yy.98 liquid A 103.xx.yy.100 Should I changes it? Or leave it as is? >> On instance with mydomain.com, I've setup and point my DNS to the IPA >> Server, the DNS Discovery was failed, but if I entered IPA server >> address manually, the setup was success. > > If autodiscovery with hosts in your alternate domain does not work, you can > also use just > > # ipa-client-install --domain main.ipa.domain.com > > and it should find the IPA server. > >> >> --- >> [root at joyoboyo ~]# getent passwd dewangga >> dewangga:*:940000001:940000001:Dewangga Alam:/home/dewangga:/bin/bash >> [root at joyoboyo ~]# uname -a >> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 >> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >> --- >> >> Is it normal? Or is there another configuration on krb5.conf? I found >> something interesting on [domain_realm] section, but before I changes >> them, better I ask to the mailing list. > > What I see above looks normal to me. [domain_realm] manual mapping can be used > if you have DNS autodiscovery disabled or you miss the DNS TXT record for > Kerberos, IIRC. > >> >> Thanks for any help and comments, this is my first time to configure IPA >> Server :D > > Good, I hope you like it :-) > And what if I setup replica IPA server, did mydomain.com will be distributed to another replicated IPA server? Thanks From mkosek at redhat.com Wed May 20 10:42:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 May 2015 12:42:46 +0200 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env In-Reply-To: <555C6428.1060204@xtremenitro.org> References: <555C59F0.5020905@xtremenitro.org> <555C6256.1090503@redhat.com> <555C6428.1060204@xtremenitro.org> Message-ID: <555C6526.6000409@redhat.com> On 05/20/2015 12:38 PM, Dewangga Bachrul Alam wrote: > Hello! > > On 05/20/2015 05:30 PM, Martin Kosek wrote: >> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote: >>> Hello! >>> >>> I've tried to setup my IPA server to work on multiple domain env, for >>> the example, I have 20 instance/servers using mydomain.co.id then I have >>> another 10 instance/servers using mydomain.com, I want to manage both of >>> them on same IPA server. >> >> This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS >> TXT record with the ream, Kerberos client should be able to find the right IPA >> server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA >> versions add this record to owned DNS zones automatically. > > TXT record said like this : > > $ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw > > .. some content skipped .. > > $ORIGIN mydomain.com. > _kerberos TXT "MYDOMAIN.CO.ID" > joyoboyo A 103.xx.yy.98 > liquid A 103.xx.yy.100 > > Should I changes it? Or leave it as is? If this is the alternate DNS domain (REALM != DNS domain name), this should be fine and Kerberos client should be able to tell which KDC/realm is responsible for this domain. >>> On instance with mydomain.com, I've setup and point my DNS to the IPA >>> Server, the DNS Discovery was failed, but if I entered IPA server >>> address manually, the setup was success. >> >> If autodiscovery with hosts in your alternate domain does not work, you can >> also use just >> >> # ipa-client-install --domain main.ipa.domain.com >> >> and it should find the IPA server. >> >>> >>> --- >>> [root at joyoboyo ~]# getent passwd dewangga >>> dewangga:*:940000001:940000001:Dewangga Alam:/home/dewangga:/bin/bash >>> [root at joyoboyo ~]# uname -a >>> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 >>> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>> --- >>> >>> Is it normal? Or is there another configuration on krb5.conf? I found >>> something interesting on [domain_realm] section, but before I changes >>> them, better I ask to the mailing list. >> >> What I see above looks normal to me. [domain_realm] manual mapping can be used >> if you have DNS autodiscovery disabled or you miss the DNS TXT record for >> Kerberos, IIRC. >> >>> >>> Thanks for any help and comments, this is my first time to configure IPA >>> Server :D >> >> Good, I hope you like it :-) >> > > And what if I setup replica IPA server, did mydomain.com will be > distributed to another replicated IPA server? Yup, all IPA data are replicated between masters. From dewanggaba at xtremenitro.org Wed May 20 10:56:31 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Wed, 20 May 2015 17:56:31 +0700 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env In-Reply-To: <555C6526.6000409@redhat.com> References: <555C59F0.5020905@xtremenitro.org> <555C6256.1090503@redhat.com> <555C6428.1060204@xtremenitro.org> <555C6526.6000409@redhat.com> Message-ID: <555C685F.6020902@xtremenitro.org> Thanks Martin, Better I leave the configuration as is :D So, If I want to add another domain, I just add and point them to master IPA Server, right? And add DNS Zone, A Rec, etc on IPA server by using `ipa dnsrecord-add`. Isn't it? On 05/20/2015 05:42 PM, Martin Kosek wrote: > On 05/20/2015 12:38 PM, Dewangga Bachrul Alam wrote: >> Hello! >> >> On 05/20/2015 05:30 PM, Martin Kosek wrote: >>> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote: >>>> Hello! >>>> >>>> I've tried to setup my IPA server to work on multiple domain env, for >>>> the example, I have 20 instance/servers using mydomain.co.id then I have >>>> another 10 instance/servers using mydomain.com, I want to manage both of >>>> them on same IPA server. >>> >>> This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS >>> TXT record with the ream, Kerberos client should be able to find the right IPA >>> server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA >>> versions add this record to owned DNS zones automatically. >> >> TXT record said like this : >> >> $ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw >> >> .. some content skipped .. >> >> $ORIGIN mydomain.com. >> _kerberos TXT "MYDOMAIN.CO.ID" >> joyoboyo A 103.xx.yy.98 >> liquid A 103.xx.yy.100 >> >> Should I changes it? Or leave it as is? > > If this is the alternate DNS domain (REALM != DNS domain name), this should be > fine and Kerberos client should be able to tell which KDC/realm is responsible > for this domain. > >>>> On instance with mydomain.com, I've setup and point my DNS to the IPA >>>> Server, the DNS Discovery was failed, but if I entered IPA server >>>> address manually, the setup was success. >>> >>> If autodiscovery with hosts in your alternate domain does not work, you can >>> also use just >>> >>> # ipa-client-install --domain main.ipa.domain.com >>> >>> and it should find the IPA server. >>> >>>> >>>> --- >>>> [root at joyoboyo ~]# getent passwd dewangga >>>> dewangga:*:940000001:940000001:Dewangga Alam:/home/dewangga:/bin/bash >>>> [root at joyoboyo ~]# uname -a >>>> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 >>>> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>> --- >>>> >>>> Is it normal? Or is there another configuration on krb5.conf? I found >>>> something interesting on [domain_realm] section, but before I changes >>>> them, better I ask to the mailing list. >>> >>> What I see above looks normal to me. [domain_realm] manual mapping can be used >>> if you have DNS autodiscovery disabled or you miss the DNS TXT record for >>> Kerberos, IIRC. >>> >>>> >>>> Thanks for any help and comments, this is my first time to configure IPA >>>> Server :D >>> >>> Good, I hope you like it :-) >>> >> >> And what if I setup replica IPA server, did mydomain.com will be >> distributed to another replicated IPA server? > > Yup, all IPA data are replicated between masters. > From mkosek at redhat.com Wed May 20 11:01:10 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 May 2015 13:01:10 +0200 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env In-Reply-To: <555C685F.6020902@xtremenitro.org> References: <555C59F0.5020905@xtremenitro.org> <555C6256.1090503@redhat.com> <555C6428.1060204@xtremenitro.org> <555C6526.6000409@redhat.com> <555C685F.6020902@xtremenitro.org> Message-ID: <555C6976.7020606@redhat.com> On 05/20/2015 12:56 PM, Dewangga Bachrul Alam wrote: > Thanks Martin, > > Better I leave the configuration as is :D > > So, If I want to add another domain, I just add and point them to master > IPA Server, right? Right, after FreeIPA 3.2 (https://fedorahosted.org/freeipa/ticket/3544), dnszone-add should be enough to generate the DNS record to solve the Kerberos side. > And add DNS Zone, A Rec, etc on IPA server by using > `ipa dnsrecord-add`. > > Isn't it? Should be. From pspacek at redhat.com Wed May 20 11:02:34 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 May 2015 13:02:34 +0200 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env In-Reply-To: <555C685F.6020902@xtremenitro.org> References: <555C59F0.5020905@xtremenitro.org> <555C6256.1090503@redhat.com> <555C6428.1060204@xtremenitro.org> <555C6526.6000409@redhat.com> <555C685F.6020902@xtremenitro.org> Message-ID: <555C69CA.9000405@redhat.com> On 20.5.2015 12:56, Dewangga Bachrul Alam wrote: > Thanks Martin, > > Better I leave the configuration as is :D > > So, If I want to add another domain, I just add and point them to master > IPA Server, right? And add DNS Zone, A Rec, etc on IPA server by using > `ipa dnsrecord-add`. > > Isn't it? Yes, + you have to add NS record *to the parent zone* so all clients know which servers are responsible for the new domain. Petr^2 Spacek > > On 05/20/2015 05:42 PM, Martin Kosek wrote: >> On 05/20/2015 12:38 PM, Dewangga Bachrul Alam wrote: >>> Hello! >>> >>> On 05/20/2015 05:30 PM, Martin Kosek wrote: >>>> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote: >>>>> Hello! >>>>> >>>>> I've tried to setup my IPA server to work on multiple domain env, for >>>>> the example, I have 20 instance/servers using mydomain.co.id then I have >>>>> another 10 instance/servers using mydomain.com, I want to manage both of >>>>> them on same IPA server. >>>> >>>> This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS >>>> TXT record with the ream, Kerberos client should be able to find the right IPA >>>> server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA >>>> versions add this record to owned DNS zones automatically. >>> >>> TXT record said like this : >>> >>> $ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw >>> >>> .. some content skipped .. >>> >>> $ORIGIN mydomain.com. >>> _kerberos TXT "MYDOMAIN.CO.ID" >>> joyoboyo A 103.xx.yy.98 >>> liquid A 103.xx.yy.100 >>> >>> Should I changes it? Or leave it as is? >> >> If this is the alternate DNS domain (REALM != DNS domain name), this should be >> fine and Kerberos client should be able to tell which KDC/realm is responsible >> for this domain. >> >>>>> On instance with mydomain.com, I've setup and point my DNS to the IPA >>>>> Server, the DNS Discovery was failed, but if I entered IPA server >>>>> address manually, the setup was success. >>>> >>>> If autodiscovery with hosts in your alternate domain does not work, you can >>>> also use just >>>> >>>> # ipa-client-install --domain main.ipa.domain.com >>>> >>>> and it should find the IPA server. >>>> >>>>> >>>>> --- >>>>> [root at joyoboyo ~]# getent passwd dewangga >>>>> dewangga:*:940000001:940000001:Dewangga Alam:/home/dewangga:/bin/bash >>>>> [root at joyoboyo ~]# uname -a >>>>> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 >>>>> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>>> --- >>>>> >>>>> Is it normal? Or is there another configuration on krb5.conf? I found >>>>> something interesting on [domain_realm] section, but before I changes >>>>> them, better I ask to the mailing list. >>>> >>>> What I see above looks normal to me. [domain_realm] manual mapping can be used >>>> if you have DNS autodiscovery disabled or you miss the DNS TXT record for >>>> Kerberos, IIRC. >>>> >>>>> >>>>> Thanks for any help and comments, this is my first time to configure IPA >>>>> Server :D >>>> >>>> Good, I hope you like it :-) >>>> >>> >>> And what if I setup replica IPA server, did mydomain.com will be >>> distributed to another replicated IPA server? >> >> Yup, all IPA data are replicated between masters. >> > -- Petr^2 Spacek From dewanggaba at xtremenitro.org Wed May 20 11:09:17 2015 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Wed, 20 May 2015 18:09:17 +0700 Subject: [Freeipa-users] Configure IPA Server work with Multiple domain Env In-Reply-To: <555C69CA.9000405@redhat.com> References: <555C59F0.5020905@xtremenitro.org> <555C6256.1090503@redhat.com> <555C6428.1060204@xtremenitro.org> <555C6526.6000409@redhat.com> <555C685F.6020902@xtremenitro.org> <555C69CA.9000405@redhat.com> Message-ID: <555C6B5D.8060808@xtremenitro.org> Yes, of course. I will add NS record to parent zone if my IPA server are ready for production. :D Thanks for any comments and help. Cheers! :) On 05/20/2015 06:02 PM, Petr Spacek wrote: > On 20.5.2015 12:56, Dewangga Bachrul Alam wrote: >> Thanks Martin, >> >> Better I leave the configuration as is :D >> >> So, If I want to add another domain, I just add and point them to master >> IPA Server, right? And add DNS Zone, A Rec, etc on IPA server by using >> `ipa dnsrecord-add`. >> >> Isn't it? > > Yes, + you have to add NS record *to the parent zone* so all clients know > which servers are responsible for the new domain. > > Petr^2 Spacek > >> >> On 05/20/2015 05:42 PM, Martin Kosek wrote: >>> On 05/20/2015 12:38 PM, Dewangga Bachrul Alam wrote: >>>> Hello! >>>> >>>> On 05/20/2015 05:30 PM, Martin Kosek wrote: >>>>> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote: >>>>>> Hello! >>>>>> >>>>>> I've tried to setup my IPA server to work on multiple domain env, for >>>>>> the example, I have 20 instance/servers using mydomain.co.id then I have >>>>>> another 10 instance/servers using mydomain.com, I want to manage both of >>>>>> them on same IPA server. >>>>> >>>>> This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS >>>>> TXT record with the ream, Kerberos client should be able to find the right IPA >>>>> server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA >>>>> versions add this record to owned DNS zones automatically. >>>> >>>> TXT record said like this : >>>> >>>> $ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw >>>> >>>> .. some content skipped .. >>>> >>>> $ORIGIN mydomain.com. >>>> _kerberos TXT "MYDOMAIN.CO.ID" >>>> joyoboyo A 103.xx.yy.98 >>>> liquid A 103.xx.yy.100 >>>> >>>> Should I changes it? Or leave it as is? >>> >>> If this is the alternate DNS domain (REALM != DNS domain name), this should be >>> fine and Kerberos client should be able to tell which KDC/realm is responsible >>> for this domain. >>> >>>>>> On instance with mydomain.com, I've setup and point my DNS to the IPA >>>>>> Server, the DNS Discovery was failed, but if I entered IPA server >>>>>> address manually, the setup was success. >>>>> >>>>> If autodiscovery with hosts in your alternate domain does not work, you can >>>>> also use just >>>>> >>>>> # ipa-client-install --domain main.ipa.domain.com >>>>> >>>>> and it should find the IPA server. >>>>> >>>>>> >>>>>> --- >>>>>> [root at joyoboyo ~]# getent passwd dewangga >>>>>> dewangga:*:940000001:940000001:Dewangga Alam:/home/dewangga:/bin/bash >>>>>> [root at joyoboyo ~]# uname -a >>>>>> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 >>>>>> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>>>> --- >>>>>> >>>>>> Is it normal? Or is there another configuration on krb5.conf? I found >>>>>> something interesting on [domain_realm] section, but before I changes >>>>>> them, better I ask to the mailing list. >>>>> >>>>> What I see above looks normal to me. [domain_realm] manual mapping can be used >>>>> if you have DNS autodiscovery disabled or you miss the DNS TXT record for >>>>> Kerberos, IIRC. >>>>> >>>>>> >>>>>> Thanks for any help and comments, this is my first time to configure IPA >>>>>> Server :D >>>>> >>>>> Good, I hope you like it :-) >>>>> >>>> >>>> And what if I setup replica IPA server, did mydomain.com will be >>>> distributed to another replicated IPA server? >>> >>> Yup, all IPA data are replicated between masters. >>> >> > > From natxo.asenjo at gmail.com Wed May 20 11:15:48 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 20 May 2015 13:15:48 +0200 Subject: [Freeipa-users] host usercertificate attribute In-Reply-To: <5559ED35.8000200@redhat.com> References: <5559ED35.8000200@redhat.com> Message-ID: hi rob, On Mon, May 18, 2015 at 3:46 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > >> On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo > > wrote: >> >> hi, >> >> If I retrieve the usercertificate attribute for host objects I get >> some gibberish. >> >> How can I decode the info I get from ldapsearch? >> >> >> maybe there is a way to feed that to openssl. What I ended up doing was >> using Perl and Crypt::X509 and I can see all the certificate elements. >> > > They are DER-encoded files. Something like this will show the contents: > > $ openssl x509 -text -in /tmp/file > $ openssl x509 -text -in ldapsearch-usercertificate-ZWnfJL unable to load certificate 139637925009264:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE Apparently it misses some stuff. As I wrote, I already got what I needed using perl, but maybe there are other ways. Thanks! -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 20 12:08:05 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 May 2015 08:08:05 -0400 Subject: [Freeipa-users] host usercertificate attribute In-Reply-To: References: <5559ED35.8000200@redhat.com> Message-ID: <555C7925.1090202@redhat.com> Natxo Asenjo wrote: > hi rob, > > On Mon, May 18, 2015 at 3:46 PM, Rob Crittenden > wrote: > > Natxo Asenjo wrote: > > On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo > > >> > wrote: > > hi, > > If I retrieve the usercertificate attribute for host > objects I get > some gibberish. > > How can I decode the info I get from ldapsearch? > > > maybe there is a way to feed that to openssl. What I ended up > doing was > using Perl and Crypt::X509 and I can see all the certificate > elements. > > > They are DER-encoded files. Something like this will show the contents: > > $ openssl x509 -text -in /tmp/file > > > $ openssl x509 -text -in ldapsearch-usercertificate-ZWnfJL > unable to load certificate > 139637925009264:error:0906D06C:PEM routines:PEM_read_bio:no start > line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE > > Apparently it misses some stuff. You could try adding -inform DER > As I wrote, I already got what I needed using perl, but maybe there are > other ways. rob From natxo.asenjo at gmail.com Wed May 20 12:59:37 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 20 May 2015 14:59:37 +0200 Subject: [Freeipa-users] host usercertificate attribute In-Reply-To: <555C7925.1090202@redhat.com> References: <5559ED35.8000200@redhat.com> <555C7925.1090202@redhat.com> Message-ID: hi Rob, On Wed, May 20, 2015 at 2:08 PM, Rob Crittenden wrote: > Nat > You could try adding -inform DER > cool, that works ;-) Thanks. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Wed May 20 13:01:42 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 20 May 2015 15:01:42 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555BDBE1.8060604@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> Message-ID: <555C85B6.2050104@redhat.com> On 05/20/2015 02:57 AM, Janelle wrote: > On 5/19/15 12:04 AM, thierry bordaz wrote: >> On 05/19/2015 03:42 AM, Janelle wrote: >>> On 5/18/15 6:23 PM, Janelle wrote: >>>> Once again, replication/sync has been lost. I really wish the >>>> product was more stable, it is so much potential and yet. >>>> >>>> Servers running for 6 days no issues. No new accounts or changes >>>> (maybe a few users changing passwords) and again, 5 out of 16 >>>> servers are no longer in sync. >>>> >>>> I can test it easily by adding an account and then waiting a few >>>> minutes, then run "ipa user-show --all username" on all the >>>> servers, and only a few of them have the account. I have now >>>> waited 15 minutes, still no luck. >>>> >>>> Oh well.. I guess I will go look at alternatives. I had such high >>>> hopes for this tool. Thanks so much everyone for all your help in >>>> trying to get things stable, but for whatever reason, there is a >>>> random loss of sync among the servers and obviously this is not >>>> acceptable. >>>> >>>> regards >>>> ~J >>> > > All the replicas are happy again. I found these again: > > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > > What I also found to be interesting is that I have not deleted any > masters at all, so this was quite perplexing where the orphaned > entries came from. However I did find 3 of the replicas did not show > complete RUV lists... While most of the replicas had a list of all 16 > servers, a couple of them listed only 4 or 5. (using > ipa-replica-manage list-ruv) I don't know about the orphaned entries. Did you get entries below deleted parents ? AFAIK all replicas are master and so have an entry {replica } in the RUV. We should expect all servers having the same number of RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated so that they did not received updates from those with 16 RUVelements. would you copy/paste an example of RUV with 16 and with 4-5 ? > > Once I re-initialized --from servers that showed the correct RUVS > everyone is happy again. I have tested replication by creating and > deleting accounts, changing group members and a few other things. > Everything is working fine. I have enabled additional logging. > > Now we wait and when it happens again, hopefully we have something. Yes, it will help :-) thanks thierry > > thanks > ~Janelle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Wed May 20 13:25:21 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 20 May 2015 06:25:21 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555C3DCE.8060102@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C3DCE.8060102@redhat.com> Message-ID: <555C8B41.5010502@gmail.com> On 5/20/15 12:54 AM, Ludwig Krispenz wrote: > > On 05/20/2015 02:57 AM, Janelle wrote: >> On 5/19/15 12:04 AM, thierry bordaz wrote: >>> On 05/19/2015 03:42 AM, Janelle wrote: >>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>> Once again, replication/sync has been lost. I really wish the >>>>> product was more stable, it is so much potential and yet. >>>>> >>>>> Servers running for 6 days no issues. No new accounts or changes >>>>> (maybe a few users changing passwords) and again, 5 out of 16 >>>>> servers are no longer in sync. >>>>> >>>>> I can test it easily by adding an account and then waiting a few >>>>> minutes, then run "ipa user-show --all username" on all the >>>>> servers, and only a few of them have the account. I have now >>>>> waited 15 minutes, still no luck. >>>>> >>>>> Oh well.. I guess I will go look at alternatives. I had such high >>>>> hopes for this tool. Thanks so much everyone for all your help in >>>>> trying to get things stable, but for whatever reason, there is a >>>>> random loss of sync among the servers and obviously this is not >>>>> acceptable. >>>>> >>>>> regards >>>>> ~J >>>> >> >> All the replicas are happy again. I found these again: >> >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> >> What I also found to be interesting is that I have not deleted any >> masters at all, so this was quite perplexing where the orphaned >> entries came from. However I did find 3 of the replicas did not show >> complete RUV lists... While most of the replicas had a list of all 16 >> servers, a couple of them listed only 4 or 5. (using >> ipa-replica-manage list-ruv) > so this happens "out of the blue" ? Did it happen at the same time, do > you know when it started ? The maxcsns in the ruv are quite old: r16: > apr,21, r23: may,14 r24: may,9 could it be that there was no change > applied to these masters for that time ? >> Indeed yes, that is a correct statement. It seems to be incredibly random. Ok, I give up - how are you finding the date in the strings? And really, is May 14th that old? What is odd about the Apr 21st one, is that if you see my previous emails, I had cleaned up all of this before, so for that to "re-appear" is indeed a mystery. As of this morning, things remain clean. What will be funny, now that I had extended logging enabled, they know we are on to them, so the servers won't fail again. :-) ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 20 13:32:51 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 May 2015 09:32:51 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> <555A28B3.8080503@redhat.com> <555B55DE.8070007@redhat.com> Message-ID: <555C8D03.3050709@redhat.com> Sina Owolabi wrote: > Another key difference I noticed is that the problematic certs have > CA:IPA in them, while the working certs have CA: > dogtag-ipa-retrieve-agent-submit. Ok, the full output is really helpful. First an explanation of CA subsystem renewal. CA clones are just that, exact clones of each other, which means they use the same subsystem certificates for OCSP, audit, etc. This also means that at renewal time they need to be renewed on only one master and then somehow shared with the ohter clones. The initially-installed CA is designated as the renewal master by default. It configures certmonger to renew the CA subsytem certificates and put the new public cert into a shared area in IPA that will be replicated to the other masters. The non-renewal masters are configured with a special CA, dogtag-ipa-retrieve-agent-submit, that looks in this shared area for an updated certificate and when available, it installs it. So the issue is that it isn't seeing this updated certificate, hence CA_WORKING. The CA_UNREACHABLE are due to the fact that the IPA RA agent certificate that IPA uses to talk to the CA expired on 04/29. So the steps you need to take are: 1. Check your other CA masters and see if they have been renewed properly (getcert list will tell you, look for expiration in 2017). 2. If they have, see if the data was pushed to LDAP $ kinit admin $ ldapsearch -Y GSSAPI -b cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com See if there are certificate entries there. Check on multiple masters to see if there is a replication issue. If the certs are there you can try restarting certmonger to kickstart the request. rob From rcritten at redhat.com Wed May 20 13:33:59 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 May 2015 09:33:59 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: Message-ID: <555C8D47.7030306@redhat.com> Sanju A wrote: > Hi, > > I am getting the following error while removing a host. > > --------------------------------------- > Certificate operation cannot be completed: Unable to communicate with > CMS (Not Found) > --------------------------------------- This usually means that the CA is not serving requestss. It may be up and running but that doesn't mean the webapp is working. This is often due to expired CA subsystem certificates. Run getcert list to check. rob From notify.sina at gmail.com Wed May 20 13:42:44 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Wed, 20 May 2015 13:42:44 +0000 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <555C8D03.3050709@redhat.com> References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> <555A28B3.8080503@redhat.com> <555B55DE.8070007@redhat.com> <555C8D03.3050709@redhat.com> Message-ID: Hi Rob This is the only CA master. The one I cloned it from was decommissioned, reinstalled and then made to be a replica of this server. Looks like I'm really stuck. How do I export the data out so I can reinstall from scratch, if possible? There are a lot of rules and configuration data I'd really like to keep. On Wed, May 20, 2015, 2:32 PM Rob Crittenden wrote: > Sina Owolabi wrote: > > Another key difference I noticed is that the problematic certs have > > CA:IPA in them, while the working certs have CA: > > dogtag-ipa-retrieve-agent-submit. > > Ok, the full output is really helpful. > > First an explanation of CA subsystem renewal. > > CA clones are just that, exact clones of each other, which means they > use the same subsystem certificates for OCSP, audit, etc. This also > means that at renewal time they need to be renewed on only one master > and then somehow shared with the ohter clones. > > The initially-installed CA is designated as the renewal master by > default. It configures certmonger to renew the CA subsytem certificates > and put the new public cert into a shared area in IPA that will be > replicated to the other masters. > > The non-renewal masters are configured with a special CA, > dogtag-ipa-retrieve-agent-submit, that looks in this shared area for an > updated certificate and when available, it installs it. > > So the issue is that it isn't seeing this updated certificate, hence > CA_WORKING. > > The CA_UNREACHABLE are due to the fact that the IPA RA agent certificate > that IPA uses to talk to the CA expired on 04/29. > > So the steps you need to take are: > > 1. Check your other CA masters and see if they have been renewed > properly (getcert list will tell you, look for expiration in 2017). > 2. If they have, see if the data was pushed to LDAP > > $ kinit admin > $ ldapsearch -Y GSSAPI -b cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com > > See if there are certificate entries there. Check on multiple masters to > see if there is a replication issue. > > If the certs are there you can try restarting certmonger to kickstart > the request. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Wed May 20 13:46:49 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 20 May 2015 06:46:49 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555C85B6.2050104@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> Message-ID: <555C9049.70607@gmail.com> On 5/20/15 6:01 AM, thierry bordaz wrote: > On 05/20/2015 02:57 AM, Janelle wrote: >> On 5/19/15 12:04 AM, thierry bordaz wrote: >>> On 05/19/2015 03:42 AM, Janelle wrote: >>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>> Once again, replication/sync has been lost. I really wish the >>>>> product was more stable, it is so much potential and yet. >>>>> >>>>> Servers running for 6 days no issues. No new accounts or changes >>>>> (maybe a few users changing passwords) and again, 5 out of 16 >>>>> servers are no longer in sync. >>>>> >>>>> I can test it easily by adding an account and then waiting a few >>>>> minutes, then run "ipa user-show --all username" on all the >>>>> servers, and only a few of them have the account. I have now >>>>> waited 15 minutes, still no luck. >>>>> >>>>> Oh well.. I guess I will go look at alternatives. I had such high >>>>> hopes for this tool. Thanks so much everyone for all your help in >>>>> trying to get things stable, but for whatever reason, there is a >>>>> random loss of sync among the servers and obviously this is not >>>>> acceptable. >>>>> >>>>> regards >>>>> ~J >>>> >> >> All the replicas are happy again. I found these again: >> >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> >> What I also found to be interesting is that I have not deleted any >> masters at all, so this was quite perplexing where the orphaned >> entries came from. However I did find 3 of the replicas did not show >> complete RUV lists... While most of the replicas had a list of all 16 >> servers, a couple of them listed only 4 or 5. (using >> ipa-replica-manage list-ruv) > I don't know about the orphaned entries. Did you get entries below > deleted parents ? > > AFAIK all replicas are master and so have an entry {replica } in > the RUV. We should expect all servers having the same number of > RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated so > that they did not received updates from those with 16 RUVelements. > would you copy/paste an example of RUV with 16 and with 4-5 ? Now, the steps to clear this were: Removed the "unable to decode" with the direct ldapmodify's. This worked across all replicas, which was nice and did not have to be repeated in each one. In other words, entered on a single server, and it was removed on all. re-initialized --from=good server on the ones with the short list. Waited 5 minutes to let everything settle, then started running tests of adds/deletes which seemed to be just fine. Here are 2 of the DCs ------------------------------------- Node dc1-ipa1 ------------------------------------- dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa4.example.com 389 4 ------------------------------------- Node dc1-ipa2 ------------------------------------- dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 ------------------------------------- Node dc1-ipa3 ------------------------------------- dc3-ipa1.example.com 389 14 dc3-ipa2.example.com 389 13 dc3-ipa3.example.com 389 12 dc3-ipa4.example.com 389 11 dc2-ipa1.example.com 389 7 dc2-ipa2.example.com 389 6 dc2-ipa3.example.com 389 5 dc2-ipa4.example.com 389 3 dc4-ipa1.example.com 389 18 dc4-ipa2.example.com 389 19 dc4-ipa3.example.com 389 20 dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa2.example.com 389 9 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 dc5-ipa1.example.com 389 26 dc5-ipa2.example.com 389 15 dc5-ipa3.example.com 389 17 ------------------------------------- Node dc1-ipa4 ------------------------------------- dc3-ipa1.example.com 389 14 dc3-ipa2.example.com 389 13 dc3-ipa3.example.com 389 12 dc3-ipa4.example.com 389 11 dc2-ipa1.example.com 389 7 dc2-ipa2.example.com 389 6 dc2-ipa3.example.com 389 5 dc2-ipa4.example.com 389 3 dc4-ipa1.example.com 389 18 dc4-ipa2.example.com 389 19 dc4-ipa3.example.com 389 20 dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa2.example.com 389 9 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 dc5-ipa1.example.com 389 26 dc5-ipa2.example.com 389 15 dc5-ipa3.example.com 389 17 ------------------------------------- Node dc2-ipa1 ------------------------------------- dc3-ipa1.example.com 389 14 dc3-ipa2.example.com 389 13 dc3-ipa3.example.com 389 12 dc3-ipa4.example.com 389 11 dc2-ipa1.example.com 389 7 dc2-ipa2.example.com 389 6 dc2-ipa3.example.com 389 5 dc2-ipa4.example.com 389 3 dc4-ipa1.example.com 389 18 dc4-ipa2.example.com 389 19 dc4-ipa3.example.com 389 20 dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa2.example.com 389 9 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 dc5-ipa1.example.com 389 26 dc5-ipa2.example.com 389 15 dc5-ipa3.example.com 389 17 ------------------------------------- Node dc2-ipa2 ------------------------------------- dc3-ipa1.example.com 389 14 dc3-ipa2.example.com 389 13 dc3-ipa3.example.com 389 12 dc3-ipa4.example.com 389 11 dc2-ipa1.example.com 389 7 dc2-ipa2.example.com 389 6 dc2-ipa3.example.com 389 5 dc2-ipa4.example.com 389 3 dc4-ipa1.example.com 389 18 dc4-ipa2.example.com 389 19 dc4-ipa3.example.com 389 20 dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa2.example.com 389 9 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 dc5-ipa1.example.com 389 26 dc5-ipa2.example.com 389 15 dc5-ipa3.example.com 389 17 ------------------------------------- Node dc2-ipa3 ------------------------------------- dc3-ipa1.example.com 389 14 dc3-ipa2.example.com 389 13 dc3-ipa3.example.com 389 12 dc3-ipa4.example.com 389 11 dc2-ipa1.example.com 389 7 dc2-ipa2.example.com 389 6 dc2-ipa3.example.com 389 5 dc2-ipa4.example.com 389 3 dc4-ipa1.example.com 389 18 dc4-ipa2.example.com 389 19 dc4-ipa3.example.com 389 20 dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa2.example.com 389 9 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 dc5-ipa1.example.com 389 26 dc5-ipa2.example.com 389 15 dc5-ipa3.example.com 389 17 ------------------------------------- Node dc2-ipa4 ------------------------------------- dc3-ipa1.example.com 389 14 dc3-ipa2.example.com 389 13 dc3-ipa3.example.com 389 12 dc3-ipa4.example.com 389 11 dc2-ipa1.example.com 389 7 dc2-ipa2.example.com 389 6 dc2-ipa3.example.com 389 5 dc2-ipa4.example.com 389 3 dc4-ipa1.example.com 389 18 dc4-ipa2.example.com 389 19 dc4-ipa3.example.com 389 20 dc4-ipa4.example.com 389 21 dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa2.example.com 389 9 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 dc5-ipa1.example.com 389 26 dc5-ipa2.example.com 389 15 dc5-ipa3.example.com 389 17 Happy Wednesday ~Janelle -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed May 20 13:59:54 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 20 May 2015 15:59:54 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555C8B41.5010502@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C3DCE.8060102@redhat.com> <555C8B41.5010502@gmail.com> Message-ID: <555C935A.6030304@redhat.com> On 05/20/2015 03:25 PM, Janelle wrote: > On 5/20/15 12:54 AM, Ludwig Krispenz wrote: >> >> On 05/20/2015 02:57 AM, Janelle wrote: >>> On 5/19/15 12:04 AM, thierry bordaz wrote: >>>> On 05/19/2015 03:42 AM, Janelle wrote: >>>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>>> Once again, replication/sync has been lost. I really wish the >>>>>> product was more stable, it is so much potential and yet. >>>>>> >>>>>> Servers running for 6 days no issues. No new accounts or changes >>>>>> (maybe a few users changing passwords) and again, 5 out of 16 >>>>>> servers are no longer in sync. >>>>>> >>>>>> I can test it easily by adding an account and then waiting a few >>>>>> minutes, then run "ipa user-show --all username" on all the >>>>>> servers, and only a few of them have the account. I have now >>>>>> waited 15 minutes, still no luck. >>>>>> >>>>>> Oh well.. I guess I will go look at alternatives. I had such high >>>>>> hopes for this tool. Thanks so much everyone for all your help in >>>>>> trying to get things stable, but for whatever reason, there is a >>>>>> random loss of sync among the servers and obviously this is not >>>>>> acceptable. >>>>>> >>>>>> regards >>>>>> ~J >>>>> >>> >>> All the replicas are happy again. I found these again: >>> >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> >>> What I also found to be interesting is that I have not deleted any >>> masters at all, so this was quite perplexing where the orphaned >>> entries came from. However I did find 3 of the replicas did not >>> show complete RUV lists... While most of the replicas had a list of >>> all 16 servers, a couple of them listed only 4 or 5. (using >>> ipa-replica-manage list-ruv) >> so this happens "out of the blue" ? Did it happen at the same time, >> do you know when it started ? The maxcsns in the ruv are quite old: >> r16: apr,21, r23: may,14 r24: may,9 could it be that there was no >> change applied to these masters for that time ? >>> > Indeed yes, that is a correct statement. It seems to be incredibly > random. > Ok, I give up - how are you finding the date in the strings? And > really, is May 14th that old? 55356472000300100000 is a CSN (ChangeSequenceNumber), it is built of hextimestamp: 55356472 sequence number: 0003 (numbering of csns generated within the sceond of the time stamp replica id: 0010 (==16) replica, where the change was received subsequence number: 0000 used internally if a mod consists of several sub-mods May. 14 is not old, but would mean that there was no change on that replica for a couple of days > > What is odd about the Apr 21st one, is that if you see my previous > emails, I had cleaned up all of this before, so for that to > "re-appear" is indeed a mystery. > > As of this morning, things remain clean. What will be funny, now that > I had extended logging enabled, they know we are on to them, so the > servers won't fail again. :-) > > ~J > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.boyce at nasa.gov Wed May 20 14:01:55 2015 From: george.boyce at nasa.gov (Boyce, George Robert. (GSFC-762.0)[NICS]) Date: Wed, 20 May 2015 14:01:55 +0000 Subject: [Freeipa-users] confused by ldapsearch results In-Reply-To: <555B9C54.6050302@redhat.com> References: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> <555B9C54.6050302@redhat.com> Message-ID: <642326D3671873428E03A5AB2A1ACF0811B89A1D@NDMSMBX301.ndc.nasa.gov> << This worked for me: $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm "(|(uid=admin)(name=admin))" dn SASL/GSSAPI authentication started SASL username: admin at EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com Note that cn is Common Name which is set to the user's full name, in this case likely "George Boyce". So that will never match gboyce. Rob >> Rob, Thanks for your example, it had me test my ldap bind which narrows the problem and gives me a workaround. I used cn=gboyce to pull my group record, so I expected my test to return two records for my account and my group. And it does when I authenticate as admin as in your test. So the problem is isolated to when I use a dedicated search account. I missed this note on setting up system accounts: << Note: IPA 4.0 is going to change the default stance on data from nearly everything is readable to nothing is readable, by default. You will eventually need to add some Access Control Instructions (ACI's) to grant read access to the parts of the LDAP tree you will need. >> Looks like I need to do just that. :-) Still the behavior of returning nothing by adding an extra false term, or returning one entry when each of the terms each returns a unique entry, seems wrong. It does return two entries when both are in the same subtree. ### ### everything ok when using admin... two records, one from users, one from groups ### # ldapsearch -Y GSSAPI -b "dc=..." "(|(uid=admin)(cn=gboyce))" dn SASL/GSSAPI authentication started SASL username: admin at ... SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(uid=admin)(cn=gboyce)) # requesting: dn # # admin, users, accounts, ... dn: uid=admin,cn=users,cn=accounts,dc=... # gboyce, groups, accounts, ... dn: cn=gboyce,cn=groups,cn=accounts,dc=... # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 ########################################################################################## ### ### system account (without ACLs) returns simple queries, but not correct results for compound queries in different subtrees ### ### ### different subtrees fails... ### # ldapsearch -x -D "uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=..." -w "..." -b "dc=..." "(|(uid=admin)(cn=gboyce))" dn # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(uid=admin)(cn=gboyce)) # requesting: dn # # admin, users, accounts, ... dn: uid=admin,cn=users,cn=accounts,dc=... # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ### ### same subtree works... ### # l "(|(cn=admins)(cn=gboyce))" dn # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(cn=admins)(cn=gboyce)) # requesting: dn # # admins, groups, accounts, ... dn: cn=admins,cn=groups,cn=accounts,dc=... # gboyce, groups, accounts, ... dn: cn=gboyce,cn=groups,cn=accounts,dc=... # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 ### ### valid filter from above with extra false term... ### # l "(|(cn=admins)(cn=gboyce)(name=foobar))" dn # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(cn=admins)(cn=gboyce)(name=foobar)) # requesting: dn # # search result search: 2 result: 0 Success # numResponses: 1 From tbordaz at redhat.com Wed May 20 14:17:18 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 20 May 2015 16:17:18 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555C9049.70607@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> Message-ID: <555C976E.30202@redhat.com> On 05/20/2015 03:46 PM, Janelle wrote: > On 5/20/15 6:01 AM, thierry bordaz wrote: >> On 05/20/2015 02:57 AM, Janelle wrote: >>> On 5/19/15 12:04 AM, thierry bordaz wrote: >>>> On 05/19/2015 03:42 AM, Janelle wrote: >>>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>>> Once again, replication/sync has been lost. I really wish the >>>>>> product was more stable, it is so much potential and yet. >>>>>> >>>>>> Servers running for 6 days no issues. No new accounts or changes >>>>>> (maybe a few users changing passwords) and again, 5 out of 16 >>>>>> servers are no longer in sync. >>>>>> >>>>>> I can test it easily by adding an account and then waiting a few >>>>>> minutes, then run "ipa user-show --all username" on all the >>>>>> servers, and only a few of them have the account. I have now >>>>>> waited 15 minutes, still no luck. >>>>>> >>>>>> Oh well.. I guess I will go look at alternatives. I had such high >>>>>> hopes for this tool. Thanks so much everyone for all your help in >>>>>> trying to get things stable, but for whatever reason, there is a >>>>>> random loss of sync among the servers and obviously this is not >>>>>> acceptable. >>>>>> >>>>>> regards >>>>>> ~J >>>>> >>> >>> All the replicas are happy again. I found these again: >>> >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> >>> What I also found to be interesting is that I have not deleted any >>> masters at all, so this was quite perplexing where the orphaned >>> entries came from. However I did find 3 of the replicas did not >>> show complete RUV lists... While most of the replicas had a list of >>> all 16 servers, a couple of them listed only 4 or 5. (using >>> ipa-replica-manage list-ruv) >> I don't know about the orphaned entries. Did you get entries below >> deleted parents ? >> >> AFAIK all replicas are master and so have an entry {replica } in >> the RUV. We should expect all servers having the same number of >> RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated so >> that they did not received updates from those with 16 RUVelements. >> would you copy/paste an example of RUV with 16 and with 4-5 ? > > Now, the steps to clear this were: > > Removed the "unable to decode" with the direct ldapmodify's. This > worked across all replicas, which was nice and did not have to be > repeated in each one. In other words, entered on a single server, and > it was removed on all. Hello, Did you do direct ldapmodify onto the RUV entry (nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,SUFFIX) , clean RUV ? dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an update on dc3-ipa1, is it replicated to dc1-ipa[12] ? Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389. You may see some messages like 'attrlist_replace' in some error logs. 25 seems to be the new RID. thanks thierry > > re-initialized --from=good server on the ones with the short list. > > Waited 5 minutes to let everything settle, then started running tests > of adds/deletes which seemed to be just fine. > > Here are 2 of the DCs > > ------------------------------------- > Node dc1-ipa1 > ------------------------------------- > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa4.example.com 389 4 > ------------------------------------- > Node dc1-ipa2 > ------------------------------------- > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > ------------------------------------- > Node dc1-ipa3 > ------------------------------------- > dc3-ipa1.example.com 389 14 > dc3-ipa2.example.com 389 13 > dc3-ipa3.example.com 389 12 > dc3-ipa4.example.com 389 11 > dc2-ipa1.example.com 389 7 > dc2-ipa2.example.com 389 6 > dc2-ipa3.example.com 389 5 > dc2-ipa4.example.com 389 3 > dc4-ipa1.example.com 389 18 > dc4-ipa2.example.com 389 19 > dc4-ipa3.example.com 389 20 > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa2.example.com 389 9 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > dc5-ipa1.example.com 389 26 > dc5-ipa2.example.com 389 15 > dc5-ipa3.example.com 389 17 > ------------------------------------- > Node dc1-ipa4 > ------------------------------------- > dc3-ipa1.example.com 389 14 > dc3-ipa2.example.com 389 13 > dc3-ipa3.example.com 389 12 > dc3-ipa4.example.com 389 11 > dc2-ipa1.example.com 389 7 > dc2-ipa2.example.com 389 6 > dc2-ipa3.example.com 389 5 > dc2-ipa4.example.com 389 3 > dc4-ipa1.example.com 389 18 > dc4-ipa2.example.com 389 19 > dc4-ipa3.example.com 389 20 > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa2.example.com 389 9 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > dc5-ipa1.example.com 389 26 > dc5-ipa2.example.com 389 15 > dc5-ipa3.example.com 389 17 > ------------------------------------- > Node dc2-ipa1 > ------------------------------------- > dc3-ipa1.example.com 389 14 > dc3-ipa2.example.com 389 13 > dc3-ipa3.example.com 389 12 > dc3-ipa4.example.com 389 11 > dc2-ipa1.example.com 389 7 > dc2-ipa2.example.com 389 6 > dc2-ipa3.example.com 389 5 > dc2-ipa4.example.com 389 3 > dc4-ipa1.example.com 389 18 > dc4-ipa2.example.com 389 19 > dc4-ipa3.example.com 389 20 > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa2.example.com 389 9 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > dc5-ipa1.example.com 389 26 > dc5-ipa2.example.com 389 15 > dc5-ipa3.example.com 389 17 > ------------------------------------- > Node dc2-ipa2 > ------------------------------------- > dc3-ipa1.example.com 389 14 > dc3-ipa2.example.com 389 13 > dc3-ipa3.example.com 389 12 > dc3-ipa4.example.com 389 11 > dc2-ipa1.example.com 389 7 > dc2-ipa2.example.com 389 6 > dc2-ipa3.example.com 389 5 > dc2-ipa4.example.com 389 3 > dc4-ipa1.example.com 389 18 > dc4-ipa2.example.com 389 19 > dc4-ipa3.example.com 389 20 > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa2.example.com 389 9 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > dc5-ipa1.example.com 389 26 > dc5-ipa2.example.com 389 15 > dc5-ipa3.example.com 389 17 > ------------------------------------- > Node dc2-ipa3 > ------------------------------------- > dc3-ipa1.example.com 389 14 > dc3-ipa2.example.com 389 13 > dc3-ipa3.example.com 389 12 > dc3-ipa4.example.com 389 11 > dc2-ipa1.example.com 389 7 > dc2-ipa2.example.com 389 6 > dc2-ipa3.example.com 389 5 > dc2-ipa4.example.com 389 3 > dc4-ipa1.example.com 389 18 > dc4-ipa2.example.com 389 19 > dc4-ipa3.example.com 389 20 > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa2.example.com 389 9 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > dc5-ipa1.example.com 389 26 > dc5-ipa2.example.com 389 15 > dc5-ipa3.example.com 389 17 > ------------------------------------- > Node dc2-ipa4 > ------------------------------------- > dc3-ipa1.example.com 389 14 > dc3-ipa2.example.com 389 13 > dc3-ipa3.example.com 389 12 > dc3-ipa4.example.com 389 11 > dc2-ipa1.example.com 389 7 > dc2-ipa2.example.com 389 6 > dc2-ipa3.example.com 389 5 > dc2-ipa4.example.com 389 3 > dc4-ipa1.example.com 389 18 > dc4-ipa2.example.com 389 19 > dc4-ipa3.example.com 389 20 > dc4-ipa4.example.com 389 21 > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa2.example.com 389 9 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > dc5-ipa1.example.com 389 26 > dc5-ipa2.example.com 389 15 > dc5-ipa3.example.com 389 17 > > > Happy Wednesday > ~Janelle -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Wed May 20 14:53:52 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Wed, 20 May 2015 10:53:52 -0400 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555C976E.30202@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> Message-ID: <555CA000.4030208@redhat.com> On 05/20/2015 10:17 AM, thierry bordaz wrote: > On 05/20/2015 03:46 PM, Janelle wrote: >> On 5/20/15 6:01 AM, thierry bordaz wrote: >>> On 05/20/2015 02:57 AM, Janelle wrote: >>>> On 5/19/15 12:04 AM, thierry bordaz wrote: >>>>> On 05/19/2015 03:42 AM, Janelle wrote: >>>>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>>>> Once again, replication/sync has been lost. I really wish the >>>>>>> product was more stable, it is so much potential and yet. >>>>>>> >>>>>>> Servers running for 6 days no issues. No new accounts or changes >>>>>>> (maybe a few users changing passwords) and again, 5 out of 16 >>>>>>> servers are no longer in sync. >>>>>>> >>>>>>> I can test it easily by adding an account and then waiting a few >>>>>>> minutes, then run "ipa user-show --all username" on all the >>>>>>> servers, and only a few of them have the account. I have now >>>>>>> waited 15 minutes, still no luck. >>>>>>> >>>>>>> Oh well.. I guess I will go look at alternatives. I had such >>>>>>> high hopes for this tool. Thanks so much everyone for all your >>>>>>> help in trying to get things stable, but for whatever reason, >>>>>>> there is a random loss of sync among the servers and obviously >>>>>>> this is not acceptable. >>>>>>> >>>>>>> regards >>>>>>> ~J >>>>>> >>>> >>>> All the replicas are happy again. I found these again: >>>> >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 23} 5553e3a3000000170000 >>>> 55543240000300170000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> >>>> What I also found to be interesting is that I have not deleted any >>>> masters at all, so this was quite perplexing where the orphaned >>>> entries came from. However I did find 3 of the replicas did not >>>> show complete RUV lists... While most of the replicas had a list of >>>> all 16 servers, a couple of them listed only 4 or 5. (using >>>> ipa-replica-manage list-ruv) >>> I don't know about the orphaned entries. Did you get entries below >>> deleted parents ? >>> >>> AFAIK all replicas are master and so have an entry {replica } >>> in the RUV. We should expect all servers having the same number of >>> RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated so >>> that they did not received updates from those with 16 RUVelements. >>> would you copy/paste an example of RUV with 16 and with 4-5 ? >> >> Now, the steps to clear this were: >> >> Removed the "unable to decode" with the direct ldapmodify's. This >> worked across all replicas, which was nice and did not have to be >> repeated in each one. In other words, entered on a single server, and >> it was removed on all. > Hello, > > Did you do direct ldapmodify onto the RUV entry > (nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,SUFFIX) , clean RUV ? Thierry, Janelle just manually added a cleanallruv task (that I had recommended the other week). Mark > > dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an > update on dc3-ipa1, is it replicated to dc1-ipa[12] ? > > Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389. > You may see some messages like 'attrlist_replace' in some error logs. > 25 seems to be the new RID. > > thanks > thierry > >> >> re-initialized --from=good server on the ones with the short list. >> >> Waited 5 minutes to let everything settle, then started running tests >> of adds/deletes which seemed to be just fine. >> >> Here are 2 of the DCs >> >> ------------------------------------- >> Node dc1-ipa1 >> ------------------------------------- >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa4.example.com 389 4 >> ------------------------------------- >> Node dc1-ipa2 >> ------------------------------------- >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa2.example.com 389 25 >> dc1-ipa3.example.com 389 8 >> dc1-ipa4.example.com 389 4 >> ------------------------------------- >> Node dc1-ipa3 >> ------------------------------------- >> dc3-ipa1.example.com 389 14 >> dc3-ipa2.example.com 389 13 >> dc3-ipa3.example.com 389 12 >> dc3-ipa4.example.com 389 11 >> dc2-ipa1.example.com 389 7 >> dc2-ipa2.example.com 389 6 >> dc2-ipa3.example.com 389 5 >> dc2-ipa4.example.com 389 3 >> dc4-ipa1.example.com 389 18 >> dc4-ipa2.example.com 389 19 >> dc4-ipa3.example.com 389 20 >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa2.example.com 389 25 >> dc1-ipa2.example.com 389 9 >> dc1-ipa3.example.com 389 8 >> dc1-ipa4.example.com 389 4 >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> dc5-ipa1.example.com 389 26 >> dc5-ipa2.example.com 389 15 >> dc5-ipa3.example.com 389 17 >> ------------------------------------- >> Node dc1-ipa4 >> ------------------------------------- >> dc3-ipa1.example.com 389 14 >> dc3-ipa2.example.com 389 13 >> dc3-ipa3.example.com 389 12 >> dc3-ipa4.example.com 389 11 >> dc2-ipa1.example.com 389 7 >> dc2-ipa2.example.com 389 6 >> dc2-ipa3.example.com 389 5 >> dc2-ipa4.example.com 389 3 >> dc4-ipa1.example.com 389 18 >> dc4-ipa2.example.com 389 19 >> dc4-ipa3.example.com 389 20 >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa2.example.com 389 25 >> dc1-ipa2.example.com 389 9 >> dc1-ipa3.example.com 389 8 >> dc1-ipa4.example.com 389 4 >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> dc5-ipa1.example.com 389 26 >> dc5-ipa2.example.com 389 15 >> dc5-ipa3.example.com 389 17 >> ------------------------------------- >> Node dc2-ipa1 >> ------------------------------------- >> dc3-ipa1.example.com 389 14 >> dc3-ipa2.example.com 389 13 >> dc3-ipa3.example.com 389 12 >> dc3-ipa4.example.com 389 11 >> dc2-ipa1.example.com 389 7 >> dc2-ipa2.example.com 389 6 >> dc2-ipa3.example.com 389 5 >> dc2-ipa4.example.com 389 3 >> dc4-ipa1.example.com 389 18 >> dc4-ipa2.example.com 389 19 >> dc4-ipa3.example.com 389 20 >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa2.example.com 389 25 >> dc1-ipa2.example.com 389 9 >> dc1-ipa3.example.com 389 8 >> dc1-ipa4.example.com 389 4 >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> dc5-ipa1.example.com 389 26 >> dc5-ipa2.example.com 389 15 >> dc5-ipa3.example.com 389 17 >> ------------------------------------- >> Node dc2-ipa2 >> ------------------------------------- >> dc3-ipa1.example.com 389 14 >> dc3-ipa2.example.com 389 13 >> dc3-ipa3.example.com 389 12 >> dc3-ipa4.example.com 389 11 >> dc2-ipa1.example.com 389 7 >> dc2-ipa2.example.com 389 6 >> dc2-ipa3.example.com 389 5 >> dc2-ipa4.example.com 389 3 >> dc4-ipa1.example.com 389 18 >> dc4-ipa2.example.com 389 19 >> dc4-ipa3.example.com 389 20 >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa2.example.com 389 25 >> dc1-ipa2.example.com 389 9 >> dc1-ipa3.example.com 389 8 >> dc1-ipa4.example.com 389 4 >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> dc5-ipa1.example.com 389 26 >> dc5-ipa2.example.com 389 15 >> dc5-ipa3.example.com 389 17 >> ------------------------------------- >> Node dc2-ipa3 >> ------------------------------------- >> dc3-ipa1.example.com 389 14 >> dc3-ipa2.example.com 389 13 >> dc3-ipa3.example.com 389 12 >> dc3-ipa4.example.com 389 11 >> dc2-ipa1.example.com 389 7 >> dc2-ipa2.example.com 389 6 >> dc2-ipa3.example.com 389 5 >> dc2-ipa4.example.com 389 3 >> dc4-ipa1.example.com 389 18 >> dc4-ipa2.example.com 389 19 >> dc4-ipa3.example.com 389 20 >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa2.example.com 389 25 >> dc1-ipa2.example.com 389 9 >> dc1-ipa3.example.com 389 8 >> dc1-ipa4.example.com 389 4 >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> dc5-ipa1.example.com 389 26 >> dc5-ipa2.example.com 389 15 >> dc5-ipa3.example.com 389 17 >> ------------------------------------- >> Node dc2-ipa4 >> ------------------------------------- >> dc3-ipa1.example.com 389 14 >> dc3-ipa2.example.com 389 13 >> dc3-ipa3.example.com 389 12 >> dc3-ipa4.example.com 389 11 >> dc2-ipa1.example.com 389 7 >> dc2-ipa2.example.com 389 6 >> dc2-ipa3.example.com 389 5 >> dc2-ipa4.example.com 389 3 >> dc4-ipa1.example.com 389 18 >> dc4-ipa2.example.com 389 19 >> dc4-ipa3.example.com 389 20 >> dc4-ipa4.example.com 389 21 >> dc1-ipa1.example.com 389 10 >> dc1-ipa2.example.com 389 25 >> dc1-ipa2.example.com 389 9 >> dc1-ipa3.example.com 389 8 >> dc1-ipa4.example.com 389 4 >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> dc5-ipa1.example.com 389 26 >> dc5-ipa2.example.com 389 15 >> dc5-ipa3.example.com 389 17 >> >> >> Happy Wednesday >> ~Janelle > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Wed May 20 15:16:48 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 20 May 2015 17:16:48 +0200 Subject: [Freeipa-users] Running pki commands on fresh IPA server -- authentication Message-ID: <20150520151648.GC3605@redhat.com> Hello, TL;DR: how should I authenticate for pki command line commands on stock IPA installation? Longer context: I try to setup new IPA server (1) with --external-ca and I'd like to sign the CSR which gets generated on IPA 1 using CA at my other IPA server (2). The CSR as produced by IPA 1 is for Subject: O=SUB.EXAMPLE.TEST, CN=Certificate Authority Requested Extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Certificate Sign, CRL Sign Jan Ch. hints that I cannot use ipa cert-request because the certificate request does not have hostname CN and besides, IPA and ipa command only support server certificates and here I am attempting to create CA certificate. Hence my understanding is I need to use Dogtag directly and I'd like to use the pki commands. I believe I need start by getting the XML template -- I've used pki cert-request-profile-show caInstallCACert --output template Then I took the Base64 content of the /root/ipa.csr from IPA 2, put it to child element of /CertEnrollmentRequest/Input[@id="11"]/Attribute[@name="cert_request"] and attempted to run # pki cert-request-submit template UnauthorizedException: AuthCredentials.set() Reading man pki(1) suggests I should authenticate using certificate nickname, and reading other documentation suggests that using ca-agent's certificate could be a good option. So I do # openssl pkcs12 -out /root/ca-agent.pem < /root/ca-agent.p12 Enter Import Password: MAC verified OK Enter PEM pass phrase: # pki -n ca-agent client-cert-import --cert /root/ca-agent.pem ------------------------------- Imported certificate "ca-agent" ------------------------------- # pki -n ca-agent cert-request-submit template WARNING: UNTRUSTED ISSUER encountered on 'CN=ipa.example.test,O=EXAMPLE.TEST' indicates a non-trusted CA cert 'CN=Certificate Authority,O=EXAMPLE.TEST' Import CA certificate (Y/n)? n ClientResponseFailure: Error status 401 Unauthorized returned Even if I allow that CA certificate to be imported, the results is the same: Import CA certificate (Y/n)? CA server URI [http://mgmt9.rhq.lab.eng.bos.redhat.com:8080/ca]: ClientResponseFailure: Error status 401 Unauthorized returned What am I doing wrong? This is with ipa-server-4.1.0-18.el7.x86_64 and pki-server-10.1.2-7.el7.noarch. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From brian at votesmart.org Wed May 20 15:38:18 2015 From: brian at votesmart.org (Brian Koontz) Date: Wed, 20 May 2015 09:38:18 -0600 Subject: [Freeipa-users] Updates refused when trying to do dynamic DNS updates with TSIG Message-ID: Running FreeIPA 4.1.4, Fedora 21. Trying to get dynamic DNS updates on clients to work following these instructions: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG (Using GSS-TSIG isn't an option because I have no way of authenticating every time a client IP changes.) I've reread the instructions several times, but each time I get "update failed: REFUSED". Logs aren't showing anything useful other than the query is being refused. Is this document missing an important step? (I saw no need to create a DNS/ service as there should be no krb5 authentication involved here...) --Brian -- Brian Koontz IT Support Project Vote Smart -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.boyce at nasa.gov Wed May 20 17:50:15 2015 From: george.boyce at nasa.gov (Boyce, George Robert. (GSFC-762.0)[NICS]) Date: Wed, 20 May 2015 17:50:15 +0000 Subject: [Freeipa-users] Proper configuration of service accounts Message-ID: <642326D3671873428E03A5AB2A1ACF0811B89E4A@NDMSMBX301.ndc.nasa.gov> << If you want to add special ACIs using the new/updated permission API (ipa permission-add), I would suggest following procedure: 1) Add the new system account in cn=sysaccounts,cn=etc,dc=rhel71 2) Add the new permissions you want to add, make them a member of a (new) privilege. 3) Create a new role, make the new/updated privileges members of that role 4) Use ldapmodify to make the system account DN member of that role (you just add a new member attribute value) 5) Profit - you should be now able to control permissions to your system account with FreeIPA CLI/UI >> On step 4 to add the sysaccounts user to the role, I get an error: # cat sysaccount-LDAPsearch-add-role-2.ldif dn: cn=A and A,cn=roles,cn=accounts,dc=... changetype: modify add: member member: uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=... # ldapmodify -Y GSSAPI -f sysaccount-LDAPsearch-add-role-2.ldif SASL/GSSAPI authentication started SASL username: admin at ... SASL SSF: 56 SASL data security layer installed. modifying entry "cn=A and A,cn=roles,cn=accounts,dc=..." ldap_modify: Object class violation (65) Same thing if I use Directory Manager. I was able to add a normal user to the role, using both the GUI and ldapmodify. # ipa --version VERSION: 4.1.0, API_VERSION: 2.112 # cat /etc/centos-release CentOS Linux release 7.1.1503 (Core) George Boyce, SAIC/NICS GCC Systems Support NASA GSFC Code 762 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 20 17:58:23 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 May 2015 13:58:23 -0400 Subject: [Freeipa-users] Proper configuration of service accounts In-Reply-To: <642326D3671873428E03A5AB2A1ACF0811B89E4A@NDMSMBX301.ndc.nasa.gov> References: <642326D3671873428E03A5AB2A1ACF0811B89E4A@NDMSMBX301.ndc.nasa.gov> Message-ID: <555CCB3F.8070303@redhat.com> Boyce, George Robert. (GSFC-762.0)[NICS] wrote: > << > > If you want to add special ACIs using the new/updated permission API (ipa > > permission-add), I would suggest following procedure: > > 1) Add the new system account in cn=sysaccounts,cn=etc,dc=rhel71 > > 2) Add the new permissions you want to add, make them a member of a (new) > > privilege. > > 3) Create a new role, make the new/updated privileges members of that role > > 4) Use ldapmodify to make the system account DN member of that role (you > just > > add a new member attribute value) > > 5) Profit - you should be now able to control permissions to your system > > account with FreeIPA CLI/UI > > >> > > On step 4 to add the sysaccounts user to the role, I get an error: > > # cat sysaccount-LDAPsearch-add-role-2.ldif > > dn: cn=A and A,cn=roles,cn=accounts,dc=? > > changetype: modify > > add: member > > member: uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=? > > # ldapmodify -Y GSSAPI -f sysaccount-LDAPsearch-add-role-2.ldif > > SASL/GSSAPI authentication started > > SASL username: admin at ... > > SASL SSF: 56 > > SASL data security layer installed. > > modifying entry "cn=A and A,cn=roles,cn=accounts,dc=?" > > ldap_modify: Object class violation (65) > > Same thing if I use Directory Manager. I was able to add a normal user > to the role, using both the GUI and ldapmodify. Try adding the inetUser objectclass to your system account. You're probably lacking memberOf. > # ipa --version > > VERSION: 4.1.0, API_VERSION: 2.112 > > # cat /etc/centos-release > > CentOS Linux release 7.1.1503 (Core) > > George Boyce, SAIC/NICS > GCC Systems Support > NASA GSFC Code 762 I was in Code 500 many moons ago, Center Network Environment (CNE). rob From george.boyce at nasa.gov Wed May 20 18:20:55 2015 From: george.boyce at nasa.gov (Boyce, George Robert. (GSFC-762.0)[NICS]) Date: Wed, 20 May 2015 18:20:55 +0000 Subject: [Freeipa-users] Proper configuration of service accounts Message-ID: <642326D3671873428E03A5AB2A1ACF0811B89E97@NDMSMBX301.ndc.nasa.gov> I forgot to describe the system account that I created. I followed the procedure at https://www.freeipa.org/page/HowTo/LDAP#System_Accounts # LDAPsearch, sysaccounts, etc, ... dn: uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=... objectClass: account objectClass: simplesecurityobject objectClass: top uid: LDAPsearch What do I need to change to be able to add this account as a member to a given role? To avoid this: modifying entry "cn=A and A,cn=roles,cn=accounts,dc=..." ldap_modify: Object class violation (65) George Boyce, SAIC/NICS GCC Systems Support NASA GSFC Code 762 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 20 19:30:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 May 2015 15:30:36 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> <555A28B3.8080503@redhat.com> <555B55DE.8070007@redhat.com> <555C8D03.3050709@redhat.com> Message-ID: <555CE0DC.1030509@redhat.com> Sina Owolabi wrote: > Hi Rob > > This is the only CA master. The one I cloned it from was > decommissioned, reinstalled and then made to be a replica of this server. > > Looks like I'm really stuck. How do I export the data out so I can > reinstall from scratch, if possible? There are a lot of rules and > configuration data I'd really like to keep. So in this case you have no master managing the renewal. Take a look at http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0 starting at the step "Reconfigure a CA as the new master" Since at least one certificate has expired you'll need to go back in time to get this working. Be sure to restart IPA after going back to ensure that the CA is up. You'll eventually want to do the CRL changes as well. rob > > > On Wed, May 20, 2015, 2:32 PM Rob Crittenden > wrote: > > Sina Owolabi wrote: > > Another key difference I noticed is that the problematic certs have > > CA:IPA in them, while the working certs have CA: > > dogtag-ipa-retrieve-agent-submit. > > Ok, the full output is really helpful. > > First an explanation of CA subsystem renewal. > > CA clones are just that, exact clones of each other, which means they > use the same subsystem certificates for OCSP, audit, etc. This also > means that at renewal time they need to be renewed on only one master > and then somehow shared with the ohter clones. > > The initially-installed CA is designated as the renewal master by > default. It configures certmonger to renew the CA subsytem certificates > and put the new public cert into a shared area in IPA that will be > replicated to the other masters. > > The non-renewal masters are configured with a special CA, > dogtag-ipa-retrieve-agent-submit, that looks in this shared area for an > updated certificate and when available, it installs it. > > So the issue is that it isn't seeing this updated certificate, hence > CA_WORKING. > > The CA_UNREACHABLE are due to the fact that the IPA RA agent certificate > that IPA uses to talk to the CA expired on 04/29. > > So the steps you need to take are: > > 1. Check your other CA masters and see if they have been renewed > properly (getcert list will tell you, look for expiration in 2017). > 2. If they have, see if the data was pushed to LDAP > > $ kinit admin > $ ldapsearch -Y GSSAPI -b cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com > > See if there are certificate entries there. Check on multiple masters to > see if there is a replication issue. > > If the certs are there you can try restarting certmonger to kickstart > the request. > > rob > From sanju.a at tcs.com Thu May 21 04:08:28 2015 From: sanju.a at tcs.com (Sanju A) Date: Thu, 21 May 2015 09:38:28 +0530 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <555C8D47.7030306@redhat.com> References: <555C8D47.7030306@redhat.com> Message-ID: Dear Rob, Please find the result of getcert list. Request ID '20140430124456': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.tcs-mobility.com,O=EXAMPLE.COM expires: 2016-04-30 12:44:55 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Regards Sanju Abraham From: Rob Crittenden To: Sanju A , freeipa-users at redhat.com Date: 20-05-2015 19:04 Subject: Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Sanju A wrote: > Hi, > > I am getting the following error while removing a host. > > --------------------------------------- > Certificate operation cannot be completed: Unable to communicate with > CMS (Not Found) > --------------------------------------- This usually means that the CA is not serving requestss. It may be up and running but that doesn't mean the webapp is working. This is often due to expired CA subsystem certificates. Run getcert list to check. rob =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Frolushkin at megafon.ru Thu May 21 04:58:32 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Thu, 21 May 2015 04:58:32 +0000 Subject: [Freeipa-users] ruv problem Message-ID: <2e196e1717564d8691c4dd7d090d9194@sib-ums03.Megafon.ru> Hello again. Is it now clear how to deal with problem ipa-replica-manage list-ruv showing unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 ? I have this on all of my 17 servers, including a new replica created recently, and ipa-replica-manage clean-ruv 16 says unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 Replica ID 16 not found" WBR, Alexander Frolushkin ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu May 21 05:50:19 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 May 2015 07:50:19 +0200 Subject: [Freeipa-users] confused by ldapsearch results In-Reply-To: <642326D3671873428E03A5AB2A1ACF0811B89A1D@NDMSMBX301.ndc.nasa.gov> References: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> <555B9C54.6050302@redhat.com> <642326D3671873428E03A5AB2A1ACF0811B89A1D@NDMSMBX301.ndc.nasa.gov> Message-ID: <555D721B.4050902@redhat.com> On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: > << > This worked for me: > > $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm > "(|(uid=admin)(name=admin))" dn > SASL/GSSAPI authentication started > SASL username: admin at EXAMPLE.COM > SASL SSF: 56 > SASL data security layer installed. > dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com > > Note that cn is Common Name which is set to the user's full name, in this case likely "George Boyce". So that will never match gboyce. > > Rob >>> > > Rob, > > Thanks for your example, it had me test my ldap bind which narrows the problem and gives me a workaround. > > I used cn=gboyce to pull my group record, so I expected my test to return two records for my account and my group. And it does when I authenticate as admin as in your test. So the problem is isolated to when I use a dedicated search account. I missed this note on setting up system accounts: > > << > Note: IPA 4.0 is going to change the default stance on data from nearly everything is readable to nothing is readable, by default. You will eventually need to add some Access Control Instructions (ACI's) to grant read access to the parts of the LDAP tree you will need. >>> > > Looks like I need to do just that. :-) > > Still the behavior of returning nothing by adding an extra false term, IIRC, this is done on purpose, there was an CVE and as a fix, if you are querying with an attribute you do not have permission to query with, you get no answers. > or returning one entry when each of the terms each returns a unique entry, seems wrong. > It does return two entries when both are in the same subtree. This one sounds strange, CCing Ludwig for reference. > > ### > ### everything ok when using admin... two records, one from users, one from groups > ### > # ldapsearch -Y GSSAPI -b "dc=..." "(|(uid=admin)(cn=gboyce))" dn > SASL/GSSAPI authentication started > SASL username: admin at ... > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (|(uid=admin)(cn=gboyce)) > # requesting: dn > # > > # admin, users, accounts, ... > dn: uid=admin,cn=users,cn=accounts,dc=... > > # gboyce, groups, accounts, ... > dn: cn=gboyce,cn=groups,cn=accounts,dc=... > > # search result > search: 4 > result: 0 Success > > # numResponses: 3 > # numEntries: 2 > > ########################################################################################## > > ### > ### system account (without ACLs) returns simple queries, but not correct results for compound queries in different subtrees > ### > > ### > ### different subtrees fails... > ### > # ldapsearch -x -D "uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=..." -w "..." -b "dc=..." "(|(uid=admin)(cn=gboyce))" dn > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (|(uid=admin)(cn=gboyce)) > # requesting: dn > # > > # admin, users, accounts, ... > dn: uid=admin,cn=users,cn=accounts,dc=... > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > ### > ### same subtree works... > ### > # l "(|(cn=admins)(cn=gboyce))" dn > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (|(cn=admins)(cn=gboyce)) > # requesting: dn > # > > # admins, groups, accounts, ... > dn: cn=admins,cn=groups,cn=accounts,dc=... > > # gboyce, groups, accounts, ... > dn: cn=gboyce,cn=groups,cn=accounts,dc=... > > # search result > search: 2 > result: 0 Success > > # numResponses: 3 > # numEntries: 2 > > ### > ### valid filter from above with extra false term... > ### > # l "(|(cn=admins)(cn=gboyce)(name=foobar))" dn > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (|(cn=admins)(cn=gboyce)(name=foobar)) > # requesting: dn > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > From lkrispen at redhat.com Thu May 21 06:34:21 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 08:34:21 +0200 Subject: [Freeipa-users] confused by ldapsearch results In-Reply-To: <555D721B.4050902@redhat.com> References: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> <555B9C54.6050302@redhat.com> <642326D3671873428E03A5AB2A1ACF0811B89A1D@NDMSMBX301.ndc.nasa.gov> <555D721B.4050902@redhat.com> Message-ID: <555D7C6D.2090804@redhat.com> On 05/21/2015 07:50 AM, Martin Kosek wrote: > On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: >> << >> This worked for me: >> >> $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm >> "(|(uid=admin)(name=admin))" dn >> SASL/GSSAPI authentication started >> SASL username: admin at EXAMPLE.COM >> SASL SSF: 56 >> SASL data security layer installed. >> dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com >> >> Note that cn is Common Name which is set to the user's full name, in this case likely "George Boyce". So that will never match gboyce. >> >> Rob >> Rob, >> >> Thanks for your example, it had me test my ldap bind which narrows the problem and gives me a workaround. >> >> I used cn=gboyce to pull my group record, so I expected my test to return two records for my account and my group. And it does when I authenticate as admin as in your test. So the problem is isolated to when I use a dedicated search account. I missed this note on setting up system accounts: >> >> << >> Note: IPA 4.0 is going to change the default stance on data from nearly everything is readable to nothing is readable, by default. You will eventually need to add some Access Control Instructions (ACI's) to grant read access to the parts of the LDAP tree you will need. >> Looks like I need to do just that. :-) >> >> Still the behavior of returning nothing by adding an extra false term, > IIRC, this is done on purpose, there was an CVE and as a fix, if you are > querying with an attribute you do not have permission to query with, you get no > answers. correct. It was https://bugzilla.redhat.com/show_bug.cgi?id=979508 and behaviour matches the spec in 13.3.3.3: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Permissions For the other problem, there is not enough information to judge. If two entries are in different subtrees also different acis could apply, we need the full set of acis, the full search and eventuallay access control logging (nsslapd-errorlog-level: 128) > >> or returning one entry when each of the terms each returns a unique entry, > seems wrong. >> It does return two entries when both are in the same subtree. > This one sounds strange, CCing Ludwig for reference. > >> ### >> ### everything ok when using admin... two records, one from users, one from groups >> ### >> # ldapsearch -Y GSSAPI -b "dc=..." "(|(uid=admin)(cn=gboyce))" dn >> SASL/GSSAPI authentication started >> SASL username: admin at ... >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (|(uid=admin)(cn=gboyce)) >> # requesting: dn >> # >> >> # admin, users, accounts, ... >> dn: uid=admin,cn=users,cn=accounts,dc=... >> >> # gboyce, groups, accounts, ... >> dn: cn=gboyce,cn=groups,cn=accounts,dc=... >> >> # search result >> search: 4 >> result: 0 Success >> >> # numResponses: 3 >> # numEntries: 2 >> >> ########################################################################################## >> >> ### >> ### system account (without ACLs) returns simple queries, but not correct results for compound queries in different subtrees >> ### >> >> ### >> ### different subtrees fails... >> ### >> # ldapsearch -x -D "uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=..." -w "..." -b "dc=..." "(|(uid=admin)(cn=gboyce))" dn >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (|(uid=admin)(cn=gboyce)) >> # requesting: dn >> # >> >> # admin, users, accounts, ... >> dn: uid=admin,cn=users,cn=accounts,dc=... >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> ### >> ### same subtree works... >> ### >> # l "(|(cn=admins)(cn=gboyce))" dn >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (|(cn=admins)(cn=gboyce)) >> # requesting: dn >> # >> >> # admins, groups, accounts, ... >> dn: cn=admins,cn=groups,cn=accounts,dc=... >> >> # gboyce, groups, accounts, ... >> dn: cn=gboyce,cn=groups,cn=accounts,dc=... >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 3 >> # numEntries: 2 >> >> ### >> ### valid filter from above with extra false term... >> ### >> # l "(|(cn=admins)(cn=gboyce)(name=foobar))" dn >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (|(cn=admins)(cn=gboyce)(name=foobar)) >> # requesting: dn >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> >> From rug at usm.lmu.de Thu May 21 06:59:24 2015 From: rug at usm.lmu.de (Rudolf Gabler) Date: Thu, 21 May 2015 08:59:24 +0200 Subject: [Freeipa-users] compat settings Message-ID: <511ED412-6929-41C9-AB33-9344CC09AA76@usm.lmu.de> Hi to whom it may concern, we used for many years a 2 location policy to separate email users from unix users in order to not using the same passwords. So we had 2 trees in our LDAP with the same user but different passwords. In freeipa (where we want to migrate now) I can use the accounts and compat (for email) trees for this purpose and so I added a dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config changetype: modify add: schema-compat-entry-attribute schema-compat-entry-attribute: userPassword=* to the compat settings to have a separate place for the password (!not userPassword=%{userPassword}, because then the accounts password are mirrored). This works, but I?m not allowed to change the password i.e. with: ldappasswd -x -D "cn=Directory Manager" -W -S uid=myuser,cn=users,cn=compat,dc=example,dc=com I get a result of: No such object (32) Additional info: Failed to update password where as for the accounts tree the ldappasswd is working fine. What additional setting may be required? Regards, Rudi Gabler -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lkrispen at redhat.com Thu May 21 07:37:04 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 09:37:04 +0200 Subject: [Freeipa-users] ruv problem In-Reply-To: <2e196e1717564d8691c4dd7d090d9194@sib-ums03.Megafon.ru> References: <2e196e1717564d8691c4dd7d090d9194@sib-ums03.Megafon.ru> Message-ID: <555D8B20.3010109@redhat.com> could you try this: https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html it was successfully applied before On 05/21/2015 06:58 AM, Alexander Frolushkin wrote: > > Hello again. > > Is it now clear how to deal with problem ipa-replica-manage list-ruv > showing > > unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 > > ? > > I have this on all of my 17 servers, including a new replica created > recently, and > > ipa-replica-manage clean-ruv 16 says > > unable to decode: {replica 16} 548a8126000000100000 > 548a8126000000100000 Replica ID 16 not found" > > WBR, > > Alexander Frolushkin > > > ------------------------------------------------------------------------ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? > ???, ??????? ??? ??????????. ? ????????? ????? ??????????? > ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? > ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? > ?????????, ?? ?????????????, ?????????????, ??????????? ??? > ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? > ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, > ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? > ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for > the use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally > privileged information. The contents may not be disclosed or used by > anyone other than the addressee. If you are not the intended > recipient(s), any use, disclosure, copying, distribution or any action > taken or omitted to be taken in reliance on it is prohibited and may > be unlawful. If you have received this communication in error please > notify us immediately by responding to this email and then delete the > e-mail and all attachments and any copies thereof. > > (c)20mf50 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu May 21 07:43:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 21 May 2015 10:43:53 +0300 Subject: [Freeipa-users] compat settings In-Reply-To: <511ED412-6929-41C9-AB33-9344CC09AA76@usm.lmu.de> References: <511ED412-6929-41C9-AB33-9344CC09AA76@usm.lmu.de> Message-ID: <20150521074353.GP21881@redhat.com> On Thu, 21 May 2015, Rudolf Gabler wrote: >Hi to whom it may concern, > > >we used for many years a 2 location policy to separate email users from >unix users in order to not using the same passwords. So we had 2 trees >in our LDAP with the same user but different passwords. > >In freeipa (where we want to migrate now) I can use the accounts and >compat (for email) trees for this purpose and so I added a > >dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >changetype: modify >add: schema-compat-entry-attribute >schema-compat-entry-attribute: userPassword=* >to the compat settings to have a separate place for the password (!not >userPassword=%{userPassword}, because then the accounts password are >mirrored). This works, but I?m not allowed to change the password i.e. >with: ldappasswd -x -D "cn=Directory Manager" -W -S >uid=myuser,cn=users,cn=compat,dc=example,dc=com >I get a result of: > >No such object (32) >Additional info: Failed to update password > >where as for the accounts tree the ldappasswd is working fine. >What additional setting may be required? slapi-nis does not support modifying entries in the compat tree. The tree is virtual, it is re-populated from the original data every time 389-ds server is restarted. -- / Alexander Bokovoy From Alexander.Frolushkin at megafon.ru Thu May 21 07:50:26 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Thu, 21 May 2015 07:50:26 +0000 Subject: [Freeipa-users] ruv problem In-Reply-To: <555D8B20.3010109@redhat.com> References: <2e196e1717564d8691c4dd7d090d9194@sib-ums03.Megafon.ru> <555D8B20.3010109@redhat.com> Message-ID: Thank you. Do I need to run this on each of my 17 IPA servers in unix domain? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz Sent: Thursday, May 21, 2015 1:37 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] ruv problem could you try this: https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html it was successfully applied before On 05/21/2015 06:58 AM, Alexander Frolushkin wrote: Hello again. Is it now clear how to deal with problem ipa-replica-manage list-ruv showing unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 ? I have this on all of my 17 servers, including a new replica created recently, and ipa-replica-manage clean-ruv 16 says unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 Replica ID 16 not found" WBR, Alexander Frolushkin ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Thu May 21 08:37:36 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 10:37:36 +0200 Subject: [Freeipa-users] ruv problem In-Reply-To: References: <2e196e1717564d8691c4dd7d090d9194@sib-ums03.Megafon.ru> <555D8B20.3010109@redhat.com> Message-ID: <555D9950.3040106@redhat.com> On 05/21/2015 09:50 AM, Alexander Frolushkin wrote: > > Thank you. Do I need to run this on each of my 17 IPA servers in unix > domain? > no, the cleanallruv task should be propagated to all server a repl agreement exists > > WBR, > > Alexander Frolushkin > > Cell +79232508764 > > Work +79232507764 > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Ludwig Krispenz > *Sent:* Thursday, May 21, 2015 1:37 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] ruv problem > > could you try this: > https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html > it was successfully applied before > > On 05/21/2015 06:58 AM, Alexander Frolushkin wrote: > > Hello again. > > Is it now clear how to deal with problem ipa-replica-manage > list-ruv showing > > unable to decode: {replica 16} 548a8126000000100000 > 548a8126000000100000 > > ? > > I have this on all of my 17 servers, including a new replica > created recently, and > > ipa-replica-manage clean-ruv 16 says > > unable to decode: {replica 16} 548a8126000000100000 > 548a8126000000100000 Replica ID 16 not found" > > WBR, > > Alexander Frolushkin > > ------------------------------------------------------------------------ > > > ?????????? ? ???? ????????? ????????????? ????????????? ??? > ?????????? ???, ??????? ??? ??????????. ? ????????? ????? > ??????????? ???????????????? ??????????, ??????? ?? ????? ???? > ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? > ??????? ????? ?????????, ?? ?????????????, ?????????????, > ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? > ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, > ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? > ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? > ??????????. > > The information contained in this communication is intended solely > for the use of the individual or entity to whom it is addressed > and others authorized to receive it. It may contain confidential > or legally privileged information. The contents may not be > disclosed or used by anyone other than the addressee. If you are > not the intended recipient(s), any use, disclosure, copying, > distribution or any action taken or omitted to be taken in > reliance on it is prohibited and may be unlawful. If you have > received this communication in error please notify us immediately > by responding to this email and then delete the e-mail and all > attachments and any copies thereof. > > (c)20mf50 > > > > ------------------------------------------------------------------------ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? > ???, ??????? ??? ??????????. ? ????????? ????? ??????????? > ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? > ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? > ?????????, ?? ?????????????, ?????????????, ??????????? ??? > ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? > ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, > ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? > ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for > the use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally > privileged information. The contents may not be disclosed or used by > anyone other than the addressee. If you are not the intended > recipient(s), any use, disclosure, copying, distribution or any action > taken or omitted to be taken in reliance on it is prohibited and may > be unlawful. If you have received this communication in error please > notify us immediately by responding to this email and then delete the > e-mail and all attachments and any copies thereof. > > (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu May 21 10:51:07 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 May 2015 12:51:07 +0200 Subject: [Freeipa-users] Updates refused when trying to do dynamic DNS updates with TSIG In-Reply-To: References: Message-ID: <555DB89B.1060400@redhat.com> On 20.5.2015 17:38, Brian Koontz wrote: > Running FreeIPA 4.1.4, Fedora 21. Trying to get dynamic DNS updates on > clients to work following these instructions: > > http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG > > (Using GSS-TSIG isn't an option because I have no way of authenticating > every time a client IP changes.) Generally, GSS-TSIG with Kerberos should not be affected by changes in client's IP address and is strongly recommended over TSIG. > I've reread the instructions several times, but each time I get "update > failed: REFUSED". Logs aren't showing anything useful other than the query > is being refused. Is this document missing an important step? Yes, thank you for catching this! I added 'ipa dnszone-mod --dynamic-update=1' command to the how-to: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG#Server > (I saw no > need to create a DNS/ service as there should be no krb5 authentication > involved here...) This is correct assumption, you should not need it. Thank you for your time! -- Petr^2 Spacek From janellenicole80 at gmail.com Thu May 21 11:36:00 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 04:36:00 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555CA000.4030208@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> Message-ID: <555DC320.30203@gmail.com> On 5/20/15 7:53 AM, Mark Reynolds wrote: > > > On 05/20/2015 10:17 AM, thierry bordaz wrote: >> On 05/20/2015 03:46 PM, Janelle wrote: >>> On 5/20/15 6:01 AM, thierry bordaz wrote: >>>> On 05/20/2015 02:57 AM, Janelle wrote: >>>>> On 5/19/15 12:04 AM, thierry bordaz wrote: >>>>>> On 05/19/2015 03:42 AM, Janelle wrote: >>>>>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>>>>> Once again, replication/sync has been lost. I really wish the >>>>>>>> product was more stable, it is so much potential and yet. >>>>>>>> >>>>>>>> Servers running for 6 days no issues. No new accounts or >>>>>>>> changes (maybe a few users changing passwords) and again, 5 out >>>>>>>> of 16 servers are no longer in sync. >>>>>>>> >>>>>>>> I can test it easily by adding an account and then waiting a >>>>>>>> few minutes, then run "ipa user-show --all username" on all >>>>>>>> the servers, and only a few of them have the account. I have >>>>>>>> now waited 15 minutes, still no luck. >>>>>>>> >>>>>>>> Oh well.. I guess I will go look at alternatives. I had such >>>>>>>> high hopes for this tool. Thanks so much everyone for all your >>>>>>>> help in trying to get things stable, but for whatever reason, >>>>>>>> there is a random loss of sync among the servers and obviously >>>>>>>> this is not acceptable. >>>>>>>> >>>>>>>> regards >>>>>>>> ~J >>>>>>> >>>>> >>>>> All the replicas are happy again. I found these again: >>>>> >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 23} 5553e3a3000000170000 >>>>> 55543240000300170000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> >>>>> What I also found to be interesting is that I have not deleted any >>>>> masters at all, so this was quite perplexing where the orphaned >>>>> entries came from. However I did find 3 of the replicas did not >>>>> show complete RUV lists... While most of the replicas had a list >>>>> of all 16 servers, a couple of them listed only 4 or 5. (using >>>>> ipa-replica-manage list-ruv) >>>> I don't know about the orphaned entries. Did you get entries below >>>> deleted parents ? >>>> >>>> AFAIK all replicas are master and so have an entry {replica } >>>> in the RUV. We should expect all servers having the same number of >>>> RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated >>>> so that they did not received updates from those with 16 RUVelements. >>>> would you copy/paste an example of RUV with 16 and with 4-5 ? >>> >>> Now, the steps to clear this were: >>> >>> Removed the "unable to decode" with the direct ldapmodify's. This >>> worked across all replicas, which was nice and did not have to be >>> repeated in each one. In other words, entered on a single server, >>> and it was removed on all. >> Hello, >> >> Did you do direct ldapmodify onto the RUV entry >> (nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,SUFFIX) , clean RUV ? > Thierry, > > Janelle just manually added a cleanallruv task (that I had recommended > the other week). > > Mark >> >> dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an >> update on dc3-ipa1, is it replicated to dc1-ipa[12] ? >> >> Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389. >> You may see some messages like 'attrlist_replace' in some error logs. >> 25 seems to be the new RID. >> >> thanks >> thierry >> >>> >>> re-initialized --from=good server on the ones with the short list. >>> >>> Waited 5 minutes to let everything settle, then started running >>> tests of adds/deletes which seemed to be just fine. >>> >>> Here are 2 of the DCs >>> >>> ------------------------------------- >>> Node dc1-ipa1 >>> ------------------------------------- >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa4.example.com 389 4 >>> ------------------------------------- >>> Node dc1-ipa2 >>> ------------------------------------- >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa2.example.com 389 25 >>> dc1-ipa3.example.com 389 8 >>> dc1-ipa4.example.com 389 4 >>> ------------------------------------- >>> Node dc1-ipa3 >>> ------------------------------------- >>> dc3-ipa1.example.com 389 14 >>> dc3-ipa2.example.com 389 13 >>> dc3-ipa3.example.com 389 12 >>> dc3-ipa4.example.com 389 11 >>> dc2-ipa1.example.com 389 7 >>> dc2-ipa2.example.com 389 6 >>> dc2-ipa3.example.com 389 5 >>> dc2-ipa4.example.com 389 3 >>> dc4-ipa1.example.com 389 18 >>> dc4-ipa2.example.com 389 19 >>> dc4-ipa3.example.com 389 20 >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa2.example.com 389 25 >>> dc1-ipa2.example.com 389 9 >>> dc1-ipa3.example.com 389 8 >>> dc1-ipa4.example.com 389 4 >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> dc5-ipa1.example.com 389 26 >>> dc5-ipa2.example.com 389 15 >>> dc5-ipa3.example.com 389 17 >>> ------------------------------------- >>> Node dc1-ipa4 >>> ------------------------------------- >>> dc3-ipa1.example.com 389 14 >>> dc3-ipa2.example.com 389 13 >>> dc3-ipa3.example.com 389 12 >>> dc3-ipa4.example.com 389 11 >>> dc2-ipa1.example.com 389 7 >>> dc2-ipa2.example.com 389 6 >>> dc2-ipa3.example.com 389 5 >>> dc2-ipa4.example.com 389 3 >>> dc4-ipa1.example.com 389 18 >>> dc4-ipa2.example.com 389 19 >>> dc4-ipa3.example.com 389 20 >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa2.example.com 389 25 >>> dc1-ipa2.example.com 389 9 >>> dc1-ipa3.example.com 389 8 >>> dc1-ipa4.example.com 389 4 >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> dc5-ipa1.example.com 389 26 >>> dc5-ipa2.example.com 389 15 >>> dc5-ipa3.example.com 389 17 >>> ------------------------------------- >>> Node dc2-ipa1 >>> ------------------------------------- >>> dc3-ipa1.example.com 389 14 >>> dc3-ipa2.example.com 389 13 >>> dc3-ipa3.example.com 389 12 >>> dc3-ipa4.example.com 389 11 >>> dc2-ipa1.example.com 389 7 >>> dc2-ipa2.example.com 389 6 >>> dc2-ipa3.example.com 389 5 >>> dc2-ipa4.example.com 389 3 >>> dc4-ipa1.example.com 389 18 >>> dc4-ipa2.example.com 389 19 >>> dc4-ipa3.example.com 389 20 >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa2.example.com 389 25 >>> dc1-ipa2.example.com 389 9 >>> dc1-ipa3.example.com 389 8 >>> dc1-ipa4.example.com 389 4 >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 23} 5553e3a3000000170000 55543240000300170000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> dc5-ipa1.example.com 389 26 >>> dc5-ipa2.example.com 389 15 >>> dc5-ipa3.example.com 389 17 >>> ------------------------------------- >>> Node dc2-ipa2 >>> ------------------------------------- >>> dc3-ipa1.example.com 389 14 >>> dc3-ipa2.example.com 389 13 >>> dc3-ipa3.example.com 389 12 >>> dc3-ipa4.example.com 389 11 >>> dc2-ipa1.example.com 389 7 >>> dc2-ipa2.example.com 389 6 >>> dc2-ipa3.example.com 389 5 >>> dc2-ipa4.example.com 389 3 >>> dc4-ipa1.example.com 389 18 >>> dc4-ipa2.example.com 389 19 >>> dc4-ipa3.example.com 389 20 >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa2.example.com 389 25 >>> dc1-ipa2.example.com 389 9 >>> dc1-ipa3.example.com 389 8 >>> dc1-ipa4.example.com 389 4 >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> dc5-ipa1.example.com 389 26 >>> dc5-ipa2.example.com 389 15 >>> dc5-ipa3.example.com 389 17 >>> ------------------------------------- >>> Node dc2-ipa3 >>> ------------------------------------- >>> dc3-ipa1.example.com 389 14 >>> dc3-ipa2.example.com 389 13 >>> dc3-ipa3.example.com 389 12 >>> dc3-ipa4.example.com 389 11 >>> dc2-ipa1.example.com 389 7 >>> dc2-ipa2.example.com 389 6 >>> dc2-ipa3.example.com 389 5 >>> dc2-ipa4.example.com 389 3 >>> dc4-ipa1.example.com 389 18 >>> dc4-ipa2.example.com 389 19 >>> dc4-ipa3.example.com 389 20 >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa2.example.com 389 25 >>> dc1-ipa2.example.com 389 9 >>> dc1-ipa3.example.com 389 8 >>> dc1-ipa4.example.com 389 4 >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> dc5-ipa1.example.com 389 26 >>> dc5-ipa2.example.com 389 15 >>> dc5-ipa3.example.com 389 17 >>> ------------------------------------- >>> Node dc2-ipa4 >>> ------------------------------------- >>> dc3-ipa1.example.com 389 14 >>> dc3-ipa2.example.com 389 13 >>> dc3-ipa3.example.com 389 12 >>> dc3-ipa4.example.com 389 11 >>> dc2-ipa1.example.com 389 7 >>> dc2-ipa2.example.com 389 6 >>> dc2-ipa3.example.com 389 5 >>> dc2-ipa4.example.com 389 3 >>> dc4-ipa1.example.com 389 18 >>> dc4-ipa2.example.com 389 19 >>> dc4-ipa3.example.com 389 20 >>> dc4-ipa4.example.com 389 21 >>> dc1-ipa1.example.com 389 10 >>> dc1-ipa2.example.com 389 25 >>> dc1-ipa2.example.com 389 9 >>> dc1-ipa3.example.com 389 8 >>> dc1-ipa4.example.com 389 4 >>> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >>> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >>> dc5-ipa1.example.com 389 26 >>> dc5-ipa2.example.com 389 15 >>> dc5-ipa3.example.com 389 17 >>> >>> >>> Happy Wednesday >>> ~Janelle >> >> >> > And just like that - for no reason, they all reappeared: unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 23} 5545d61f000200170000 5552f718000300170000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 :-( ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Thu May 21 12:16:19 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 14:16:19 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DC320.30203@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> Message-ID: <555DCC93.4090807@redhat.com> On 05/21/2015 01:36 PM, Janelle wrote: > And just like that - for no reason, they all reappeared: > > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 23} 5545d61f000200170000 5552f718000300170000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > > :-( > ~J > so it is the same set of rids again. Just to be sure, do servers with rid 16, 23 and 24 still exist ? I think last time you cleaned them by ldapmodify, so they should no longer exist. you said you would enable logging, did you find something in the logs ? or can we have a look at them ? Ludwig -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu May 21 12:20:32 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 21 May 2015 14:20:32 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DC320.30203@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> Message-ID: <555DCD90.4070306@redhat.com> On 05/21/2015 01:36 PM, Janelle wrote: > On 5/20/15 7:53 AM, Mark Reynolds wrote: >> >> >> On 05/20/2015 10:17 AM, thierry bordaz wrote: >>> On 05/20/2015 03:46 PM, Janelle wrote: >>>> On 5/20/15 6:01 AM, thierry bordaz wrote: >>>>> On 05/20/2015 02:57 AM, Janelle wrote: >>>>>> On 5/19/15 12:04 AM, thierry bordaz wrote: >>>>>>> On 05/19/2015 03:42 AM, Janelle wrote: >>>>>>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>>>>>> Once again, replication/sync has been lost. I really wish the >>>>>>>>> product was more stable, it is so much potential and yet. >>>>>>>>> >>>>>>>>> Servers running for 6 days no issues. No new accounts or >>>>>>>>> changes (maybe a few users changing passwords) and again, 5 >>>>>>>>> out of 16 servers are no longer in sync. >>>>>>>>> >>>>>>>>> I can test it easily by adding an account and then waiting a >>>>>>>>> few minutes, then run "ipa user-show --all username" on all >>>>>>>>> the servers, and only a few of them have the account. I have >>>>>>>>> now waited 15 minutes, still no luck. >>>>>>>>> >>>>>>>>> Oh well.. I guess I will go look at alternatives. I had such >>>>>>>>> high hopes for this tool. Thanks so much everyone for all your >>>>>>>>> help in trying to get things stable, but for whatever reason, >>>>>>>>> there is a random loss of sync among the servers and obviously >>>>>>>>> this is not acceptable. >>>>>>>>> >>>>>>>>> regards >>>>>>>>> ~J >>>>>>>> >>>>>> >>>>>> All the replicas are happy again. I found these again: >>>>>> >>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>> 55356472000300100000 >>>>>> unable to decode {replica 23} 5553e3a3000000170000 >>>>>> 55543240000300170000 >>>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>>> 554d54a4000200180000 >>>>>> >>>>>> What I also found to be interesting is that I have not deleted >>>>>> any masters at all, so this was quite perplexing where the >>>>>> orphaned entries came from. However I did find 3 of the replicas >>>>>> did not show complete RUV lists... While most of the replicas had >>>>>> a list of all 16 servers, a couple of them listed only 4 or 5. >>>>>> (using ipa-replica-manage list-ruv) >>>>> I don't know about the orphaned entries. Did you get entries below >>>>> deleted parents ? >>>>> >>>>> AFAIK all replicas are master and so have an entry {replica } >>>>> in the RUV. We should expect all servers having the same number of >>>>> RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated >>>>> so that they did not received updates from those with 16 RUVelements. >>>>> would you copy/paste an example of RUV with 16 and with 4-5 ? >>>> >>>> Now, the steps to clear this were: >>>> >>>> Removed the "unable to decode" with the direct ldapmodify's. This >>>> worked across all replicas, which was nice and did not have to be >>>> repeated in each one. In other words, entered on a single server, >>>> and it was removed on all. >>> Hello, >>> >>> Did you do direct ldapmodify onto the RUV entry >>> (nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,SUFFIX) , clean RUV ? >> Thierry, >> >> Janelle just manually added a cleanallruv task (that I had >> recommended the other week). >> >> Mark >>> >>> dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an >>> update on dc3-ipa1, is it replicated to dc1-ipa[12] ? >>> >>> Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389. >>> You may see some messages like 'attrlist_replace' in some error logs. >>> 25 seems to be the new RID. >>> >>> thanks >>> thierry >>> >>>> >>>> re-initialized --from=good server on the ones with the short list. >>>> >>>> Waited 5 minutes to let everything settle, then started running >>>> tests of adds/deletes which seemed to be just fine. >>>> >>>> Here are 2 of the DCs >>>> >>>> ------------------------------------- >>>> Node dc1-ipa1 >>>> ------------------------------------- >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa4.example.com 389 4 >>>> ------------------------------------- >>>> Node dc1-ipa2 >>>> ------------------------------------- >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa2.example.com 389 25 >>>> dc1-ipa3.example.com 389 8 >>>> dc1-ipa4.example.com 389 4 >>>> ------------------------------------- >>>> Node dc1-ipa3 >>>> ------------------------------------- >>>> dc3-ipa1.example.com 389 14 >>>> dc3-ipa2.example.com 389 13 >>>> dc3-ipa3.example.com 389 12 >>>> dc3-ipa4.example.com 389 11 >>>> dc2-ipa1.example.com 389 7 >>>> dc2-ipa2.example.com 389 6 >>>> dc2-ipa3.example.com 389 5 >>>> dc2-ipa4.example.com 389 3 >>>> dc4-ipa1.example.com 389 18 >>>> dc4-ipa2.example.com 389 19 >>>> dc4-ipa3.example.com 389 20 >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa2.example.com 389 25 >>>> dc1-ipa2.example.com 389 9 >>>> dc1-ipa3.example.com 389 8 >>>> dc1-ipa4.example.com 389 4 >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> dc5-ipa1.example.com 389 26 >>>> dc5-ipa2.example.com 389 15 >>>> dc5-ipa3.example.com 389 17 >>>> ------------------------------------- >>>> Node dc1-ipa4 >>>> ------------------------------------- >>>> dc3-ipa1.example.com 389 14 >>>> dc3-ipa2.example.com 389 13 >>>> dc3-ipa3.example.com 389 12 >>>> dc3-ipa4.example.com 389 11 >>>> dc2-ipa1.example.com 389 7 >>>> dc2-ipa2.example.com 389 6 >>>> dc2-ipa3.example.com 389 5 >>>> dc2-ipa4.example.com 389 3 >>>> dc4-ipa1.example.com 389 18 >>>> dc4-ipa2.example.com 389 19 >>>> dc4-ipa3.example.com 389 20 >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa2.example.com 389 25 >>>> dc1-ipa2.example.com 389 9 >>>> dc1-ipa3.example.com 389 8 >>>> dc1-ipa4.example.com 389 4 >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> dc5-ipa1.example.com 389 26 >>>> dc5-ipa2.example.com 389 15 >>>> dc5-ipa3.example.com 389 17 >>>> ------------------------------------- >>>> Node dc2-ipa1 >>>> ------------------------------------- >>>> dc3-ipa1.example.com 389 14 >>>> dc3-ipa2.example.com 389 13 >>>> dc3-ipa3.example.com 389 12 >>>> dc3-ipa4.example.com 389 11 >>>> dc2-ipa1.example.com 389 7 >>>> dc2-ipa2.example.com 389 6 >>>> dc2-ipa3.example.com 389 5 >>>> dc2-ipa4.example.com 389 3 >>>> dc4-ipa1.example.com 389 18 >>>> dc4-ipa2.example.com 389 19 >>>> dc4-ipa3.example.com 389 20 >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa2.example.com 389 25 >>>> dc1-ipa2.example.com 389 9 >>>> dc1-ipa3.example.com 389 8 >>>> dc1-ipa4.example.com 389 4 >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 23} 5553e3a3000000170000 >>>> 55543240000300170000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> dc5-ipa1.example.com 389 26 >>>> dc5-ipa2.example.com 389 15 >>>> dc5-ipa3.example.com 389 17 >>>> ------------------------------------- >>>> Node dc2-ipa2 >>>> ------------------------------------- >>>> dc3-ipa1.example.com 389 14 >>>> dc3-ipa2.example.com 389 13 >>>> dc3-ipa3.example.com 389 12 >>>> dc3-ipa4.example.com 389 11 >>>> dc2-ipa1.example.com 389 7 >>>> dc2-ipa2.example.com 389 6 >>>> dc2-ipa3.example.com 389 5 >>>> dc2-ipa4.example.com 389 3 >>>> dc4-ipa1.example.com 389 18 >>>> dc4-ipa2.example.com 389 19 >>>> dc4-ipa3.example.com 389 20 >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa2.example.com 389 25 >>>> dc1-ipa2.example.com 389 9 >>>> dc1-ipa3.example.com 389 8 >>>> dc1-ipa4.example.com 389 4 >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> dc5-ipa1.example.com 389 26 >>>> dc5-ipa2.example.com 389 15 >>>> dc5-ipa3.example.com 389 17 >>>> ------------------------------------- >>>> Node dc2-ipa3 >>>> ------------------------------------- >>>> dc3-ipa1.example.com 389 14 >>>> dc3-ipa2.example.com 389 13 >>>> dc3-ipa3.example.com 389 12 >>>> dc3-ipa4.example.com 389 11 >>>> dc2-ipa1.example.com 389 7 >>>> dc2-ipa2.example.com 389 6 >>>> dc2-ipa3.example.com 389 5 >>>> dc2-ipa4.example.com 389 3 >>>> dc4-ipa1.example.com 389 18 >>>> dc4-ipa2.example.com 389 19 >>>> dc4-ipa3.example.com 389 20 >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa2.example.com 389 25 >>>> dc1-ipa2.example.com 389 9 >>>> dc1-ipa3.example.com 389 8 >>>> dc1-ipa4.example.com 389 4 >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> dc5-ipa1.example.com 389 26 >>>> dc5-ipa2.example.com 389 15 >>>> dc5-ipa3.example.com 389 17 >>>> ------------------------------------- >>>> Node dc2-ipa4 >>>> ------------------------------------- >>>> dc3-ipa1.example.com 389 14 >>>> dc3-ipa2.example.com 389 13 >>>> dc3-ipa3.example.com 389 12 >>>> dc3-ipa4.example.com 389 11 >>>> dc2-ipa1.example.com 389 7 >>>> dc2-ipa2.example.com 389 6 >>>> dc2-ipa3.example.com 389 5 >>>> dc2-ipa4.example.com 389 3 >>>> dc4-ipa1.example.com 389 18 >>>> dc4-ipa2.example.com 389 19 >>>> dc4-ipa3.example.com 389 20 >>>> dc4-ipa4.example.com 389 21 >>>> dc1-ipa1.example.com 389 10 >>>> dc1-ipa2.example.com 389 25 >>>> dc1-ipa2.example.com 389 9 >>>> dc1-ipa3.example.com 389 8 >>>> dc1-ipa4.example.com 389 4 >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> dc5-ipa1.example.com 389 26 >>>> dc5-ipa2.example.com 389 15 >>>> dc5-ipa3.example.com 389 17 >>>> >>>> >>>> Happy Wednesday >>>> ~Janelle >>> >>> >>> >> > > And just like that - for no reason, they all reappeared: > > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 23} 5545d61f000200170000 5552f718000300170000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > > :-( > ~J > Hello Janelle, Those 3 RIDs were already present in Node dc2-ipa1, correct ? They reappeared on others nodes as well ? May be ds2-ipa1 established a replication session with its peers and send those RIDs. Could you track in all the access logs, when the op csn=5552f718000300170000 was applied. Note that the two hexa values of replica 23 changed (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 55543240000300170000). Have you recreated a replica 23 ?. Do you have replication logging enabled ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Thu May 21 12:21:38 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 05:21:38 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DCC93.4090807@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCC93.4090807@redhat.com> Message-ID: <555DCDD2.7040508@gmail.com> On 5/21/15 5:16 AM, Ludwig Krispenz wrote: > > On 05/21/2015 01:36 PM, Janelle wrote: >> And just like that - for no reason, they all reappeared: >> >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 23} 5545d61f000200170000 5552f718000300170000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> >> :-( >> ~J >> > > so it is the same set of rids again. Just to be sure, do servers with > rid 16, 23 and 24 still exist ? I think last time you cleaned them by > ldapmodify, so they should no longer exist. > > you said you would enable logging, did you find something in the logs > ? or can we have a look at them ? > > Ludwig > > They do NOT exist. Have not found anything in the logs. I also now have 2 masters who no longer start. Not sure if this is related, but starting them after a minute or so, dirsrv dies... For the last 48 hours things were working perfectly. Some minor adds and a few deletes, but replication was working flawlessly. Then I woke up to this. :-( Still a lot to go through before I can post anything. More to come. ~Janelle -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Thu May 21 12:23:52 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 05:23:52 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DCD90.4070306@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> Message-ID: <555DCE58.7040507@gmail.com> On 5/21/15 5:20 AM, thierry bordaz wrote: > On 05/21/2015 01:36 PM, Janelle wrote: >> On 5/20/15 7:53 AM, Mark Reynolds wrote: >>> >>> >>> On 05/20/2015 10:17 AM, thierry bordaz wrote: >>>> On 05/20/2015 03:46 PM, Janelle wrote: >>>>> On 5/20/15 6:01 AM, thierry bordaz wrote: >>>>>> On 05/20/2015 02:57 AM, Janelle wrote: >>>>>>> On 5/19/15 12:04 AM, thierry bordaz wrote: >>>>>>>> On 05/19/2015 03:42 AM, Janelle wrote: >>>>>>>>> On 5/18/15 6:23 PM, Janelle wrote: >>>>>>>>>> Once again, replication/sync has been lost. I really wish the >>>>>>>>>> product was more stable, it is so much potential and yet. >>>>>>>>>> >>>>>>>>>> Servers running for 6 days no issues. No new accounts or >>>>>>>>>> changes (maybe a few users changing passwords) and again, 5 >>>>>>>>>> out of 16 servers are no longer in sync. >>>>>>>>>> >>>>>>>>>> I can test it easily by adding an account and then waiting a >>>>>>>>>> few minutes, then run "ipa user-show --all username" on all >>>>>>>>>> the servers, and only a few of them have the account. I have >>>>>>>>>> now waited 15 minutes, still no luck. >>>>>>>>>> >>>>>>>>>> Oh well.. I guess I will go look at alternatives. I had such >>>>>>>>>> high hopes for this tool. Thanks so much everyone for all >>>>>>>>>> your help in trying to get things stable, but for whatever >>>>>>>>>> reason, there is a random loss of sync among the servers and >>>>>>>>>> obviously this is not acceptable. >>>>>>>>>> >>>>>>>>>> regards >>>>>>>>>> ~J >>>>>>>>> >>>>>>> >>>>>>> All the replicas are happy again. I found these again: >>>>>>> >>>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>>> 55356472000300100000 >>>>>>> unable to decode {replica 23} 5553e3a3000000170000 >>>>>>> 55543240000300170000 >>>>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>>>> 554d54a4000200180000 >>>>>>> >>>>>>> What I also found to be interesting is that I have not deleted >>>>>>> any masters at all, so this was quite perplexing where the >>>>>>> orphaned entries came from. However I did find 3 of the replicas >>>>>>> did not show complete RUV lists... While most of the replicas >>>>>>> had a list of all 16 servers, a couple of them listed only 4 or >>>>>>> 5. (using ipa-replica-manage list-ruv) >>>>>> I don't know about the orphaned entries. Did you get entries >>>>>> below deleted parents ? >>>>>> >>>>>> AFAIK all replicas are master and so have an entry {replica >>>>>> } in the RUV. We should expect all servers having the same >>>>>> number of RUVelements (16, 4 or 5). The servers with 4 or 5 may >>>>>> be isolated so that they did not received updates from those with >>>>>> 16 RUVelements. >>>>>> would you copy/paste an example of RUV with 16 and with 4-5 ? >>>>> >>>>> Now, the steps to clear this were: >>>>> >>>>> Removed the "unable to decode" with the direct ldapmodify's. This >>>>> worked across all replicas, which was nice and did not have to be >>>>> repeated in each one. In other words, entered on a single server, >>>>> and it was removed on all. >>>> Hello, >>>> >>>> Did you do direct ldapmodify onto the RUV entry >>>> (nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,SUFFIX) , clean RUV ? >>> Thierry, >>> >>> Janelle just manually added a cleanallruv task (that I had >>> recommended the other week). >>> >>> Mark >>>> >>>> dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an >>>> update on dc3-ipa1, is it replicated to dc1-ipa[12] ? >>>> >>>> Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389. >>>> You may see some messages like 'attrlist_replace' in some error logs. >>>> 25 seems to be the new RID. >>>> >>>> thanks >>>> thierry >>>> >>>>> >>>>> re-initialized --from=good server on the ones with the short list. >>>>> >>>>> Waited 5 minutes to let everything settle, then started running >>>>> tests of adds/deletes which seemed to be just fine. >>>>> >>>>> Here are 2 of the DCs >>>>> >>>>> ------------------------------------- >>>>> Node dc1-ipa1 >>>>> ------------------------------------- >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa4.example.com 389 4 >>>>> ------------------------------------- >>>>> Node dc1-ipa2 >>>>> ------------------------------------- >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa2.example.com 389 25 >>>>> dc1-ipa3.example.com 389 8 >>>>> dc1-ipa4.example.com 389 4 >>>>> ------------------------------------- >>>>> Node dc1-ipa3 >>>>> ------------------------------------- >>>>> dc3-ipa1.example.com 389 14 >>>>> dc3-ipa2.example.com 389 13 >>>>> dc3-ipa3.example.com 389 12 >>>>> dc3-ipa4.example.com 389 11 >>>>> dc2-ipa1.example.com 389 7 >>>>> dc2-ipa2.example.com 389 6 >>>>> dc2-ipa3.example.com 389 5 >>>>> dc2-ipa4.example.com 389 3 >>>>> dc4-ipa1.example.com 389 18 >>>>> dc4-ipa2.example.com 389 19 >>>>> dc4-ipa3.example.com 389 20 >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa2.example.com 389 25 >>>>> dc1-ipa2.example.com 389 9 >>>>> dc1-ipa3.example.com 389 8 >>>>> dc1-ipa4.example.com 389 4 >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> dc5-ipa1.example.com 389 26 >>>>> dc5-ipa2.example.com 389 15 >>>>> dc5-ipa3.example.com 389 17 >>>>> ------------------------------------- >>>>> Node dc1-ipa4 >>>>> ------------------------------------- >>>>> dc3-ipa1.example.com 389 14 >>>>> dc3-ipa2.example.com 389 13 >>>>> dc3-ipa3.example.com 389 12 >>>>> dc3-ipa4.example.com 389 11 >>>>> dc2-ipa1.example.com 389 7 >>>>> dc2-ipa2.example.com 389 6 >>>>> dc2-ipa3.example.com 389 5 >>>>> dc2-ipa4.example.com 389 3 >>>>> dc4-ipa1.example.com 389 18 >>>>> dc4-ipa2.example.com 389 19 >>>>> dc4-ipa3.example.com 389 20 >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa2.example.com 389 25 >>>>> dc1-ipa2.example.com 389 9 >>>>> dc1-ipa3.example.com 389 8 >>>>> dc1-ipa4.example.com 389 4 >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> dc5-ipa1.example.com 389 26 >>>>> dc5-ipa2.example.com 389 15 >>>>> dc5-ipa3.example.com 389 17 >>>>> ------------------------------------- >>>>> Node dc2-ipa1 >>>>> ------------------------------------- >>>>> dc3-ipa1.example.com 389 14 >>>>> dc3-ipa2.example.com 389 13 >>>>> dc3-ipa3.example.com 389 12 >>>>> dc3-ipa4.example.com 389 11 >>>>> dc2-ipa1.example.com 389 7 >>>>> dc2-ipa2.example.com 389 6 >>>>> dc2-ipa3.example.com 389 5 >>>>> dc2-ipa4.example.com 389 3 >>>>> dc4-ipa1.example.com 389 18 >>>>> dc4-ipa2.example.com 389 19 >>>>> dc4-ipa3.example.com 389 20 >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa2.example.com 389 25 >>>>> dc1-ipa2.example.com 389 9 >>>>> dc1-ipa3.example.com 389 8 >>>>> dc1-ipa4.example.com 389 4 >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 23} 5553e3a3000000170000 >>>>> 55543240000300170000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> dc5-ipa1.example.com 389 26 >>>>> dc5-ipa2.example.com 389 15 >>>>> dc5-ipa3.example.com 389 17 >>>>> ------------------------------------- >>>>> Node dc2-ipa2 >>>>> ------------------------------------- >>>>> dc3-ipa1.example.com 389 14 >>>>> dc3-ipa2.example.com 389 13 >>>>> dc3-ipa3.example.com 389 12 >>>>> dc3-ipa4.example.com 389 11 >>>>> dc2-ipa1.example.com 389 7 >>>>> dc2-ipa2.example.com 389 6 >>>>> dc2-ipa3.example.com 389 5 >>>>> dc2-ipa4.example.com 389 3 >>>>> dc4-ipa1.example.com 389 18 >>>>> dc4-ipa2.example.com 389 19 >>>>> dc4-ipa3.example.com 389 20 >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa2.example.com 389 25 >>>>> dc1-ipa2.example.com 389 9 >>>>> dc1-ipa3.example.com 389 8 >>>>> dc1-ipa4.example.com 389 4 >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> dc5-ipa1.example.com 389 26 >>>>> dc5-ipa2.example.com 389 15 >>>>> dc5-ipa3.example.com 389 17 >>>>> ------------------------------------- >>>>> Node dc2-ipa3 >>>>> ------------------------------------- >>>>> dc3-ipa1.example.com 389 14 >>>>> dc3-ipa2.example.com 389 13 >>>>> dc3-ipa3.example.com 389 12 >>>>> dc3-ipa4.example.com 389 11 >>>>> dc2-ipa1.example.com 389 7 >>>>> dc2-ipa2.example.com 389 6 >>>>> dc2-ipa3.example.com 389 5 >>>>> dc2-ipa4.example.com 389 3 >>>>> dc4-ipa1.example.com 389 18 >>>>> dc4-ipa2.example.com 389 19 >>>>> dc4-ipa3.example.com 389 20 >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa2.example.com 389 25 >>>>> dc1-ipa2.example.com 389 9 >>>>> dc1-ipa3.example.com 389 8 >>>>> dc1-ipa4.example.com 389 4 >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> dc5-ipa1.example.com 389 26 >>>>> dc5-ipa2.example.com 389 15 >>>>> dc5-ipa3.example.com 389 17 >>>>> ------------------------------------- >>>>> Node dc2-ipa4 >>>>> ------------------------------------- >>>>> dc3-ipa1.example.com 389 14 >>>>> dc3-ipa2.example.com 389 13 >>>>> dc3-ipa3.example.com 389 12 >>>>> dc3-ipa4.example.com 389 11 >>>>> dc2-ipa1.example.com 389 7 >>>>> dc2-ipa2.example.com 389 6 >>>>> dc2-ipa3.example.com 389 5 >>>>> dc2-ipa4.example.com 389 3 >>>>> dc4-ipa1.example.com 389 18 >>>>> dc4-ipa2.example.com 389 19 >>>>> dc4-ipa3.example.com 389 20 >>>>> dc4-ipa4.example.com 389 21 >>>>> dc1-ipa1.example.com 389 10 >>>>> dc1-ipa2.example.com 389 25 >>>>> dc1-ipa2.example.com 389 9 >>>>> dc1-ipa3.example.com 389 8 >>>>> dc1-ipa4.example.com 389 4 >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> dc5-ipa1.example.com 389 26 >>>>> dc5-ipa2.example.com 389 15 >>>>> dc5-ipa3.example.com 389 17 >>>>> >>>>> >>>>> Happy Wednesday >>>>> ~Janelle >>>> >>>> >>>> >>> >> >> And just like that - for no reason, they all reappeared: >> >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 23} 5545d61f000200170000 5552f718000300170000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> >> :-( >> ~J >> > Hello Janelle, > > Those 3 RIDs were already present in Node dc2-ipa1, correct ? They > reappeared on others nodes as well ? > May be ds2-ipa1 established a replication session with its peers and > send those RIDs. > Could you track in all the access logs, when the op > csn=5552f718000300170000 was applied. > > Note that the two hexa values of replica 23 changed > (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 > 55543240000300170000). Have you recreated a replica 23 ?. > > Do you have replication logging enabled ? > > thanks > thierry > > As I mentioned in the email I just sent and to be clear - NOTHING changed in the environment. No new replicas. No changes in the servers at all other than some simple add and deletes of users. This just happens randomly. In the process of trying to clean them to get back into production, as it is causing issues, and I need production to run. Back later once I am running again. ~Janelle -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Thu May 21 12:25:38 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 05:25:38 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DCD90.4070306@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> Message-ID: <555DCEC2.40405@gmail.com> On 5/21/15 5:20 AM, thierry bordaz wrote: > Hello Janelle, > > Those 3 RIDs were already present in Node dc2-ipa1, correct ? They > reappeared on others nodes as well ? > May be ds2-ipa1 established a replication session with its peers and > send those RIDs. > Could you track in all the access logs, when the op > csn=5552f718000300170000 was applied. > > Note that the two hexa values of replica 23 changed > (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 > 55543240000300170000). Have you recreated a replica 23 ?. > > Do you have replication logging enabled ? > > thanks > thierry Just to help me -- what is the best way to enable the logging level you need? I thought I did it correctly adding to ldif.dse, but I don't think it took. I am used to OpenLDAP, so perhaps there is a different way to do it with 389-ds. Can you suggest settings of logging you want me to use? ~Janelle From lkrispen at redhat.com Thu May 21 12:47:31 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 14:47:31 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DCD90.4070306@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> Message-ID: <555DD3E3.3070502@redhat.com> On 05/21/2015 02:20 PM, thierry bordaz wrote: > On 05/21/2015 01:36 PM, Janelle wrote: >> >> And just like that - for no reason, they all reappeared: >> >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 23} 5545d61f000200170000 5552f718000300170000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> >> :-( >> ~J >> > Hello Janelle, > > Those 3 RIDs were already present in Node dc2-ipa1, correct ? They > reappeared on others nodes as well ? > May be ds2-ipa1 established a replication session with its peers and > send those RIDs. > Could you track in all the access logs, when the op > csn=5552f718000300170000 was applied. > > Note that the two hexa values of replica 23 changed > (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 > 55543240000300170000). Have you recreated a replica 23 ?. > > Do you have replication logging enabled ? > > thanks > thierry > > > > Hi Thierry, Mark, I have an idea how this can happen, and now I have an environment where these show up. The changelog contains max and purge ruv, and in my changelog I have: dbid: 0000006f000000000000 entry count: 304 dbid: 000000de000000000000 purge ruv: {replicageneration} 51dc3bac000000640000 {replica 100} 5555a759000000640000 5555a759000000640000 {replica 200} 5555b3c2000000c80000 5555b3c2000000c80000 {replica 300} 5555b3c20005012c0000 5555b3c20005012c0000 dbid: 0000014d000000000000 max ruv: {replicageneration} 51dc3bac000000640000 {replica 100} 5555a759000000640000 5555d773000000640000 {replica 200} 5555b3c2000000c80000 5555b3c2000000c80000 {replica 300} 5555b3c20005012c0000 5555b3c20005012c0000 after restarting I got: ldapsearch -LLL -o ldif-wrap=no -h localhost -p 30522 -x -D "cn=directory manager" -w xxxxxx -b "cn=config" "objectclass=nsds5replica" nsds50ruv dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds50ruv: {replicageneration} 51dc3bac000000640000 nsds50ruv: {replica 100 ldap://localhost:30522} 5555a759000000640000 5555d773000000640000 nsds50ruv: {replica 200 ldap://localhost:4945} 5555b3c2000000c80000 5555b3c2000000c80000 nsds50ruv: {replica 300} 5555b3c20005012c0000 5555b3c20005012c0000 replica 300 is corrupted. In this env I had played by cleaning ruv for rid 300, without disabling repl agreements from 300 (which I shoudl have done) and by adding changes later on replica 300 (which I shouldn't). Everything looked fine, just after stopping to dump the changelog and restarting I was in the bad state Need to try to repeat and verify -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu May 21 12:49:00 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 21 May 2015 06:49:00 -0600 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DCEC2.40405@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> Message-ID: <555DD43C.9040402@redhat.com> On 05/21/2015 06:25 AM, Janelle wrote: > On 5/21/15 5:20 AM, thierry bordaz wrote: >> Hello Janelle, >> >> Those 3 RIDs were already present in Node dc2-ipa1, correct ? They >> reappeared on others nodes as well ? >> May be ds2-ipa1 established a replication session with its peers and >> send those RIDs. >> Could you track in all the access logs, when the op >> csn=5552f718000300170000 was applied. >> >> Note that the two hexa values of replica 23 changed >> (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 >> 55543240000300170000). Have you recreated a replica 23 ?. >> >> Do you have replication logging enabled ? >> >> thanks >> thierry > Just to help me -- what is the best way to enable the logging level > you need? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting The Replication log level. > I thought I did it correctly adding to ldif.dse, but I don't think it > took. You cannot edit dse.ldif while the server is running. Anyway, ldapmodify is the best way to set this value. > I am used to OpenLDAP, so perhaps there is a different way to do it > with 389-ds. Can you suggest settings of logging you want me to use? > The Replication log level. > ~Janelle > From janellenicole80 at gmail.com Thu May 21 13:04:24 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 06:04:24 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DD43C.9040402@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> Message-ID: <555DD7D8.6080104@gmail.com> On 5/21/15 5:49 AM, Rich Megginson wrote: > On 05/21/2015 06:25 AM, Janelle wrote: >> On 5/21/15 5:20 AM, thierry bordaz wrote: >>> Hello Janelle, >>> >>> Those 3 RIDs were already present in Node dc2-ipa1, correct ? They >>> reappeared on others nodes as well ? >>> May be ds2-ipa1 established a replication session with its peers and >>> send those RIDs. >>> Could you track in all the access logs, when the op >>> csn=5552f718000300170000 was applied. >>> >>> Note that the two hexa values of replica 23 changed >>> (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 >>> 55543240000300170000). Have you recreated a replica 23 ?. >>> >>> Do you have replication logging enabled ? >>> >>> thanks >>> thierry >> Just to help me -- what is the best way to enable the logging level >> you need? > > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > The Replication log level. > >> I thought I did it correctly adding to ldif.dse, but I don't think it >> took. > > You cannot edit dse.ldif while the server is running. Anyway, > ldapmodify is the best way to set this value. > >> I am used to OpenLDAP, so perhaps there is a different way to do it >> with 389-ds. Can you suggest settings of logging you want me to use? >> > The Replication log level. > >> ~Janelle >> > How do I kill one of the ldapmodify "cleans" I had started but seems to be stuck: CLEANALLRUV tasks RID 24 None No abort CLEANALLRUV tasks running It has been 45 minutes and still nothing, so I want to kill it and try again. ~J From lkrispen at redhat.com Thu May 21 13:15:04 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 15:15:04 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DD7D8.6080104@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> Message-ID: <555DDA58.4050403@redhat.com> On 05/21/2015 03:04 PM, Janelle wrote: > On 5/21/15 5:49 AM, Rich Megginson wrote: >> On 05/21/2015 06:25 AM, Janelle wrote: >>> On 5/21/15 5:20 AM, thierry bordaz wrote: >>>> Hello Janelle, >>>> >>>> Those 3 RIDs were already present in Node dc2-ipa1, correct ? They >>>> reappeared on others nodes as well ? >>>> May be ds2-ipa1 established a replication session with its peers >>>> and send those RIDs. >>>> Could you track in all the access logs, when the op >>>> csn=5552f718000300170000 was applied. >>>> >>>> Note that the two hexa values of replica 23 changed >>>> (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 >>>> 55543240000300170000). Have you recreated a replica 23 ?. >>>> >>>> Do you have replication logging enabled ? >>>> >>>> thanks >>>> thierry >>> Just to help me -- what is the best way to enable the logging level >>> you need? >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting >> The Replication log level. >> >>> I thought I did it correctly adding to ldif.dse, but I don't think >>> it took. >> >> You cannot edit dse.ldif while the server is running. Anyway, >> ldapmodify is the best way to set this value. >> >>> I am used to OpenLDAP, so perhaps there is a different way to do it >>> with 389-ds. Can you suggest settings of logging you want me to use? >>> >> The Replication log level. >> >>> ~Janelle >>> >> > How do I kill one of the ldapmodify "cleans" I had started but seems > to be stuck: abort should be done by ldapmodify similar to starting it: ldapmo |ldapmodify .... dn: cn=abort 222, cn=abort cleanallruv, cn=tasks, cn=config objectclass: extensibleObject cn: abort 222 replica-base-dn: dc=example,dc=com replica-id: 222 replica-certify-all: no --> if set to "no" the task does not wait for all the replica servers to have been sent the abort task, or be online, before completing. If set to "yes", the task will run forever until all the configured replicas have been aborted. Note - the orginal default was "yes", but this was changed to "no" on 4/21/15. It is best to set this attribute anyway, and not rely on what the default is.| if it doesn't work we have to ask Mark :-) > > CLEANALLRUV tasks > RID 24 None > No abort CLEANALLRUV tasks running > > It has been 45 minutes and still nothing, so I want to kill it and try > again. > > ~J > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.boyce at nasa.gov Thu May 21 13:13:26 2015 From: george.boyce at nasa.gov (Boyce, George Robert. (GSFC-762.0)[NICS]) Date: Thu, 21 May 2015 13:13:26 +0000 Subject: [Freeipa-users] confused by ldapsearch results In-Reply-To: <555D7C6D.2090804@redhat.com> References: <642326D3671873428E03A5AB2A1ACF0811B87D7F@NDMSMBX301.ndc.nasa.gov> <555B9C54.6050302@redhat.com> <642326D3671873428E03A5AB2A1ACF0811B89A1D@NDMSMBX301.ndc.nasa.gov> <555D721B.4050902@redhat.com> <555D7C6D.2090804@redhat.com> Message-ID: <642326D3671873428E03A5AB2A1ACF0811B8A9A9@NDMSMBX301.ndc.nasa.gov> Knowing that the first issue is 'working as designed', I can now focus on exactly how to fix it. In my case, the issue is that a vendor's code is appending "name=..." to its search filter to find a user group. Thanks, I can troubleshoot the second issue, it isn't a roadblock to my task. On 05/21/2015 07:50 AM, Martin Kosek wrote: > On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: >> Still the behavior of returning nothing by adding an extra false >> term, > IIRC, this is done on purpose, there was an CVE and as a fix, if you > are querying with an attribute you do not have permission to query > with, you get no answers. correct. It was https://bugzilla.redhat.com/show_bug.cgi?id=979508 and behaviour matches the spec in 13.3.3.3: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Permissions For the other problem, there is not enough information to judge. If two entries are in different subtrees also different acis could apply, we need the full set of acis, the full search and eventuallay access control logging (nsslapd-errorlog-level: 128) From mareynol at redhat.com Thu May 21 13:15:42 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Thu, 21 May 2015 09:15:42 -0400 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DDA58.4050403@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> Message-ID: <555DDA7E.9080704@redhat.com> On 05/21/2015 09:15 AM, Ludwig Krispenz wrote: > > On 05/21/2015 03:04 PM, Janelle wrote: >> On 5/21/15 5:49 AM, Rich Megginson wrote: >>> On 05/21/2015 06:25 AM, Janelle wrote: >>>> On 5/21/15 5:20 AM, thierry bordaz wrote: >>>>> Hello Janelle, >>>>> >>>>> Those 3 RIDs were already present in Node dc2-ipa1, correct ? They >>>>> reappeared on others nodes as well ? >>>>> May be ds2-ipa1 established a replication session with its peers >>>>> and send those RIDs. >>>>> Could you track in all the access logs, when the op >>>>> csn=5552f718000300170000 was applied. >>>>> >>>>> Note that the two hexa values of replica 23 changed >>>>> (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 >>>>> 55543240000300170000). Have you recreated a replica 23 ?. >>>>> >>>>> Do you have replication logging enabled ? >>>>> >>>>> thanks >>>>> thierry >>>> Just to help me -- what is the best way to enable the logging level >>>> you need? >>> >>> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting >>> The Replication log level. >>> >>>> I thought I did it correctly adding to ldif.dse, but I don't think >>>> it took. >>> >>> You cannot edit dse.ldif while the server is running. Anyway, >>> ldapmodify is the best way to set this value. >>> >>>> I am used to OpenLDAP, so perhaps there is a different way to do it >>>> with 389-ds. Can you suggest settings of logging you want me to use? >>>> >>> The Replication log level. >>> >>>> ~Janelle >>>> >>> >> How do I kill one of the ldapmodify "cleans" I had started but seems >> to be stuck: > abort should be done by ldapmodify similar to starting it: > ldapmo > |ldapmodify .... > dn: cn=abort 222, cn=abort cleanallruv, cn=tasks, cn=config > objectclass: extensibleObject > cn: abort 222 > replica-base-dn: dc=example,dc=com > replica-id: 222 > replica-certify-all: no > > --> if set to "no" the task does not wait for all the replica servers to have been sent the abort task, or be online, before completing. If set to "yes", the task will run forever until all the configured replicas have been aborted. Note - the orginal default was "yes", but this was changed to "no" on 4/21/15. It is best to set this attribute anyway, and not rely on what the default is.| > if it doesn't work we have to ask Mark :-) The abort task should work, assuming replica-certify-all is to "no". If there is still a problem you can always monitor the errors log (/var/log/dirsrv/slapd-INSTANCE/errors), and grep for "CleanAllRUV" to sort the output. Mark | | >> >> CLEANALLRUV tasks >> RID 24 None >> No abort CLEANALLRUV tasks running >> >> It has been 45 minutes and still nothing, so I want to kill it and >> try again. >> >> ~J >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.boyce at nasa.gov Thu May 21 13:20:26 2015 From: george.boyce at nasa.gov (Boyce, George Robert. (GSFC-762.0)[NICS]) Date: Thu, 21 May 2015 13:20:26 +0000 Subject: [Freeipa-users] Proper configuration of service accounts In-Reply-To: <555CCB3F.8070303@redhat.com> References: <642326D3671873428E03A5AB2A1ACF0811B89E4A@NDMSMBX301.ndc.nasa.gov> <555CCB3F.8070303@redhat.com> Message-ID: <642326D3671873428E03A5AB2A1ACF0811B8A9C9@NDMSMBX301.ndc.nasa.gov> Rob, << Try adding the inetUser objectclass to your system account. You're probably lacking memberOf. >> Thanks, that worked. My last issue is to add read/search permission on the "name" attribute as the vendor doesn't offer a way to not include it in a search filter to find user groups. << I was in Code 500 many moons ago, Center Network Environment (CNE). >> Small world :-) The NICS contract covers CNE at Goddard and at the Agency level. I'm setting up a new NMS system for the NASCOM mission network. George Boyce, SAIC/NICS GCC Systems Support NASA GSFC Code 762 From janellenicole80 at gmail.com Thu May 21 13:28:27 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 06:28:27 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DDA7E.9080704@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> Message-ID: <555DDD7B.2080003@gmail.com> I think I found the problem. There was a lone replica running in another DC. It was installed as a replica some time ago with all the others. Think of this -- the original config had 5 servers, one of them was this server. Then the other 4 servers were RE-BUILT from scratch, so all the replication agreements were changed AND - this is the important part - the 5th server was never added back in. BUT - the 5th server was left running and never told it that it was not a member anymore. It still thought it had a replication agreement with original "server 1", but server 1 knew otherwise. Now, although the first 4 servers were rebuilt, the same domain, realm, AND passwords were used. I am guessing that somehow, this 5th server keeps trying to interject its info into the ring of 4 servers, kind of forcing its way in. Somehow, because the original credentials still work (but certs are all different) is leaving the first 4 servers with a "can't decode" issue. There should be some security checks so this can't happen. It should also be easy to replicate. Now I have to go re-initialize all the servers from a good server, so everyone is happy again. The "problem" server has been shutdown completely. (and yes, there were actually 3 of them in my scenario - I just used 1 to simplify my example - but that explains the 3 CSNs that just kept "appearing") What concerns me most about this - were the servers outside of the "good ring" somehow able to inject data into replication which might have been causing bad data??? This is bad if it is true. ~Janelle From rcritten at redhat.com Thu May 21 13:33:01 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 May 2015 09:33:01 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <555C8D47.7030306@redhat.com> Message-ID: <555DDE8D.2000107@redhat.com> Sanju A wrote: > Dear Rob, > > Please find the result of getcert list. > > Request ID '20140430124456': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.tcs-mobility.com,O=EXAMPLE.COM > expires: 2016-04-30 12:44:55 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes You need to run getcert list on the IPA master running the CA that can't be contacted, not the host you're trying to delete. rob > > > Regards > Sanju Abraham > > > > > From: Rob Crittenden > To: Sanju A , freeipa-users at redhat.com > Date: 20-05-2015 19:04 > Subject: Re: [Freeipa-users] Certificate operation cannot be completed: > Unable to communicate with CMS (Not Found) > ------------------------------------------------------------------------ > > > > Sanju A wrote: > > Hi, > > > > I am getting the following error while removing a host. > > > > --------------------------------------- > > Certificate operation cannot be completed: Unable to communicate with > > CMS (Not Found) > > --------------------------------------- > > This usually means that the CA is not serving requestss. It may be up > and running but that doesn't mean the webapp is working. > > This is often due to expired CA subsystem certificates. Run getcert list > to check. > > rob > > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > From lkrispen at redhat.com Thu May 21 13:46:59 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 15:46:59 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DDD7B.2080003@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> Message-ID: <555DE1D3.3050501@redhat.com> On 05/21/2015 03:28 PM, Janelle wrote: > I think I found the problem. > > There was a lone replica running in another DC. It was installed as a > replica some time ago with all the others. Think of this -- the > original config had 5 servers, one of them was this server. Then the > other 4 servers were RE-BUILT from scratch, so all the replication > agreements were changed AND - this is the important part - the 5th > server was never added back in. BUT - the 5th server was left running > and never told it that it was not a member anymore. It still thought > it had a replication agreement with original "server 1", but server 1 > knew otherwise. > > Now, although the first 4 servers were rebuilt, the same domain, > realm, AND passwords were used. > > I am guessing that somehow, this 5th server keeps trying to interject > its info into the ring of 4 servers, kind of forcing its way in. > Somehow, because the original credentials still work (but certs are > all different) is leaving the first 4 servers with a "can't decode" > issue. > > There should be some security checks so this can't happen. It should > also be easy to replicate. > > Now I have to go re-initialize all the servers from a good server, so > everyone is happy again. The "problem" server has been shutdown > completely. (and yes, there were actually 3 of them in my scenario - I > just used 1 to simplify my example - but that explains the 3 CSNs that > just kept "appearing") > > What concerns me most about this - were the servers outside of the > "good ring" somehow able to inject data into replication which might > have been causing bad data??? This is bad if it is true. it depends a bit on what you mean by rebuilt from scratch. A replication session needs to meet three conditions to be able to send data: - the supplier side needs to be able to authenticate and the authenticated users has to be in the list of binddns of the replica - the data generation of supplier and consumer side need to be the same (they all have to have the same common origin) - the supplier needs to have the changes (CSNs) to be able to position in its changelog to send updates now if you have 5 servers, forget about one of them and do not change the credentials in the others and do not reinitialize the database by an ldif import to generate a new database generation, the fifth server will still be able to connect and eventually send updates - how should the other servers know that this one is no longer a "good" one > > ~Janelle > From janellenicole80 at gmail.com Thu May 21 13:54:12 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 06:54:12 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DE1D3.3050501@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> <555DE1D3.3050501@redhat.com> Message-ID: <555DE384.6070306@gmail.com> On 5/21/15 6:46 AM, Ludwig Krispenz wrote: > > On 05/21/2015 03:28 PM, Janelle wrote: >> I think I found the problem. >> >> There was a lone replica running in another DC. It was installed as a >> replica some time ago with all the others. Think of this -- the >> original config had 5 servers, one of them was this server. Then the >> other 4 servers were RE-BUILT from scratch, so all the replication >> agreements were changed AND - this is the important part - the 5th >> server was never added back in. BUT - the 5th server was left running >> and never told it that it was not a member anymore. It still thought >> it had a replication agreement with original "server 1", but server 1 >> knew otherwise. >> >> Now, although the first 4 servers were rebuilt, the same domain, >> realm, AND passwords were used. >> >> I am guessing that somehow, this 5th server keeps trying to interject >> its info into the ring of 4 servers, kind of forcing its way in. >> Somehow, because the original credentials still work (but certs are >> all different) is leaving the first 4 servers with a "can't decode" >> issue. >> >> There should be some security checks so this can't happen. It should >> also be easy to replicate. >> >> Now I have to go re-initialize all the servers from a good server, so >> everyone is happy again. The "problem" server has been shutdown >> completely. (and yes, there were actually 3 of them in my scenario - >> I just used 1 to simplify my example - but that explains the 3 CSNs >> that just kept "appearing") >> >> What concerns me most about this - were the servers outside of the >> "good ring" somehow able to inject data into replication which might >> have been causing bad data??? This is bad if it is true. > it depends a bit on what you mean by rebuilt from scratch. > A replication session needs to meet three conditions to be able to > send data: > - the supplier side needs to be able to authenticate and the > authenticated users has to be in the list of binddns of the replica > - the data generation of supplier and consumer side need to be the > same (they all have to have the same common origin) > - the supplier needs to have the changes (CSNs) to be able to position > in its changelog to send updates > > now if you have 5 servers, forget about one of them and do not change > the credentials in the others and do not reinitialize the database by > an ldif import to generate a new database generation, the fifth server > will still be able to connect and eventually send updates - how should > the other servers know that this one is no longer a "good" one >> >> ~Janelle >> > To clarify "rebuilt from scratch": ipa-server-install --uninstall --unattended yum remove 389-ds-* certmonger-* freeipa-* reboot yum install freeipa-server ipa-server-install The reason for the uninstalls is to clear out all "leftover" folders and certs. Also run are: rm -f /var/lib/sss/db/* rm -rf /etc/ipa rm -rf /var/log/dirsrv/ But those are before the re-install. So the 5th server was left running, and yes, the "admin" username and PW are the same, so that may be how it is happening, regardless of certificates being different. ~Janelle From janellenicole80 at gmail.com Thu May 21 13:59:46 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 06:59:46 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DE1D3.3050501@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> <555DE1D3.3050501@redhat.com> Message-ID: <555DE4D2.9050801@gmail.com> On 5/21/15 6:46 AM, Ludwig Krispenz wrote: > > On 05/21/2015 03:28 PM, Janelle wrote: >> I think I found the problem. >> >> There was a lone replica running in another DC. It was installed as a >> replica some time ago with all the others. Think of this -- the >> original config had 5 servers, one of them was this server. Then the >> other 4 servers were RE-BUILT from scratch, so all the replication >> agreements were changed AND - this is the important part - the 5th >> server was never added back in. BUT - the 5th server was left running >> and never told it that it was not a member anymore. It still thought >> it had a replication agreement with original "server 1", but server 1 >> knew otherwise. >> >> Now, although the first 4 servers were rebuilt, the same domain, >> realm, AND passwords were used. >> >> I am guessing that somehow, this 5th server keeps trying to interject >> its info into the ring of 4 servers, kind of forcing its way in. >> Somehow, because the original credentials still work (but certs are >> all different) is leaving the first 4 servers with a "can't decode" >> issue. >> >> There should be some security checks so this can't happen. It should >> also be easy to replicate. >> >> Now I have to go re-initialize all the servers from a good server, so >> everyone is happy again. The "problem" server has been shutdown >> completely. (and yes, there were actually 3 of them in my scenario - >> I just used 1 to simplify my example - but that explains the 3 CSNs >> that just kept "appearing") >> >> What concerns me most about this - were the servers outside of the >> "good ring" somehow able to inject data into replication which might >> have been causing bad data??? This is bad if it is true. > it depends a bit on what you mean by rebuilt from scratch. > A replication session needs to meet three conditions to be able to > send data: > - the supplier side needs to be able to authenticate and the > authenticated users has to be in the list of binddns of the replica > - the data generation of supplier and consumer side need to be the > same (they all have to have the same common origin) > - the supplier needs to have the changes (CSNs) to be able to position > in its changelog to send updates > > now if you have 5 servers, forget about one of them and do not change > the credentials in the others and do not reinitialize the database by > an ldif import to generate a new database generation, the fifth server > will still be able to connect and eventually send updates - how should > the other servers know that this one is no longer a "good" one >> >> ~Janelle >> > The only problem left now - is no matter what, this last entry will NOT go away and now I have 2 "stuck" cleanruvs that will not "abort" either. unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 CLEANALLRUV tasks RID 24 None No abort CLEANALLRUV tasks running ===================================== ldapmodify -D "cn=directory manager" -W -a dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc=example,dc=com cn: abort 24 replica-id: 24 replica-certify-all: no adding new entry " cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config" ldap_add: No such object (32) From rcritten at redhat.com Thu May 21 14:07:55 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 May 2015 10:07:55 -0400 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DE384.6070306@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> <555DE1D3.3050501@redhat.com> <555DE384.6070306@gmail.com> Message-ID: <555DE6BB.5000201@redhat.com> Janelle wrote: > On 5/21/15 6:46 AM, Ludwig Krispenz wrote: >> >> On 05/21/2015 03:28 PM, Janelle wrote: >>> I think I found the problem. >>> >>> There was a lone replica running in another DC. It was installed as a >>> replica some time ago with all the others. Think of this -- the >>> original config had 5 servers, one of them was this server. Then the >>> other 4 servers were RE-BUILT from scratch, so all the replication >>> agreements were changed AND - this is the important part - the 5th >>> server was never added back in. BUT - the 5th server was left running >>> and never told it that it was not a member anymore. It still thought >>> it had a replication agreement with original "server 1", but server 1 >>> knew otherwise. >>> >>> Now, although the first 4 servers were rebuilt, the same domain, >>> realm, AND passwords were used. >>> >>> I am guessing that somehow, this 5th server keeps trying to interject >>> its info into the ring of 4 servers, kind of forcing its way in. >>> Somehow, because the original credentials still work (but certs are >>> all different) is leaving the first 4 servers with a "can't decode" >>> issue. >>> >>> There should be some security checks so this can't happen. It should >>> also be easy to replicate. >>> >>> Now I have to go re-initialize all the servers from a good server, so >>> everyone is happy again. The "problem" server has been shutdown >>> completely. (and yes, there were actually 3 of them in my scenario - >>> I just used 1 to simplify my example - but that explains the 3 CSNs >>> that just kept "appearing") >>> >>> What concerns me most about this - were the servers outside of the >>> "good ring" somehow able to inject data into replication which might >>> have been causing bad data??? This is bad if it is true. >> it depends a bit on what you mean by rebuilt from scratch. >> A replication session needs to meet three conditions to be able to >> send data: >> - the supplier side needs to be able to authenticate and the >> authenticated users has to be in the list of binddns of the replica >> - the data generation of supplier and consumer side need to be the >> same (they all have to have the same common origin) >> - the supplier needs to have the changes (CSNs) to be able to position >> in its changelog to send updates >> >> now if you have 5 servers, forget about one of them and do not change >> the credentials in the others and do not reinitialize the database by >> an ldif import to generate a new database generation, the fifth server >> will still be able to connect and eventually send updates - how should >> the other servers know that this one is no longer a "good" one >>> >>> ~Janelle >>> >> > To clarify "rebuilt from scratch": > > ipa-server-install --uninstall --unattended > yum remove 389-ds-* certmonger-* freeipa-* > reboot > yum install freeipa-server > ipa-server-install > > The reason for the uninstalls is to clear out all "leftover" folders and > certs. > Also run are: > rm -f /var/lib/sss/db/* > rm -rf /etc/ipa > rm -rf /var/log/dirsrv/ > > But those are before the re-install. > > So the 5th server was left running, and yes, the "admin" username and PW > are the same, so that may be how it is happening, regardless of > certificates being different. The certs don't matter as replication doesn't use TLS and doesn't use simple bind. It uses GSSAPI, so any connection still should have failed because the keys wouldn't match, if they existed at all. So I'd look for BIND from this master in the access logs of the re-installed ones. rob From christoph.kaminski at biotronik.com Thu May 21 15:04:05 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Thu, 21 May 2015 17:04:05 +0200 Subject: [Freeipa-users] Count of IPA Servers for SSSD Message-ID: Hi All what a count of IPA servers does make sense for sssd configuration? We have 5 IPA servers and each Host can reach them. Can I put them all to sssd configuration (redundancy) or does it dont make sense (timeouts to big etc)? MfG Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Thu May 21 15:12:27 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 May 2015 17:12:27 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DE4D2.9050801@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> <555DE1D3.3050501@redhat.com> <555DE4D2.9050801@gmail.com> Message-ID: <555DF5DB.5030800@redhat.com> On 05/21/2015 03:59 PM, Janelle wrote: > On 5/21/15 6:46 AM, Ludwig Krispenz wrote: >> >> On 05/21/2015 03:28 PM, Janelle wrote: >>> I think I found the problem. >>> >>> There was a lone replica running in another DC. It was installed as >>> a replica some time ago with all the others. Think of this -- the >>> original config had 5 servers, one of them was this server. Then the >>> other 4 servers were RE-BUILT from scratch, so all the replication >>> agreements were changed AND - this is the important part - the 5th >>> server was never added back in. BUT - the 5th server was left >>> running and never told it that it was not a member anymore. It still >>> thought it had a replication agreement with original "server 1", but >>> server 1 knew otherwise. >>> >>> Now, although the first 4 servers were rebuilt, the same domain, >>> realm, AND passwords were used. >>> >>> I am guessing that somehow, this 5th server keeps trying to >>> interject its info into the ring of 4 servers, kind of forcing its >>> way in. Somehow, because the original credentials still work (but >>> certs are all different) is leaving the first 4 servers with a >>> "can't decode" issue. >>> >>> There should be some security checks so this can't happen. It should >>> also be easy to replicate. >>> >>> Now I have to go re-initialize all the servers from a good server, >>> so everyone is happy again. The "problem" server has been shutdown >>> completely. (and yes, there were actually 3 of them in my scenario - >>> I just used 1 to simplify my example - but that explains the 3 CSNs >>> that just kept "appearing") >>> >>> What concerns me most about this - were the servers outside of the >>> "good ring" somehow able to inject data into replication which might >>> have been causing bad data??? This is bad if it is true. >> it depends a bit on what you mean by rebuilt from scratch. >> A replication session needs to meet three conditions to be able to >> send data: >> - the supplier side needs to be able to authenticate and the >> authenticated users has to be in the list of binddns of the replica >> - the data generation of supplier and consumer side need to be the >> same (they all have to have the same common origin) >> - the supplier needs to have the changes (CSNs) to be able to >> position in its changelog to send updates >> >> now if you have 5 servers, forget about one of them and do not change >> the credentials in the others and do not reinitialize the database by >> an ldif import to generate a new database generation, the fifth >> server will still be able to connect and eventually send updates - >> how should the other servers know that this one is no longer a "good" >> one >>> >>> ~Janelle >>> >> > The only problem left now - is no matter what, this last entry will > NOT go away and now I have 2 "stuck" cleanruvs that will not "abort" > either. > > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > > CLEANALLRUV tasks > RID 24 None > No abort CLEANALLRUV tasks running > ===================================== > > ldapmodify -D "cn=directory manager" -W -a > > dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config > objectclass: extensibleObject > replica-base-dn: dc=example,dc=com > cn: abort 24 > replica-id: 24 > replica-certify-all: no > adding new entry " cn=abort 24, cn=abort cleanallruv, cn=tasks, > cn=config" > ldap_add: No such object (32) in your dse.ldif do you see something like: nsds5ReplicaCleanRUV: 300:00000000000000000000:no in the replica object ? This is where the task lives as long as it couldn't reach all servers for which a replication agreement exists. If abort task doesn't work, you could try to stop the server, remove these lines from the dse.ldif, start the server again. From rcritten at redhat.com Thu May 21 15:24:50 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 May 2015 11:24:50 -0400 Subject: [Freeipa-users] Count of IPA Servers for SSSD In-Reply-To: References: Message-ID: <555DF8C2.2050504@redhat.com> Christoph Kaminski wrote: > Hi All > > what a count of IPA servers does make sense for sssd configuration? We > have 5 IPA servers and each Host can reach them. Can I put them all to > sssd configuration (redundancy) or does it dont make sense (timeouts to > big etc)? The recommended procedure is to use DNS SRV records. SSSD will automatically fail over using them. This has the advantage that if you add/remove some IPA masters you don't have to go and change every single sssd.conf. rob From janellenicole80 at gmail.com Thu May 21 16:09:59 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 21 May 2015 09:09:59 -0700 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DF5DB.5030800@redhat.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> <555DE1D3.3050501@redhat.com> <555DE4D2.9050801@gmail.com> <555DF5DB.5030800@redhat.com> Message-ID: <555E0357.3030500@gmail.com> On 5/21/15 8:12 AM, Ludwig Krispenz wrote: > > On 05/21/2015 03:59 PM, Janelle wrote: >> On 5/21/15 6:46 AM, Ludwig Krispenz wrote: >>> >>> On 05/21/2015 03:28 PM, Janelle wrote: >>>> I think I found the problem. >>>> >>>> There was a lone replica running in another DC. It was installed as >>>> a replica some time ago with all the others. Think of this -- the >>>> original config had 5 servers, one of them was this server. Then >>>> the other 4 servers were RE-BUILT from scratch, so all the >>>> replication agreements were changed AND - this is the important >>>> part - the 5th server was never added back in. BUT - the 5th server >>>> was left running and never told it that it was not a member >>>> anymore. It still thought it had a replication agreement with >>>> original "server 1", but server 1 knew otherwise. >>>> >>>> Now, although the first 4 servers were rebuilt, the same domain, >>>> realm, AND passwords were used. >>>> >>>> I am guessing that somehow, this 5th server keeps trying to >>>> interject its info into the ring of 4 servers, kind of forcing its >>>> way in. Somehow, because the original credentials still work (but >>>> certs are all different) is leaving the first 4 servers with a >>>> "can't decode" issue. >>>> >>>> There should be some security checks so this can't happen. It >>>> should also be easy to replicate. >>>> >>>> Now I have to go re-initialize all the servers from a good server, >>>> so everyone is happy again. The "problem" server has been shutdown >>>> completely. (and yes, there were actually 3 of them in my scenario >>>> - I just used 1 to simplify my example - but that explains the 3 >>>> CSNs that just kept "appearing") >>>> >>>> What concerns me most about this - were the servers outside of the >>>> "good ring" somehow able to inject data into replication which >>>> might have been causing bad data??? This is bad if it is true. >>> it depends a bit on what you mean by rebuilt from scratch. >>> A replication session needs to meet three conditions to be able to >>> send data: >>> - the supplier side needs to be able to authenticate and the >>> authenticated users has to be in the list of binddns of the replica >>> - the data generation of supplier and consumer side need to be the >>> same (they all have to have the same common origin) >>> - the supplier needs to have the changes (CSNs) to be able to >>> position in its changelog to send updates >>> >>> now if you have 5 servers, forget about one of them and do not >>> change the credentials in the others and do not reinitialize the >>> database by an ldif import to generate a new database generation, >>> the fifth server will still be able to connect and eventually send >>> updates - how should the other servers know that this one is no >>> longer a "good" one >>>> >>>> ~Janelle >>>> >>> >> The only problem left now - is no matter what, this last entry will >> NOT go away and now I have 2 "stuck" cleanruvs that will not "abort" >> either. >> >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> >> CLEANALLRUV tasks >> RID 24 None >> No abort CLEANALLRUV tasks running >> ===================================== >> >> ldapmodify -D "cn=directory manager" -W -a >> >> dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config >> objectclass: extensibleObject >> replica-base-dn: dc=example,dc=com >> cn: abort 24 >> replica-id: 24 >> replica-certify-all: no >> adding new entry " cn=abort 24, cn=abort cleanallruv, cn=tasks, >> cn=config" >> ldap_add: No such object (32) > in your dse.ldif do you see something like: > > nsds5ReplicaCleanRUV: 300:00000000000000000000:no > in the replica object ? > This is where the task lives as long as it couldn't reach all servers > for which a replication agreement exists. > > If abort task doesn't work, you could try to stop the server, remove > these lines from the dse.ldif, start the server again Sadly, nothing even close to that anywhere. And now, after trying to remove another replica which had been showing as a duplicate, although authentication is continuing to work, I am afraid to try and do anything else to replication, for fear of bringing all of production down. I did not notice this at first - but yesterday when I shared my RUVs -- there was something I missed: dc1-ipa1.example.com 389 10 dc1-ipa2.example.com 389 25 dc1-ipa2.example.com 389 9 dc1-ipa3.example.com 389 8 dc1-ipa4.example.com 389 4 ipa2 appears twice with RUV 9 and 25 - with no explanation. Frustrated. ~Janelle From mareynol at redhat.com Thu May 21 17:10:38 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Thu, 21 May 2015 13:10:38 -0400 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555DE4D2.9050801@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> <555DE1D3.3050501@redhat.com> <555DE4D2.9050801@gmail.com> Message-ID: <555E118E.8000702@redhat.com> On 05/21/2015 09:59 AM, Janelle wrote: > On 5/21/15 6:46 AM, Ludwig Krispenz wrote: >> >> On 05/21/2015 03:28 PM, Janelle wrote: >>> I think I found the problem. >>> >>> There was a lone replica running in another DC. It was installed as >>> a replica some time ago with all the others. Think of this -- the >>> original config had 5 servers, one of them was this server. Then the >>> other 4 servers were RE-BUILT from scratch, so all the replication >>> agreements were changed AND - this is the important part - the 5th >>> server was never added back in. BUT - the 5th server was left >>> running and never told it that it was not a member anymore. It still >>> thought it had a replication agreement with original "server 1", but >>> server 1 knew otherwise. >>> >>> Now, although the first 4 servers were rebuilt, the same domain, >>> realm, AND passwords were used. >>> >>> I am guessing that somehow, this 5th server keeps trying to >>> interject its info into the ring of 4 servers, kind of forcing its >>> way in. Somehow, because the original credentials still work (but >>> certs are all different) is leaving the first 4 servers with a >>> "can't decode" issue. >>> >>> There should be some security checks so this can't happen. It should >>> also be easy to replicate. >>> >>> Now I have to go re-initialize all the servers from a good server, >>> so everyone is happy again. The "problem" server has been shutdown >>> completely. (and yes, there were actually 3 of them in my scenario - >>> I just used 1 to simplify my example - but that explains the 3 CSNs >>> that just kept "appearing") >>> >>> What concerns me most about this - were the servers outside of the >>> "good ring" somehow able to inject data into replication which might >>> have been causing bad data??? This is bad if it is true. >> it depends a bit on what you mean by rebuilt from scratch. >> A replication session needs to meet three conditions to be able to >> send data: >> - the supplier side needs to be able to authenticate and the >> authenticated users has to be in the list of binddns of the replica >> - the data generation of supplier and consumer side need to be the >> same (they all have to have the same common origin) >> - the supplier needs to have the changes (CSNs) to be able to >> position in its changelog to send updates >> >> now if you have 5 servers, forget about one of them and do not change >> the credentials in the others and do not reinitialize the database by >> an ldif import to generate a new database generation, the fifth >> server will still be able to connect and eventually send updates - >> how should the other servers know that this one is no longer a "good" >> one >>> >>> ~Janelle >>> >> > The only problem left now - is no matter what, this last entry will > NOT go away and now I have 2 "stuck" cleanruvs that will not "abort" > either. > > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > > CLEANALLRUV tasks > RID 24 None > No abort CLEANALLRUV tasks running > ===================================== > > ldapmodify -D "cn=directory manager" -W -a > > dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config > objectclass: extensibleObject > replica-base-dn: dc=example,dc=com > cn: abort 24 > replica-id: 24 > replica-certify-all: no > adding new entry *" cn=abort 24, cn=abort cleanallruv, cn=tasks, > cn=config" * > ldap_add: No such object (32) There should not be a white space at the beginning: *" cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config" ** * When I run the abort task I don't have that extra white space, and the task is successfully added: [root at localhost ~]# ldapmodify -D cn=dm -w password -a dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc=example,dc=com cn: abort 24 replica-id: 24 replica-certify-all: no adding new entry *"cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config"* The extra white space is the probable cause of the error 32 (no such object) you were seeing. You can verify this by looking at the access log (/var/log/dirsrv/slapd-INSTANCE/access) Like I said before you could also check the errors log for the reason why the cleanAllRUV task is not completing as well. Regards, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.1209 at yahoo.com Thu May 21 21:54:14 2015 From: john.1209 at yahoo.com (John Williams) Date: Thu, 21 May 2015 21:54:14 +0000 (UTC) Subject: [Freeipa-users] User Can't Authenticate Message-ID: <1557638601.5865.1432245254174.JavaMail.yahoo@mail.yahoo.com> I've got a freeIPA client where a user account cannot authenticate. The log entry for IPA looks like: audit/audit.log.4:type=USER_AUTH msg=audit(1425316592.375:38090): user pid=16485 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="aswanda" exe="/usr/sbin/sshd" hostname=172.31.0.162 addr=172.31.0.162 terminal=ssh res=failed' When I try to sudo to the user account, I get the following error: [root at myhost ~]# sudo su - testusersu: user testuser does not exist However, all that works for my account. Please help. ?Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu May 21 22:56:42 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 21 May 2015 18:56:42 -0400 Subject: [Freeipa-users] User Can't Authenticate In-Reply-To: <1557638601.5865.1432245254174.JavaMail.yahoo@mail.yahoo.com> References: <1557638601.5865.1432245254174.JavaMail.yahoo@mail.yahoo.com> Message-ID: <555E62AA.5070502@redhat.com> On 05/21/2015 05:54 PM, John Williams wrote: > I've got a freeIPA client where a user account cannot authenticate. > > The log entry for IPA looks like: > > audit/audit.log.4:type=USER_AUTH msg=audit(1425316592.375:38090): user > pid=16485 uid=0 auid=4294967295 ses=4294967295 > subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 > msg='op=PAM:authentication acct="aswanda" exe="/usr/sbin/sshd" > hostname=172.31.0.162 addr=172.31.0.162 terminal=ssh res=failed' > > When I try to sudo to the user account, I get the following error: > > [root at myhost ~]# sudo su - testuser > su: user testuser does not exist > > However, all that works for my account. > > Please help. Thanks in advance. > > > What do you use on the client? SSSD? What is the OS version? What SSSD logs show? -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Fri May 22 01:35:48 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 22 May 2015 01:35:48 +0000 Subject: [Freeipa-users] disable unwanted kerberos encryption types Message-ID: <39d250403d4c477c821bd0d5392318f4@TCCCORPEXCH02.TCC.local> We have requirements to only allow AES encryption. I'm trying to understand what is the default and where everything comes in to play, the user tickets are AES when obtained using kinit, but the system keytab shows des3 and arcfour in addition to AES. So my questions are What is enabled/supported by default? How can des3 and arcfour encryption types be disabled for Kerberos? ? I've seen references to krbDefaultEncSaltTypes but cannot seem to find that in the directory anywhere. Are there any implications to doing this? Running RHEL 6.6 clients against 7.1 servers supporting local and trusted AD users. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From lslebodn at redhat.com Fri May 22 07:15:43 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 22 May 2015 09:15:43 +0200 Subject: [Freeipa-users] User Can't Authenticate In-Reply-To: <555E62AA.5070502@redhat.com> References: <1557638601.5865.1432245254174.JavaMail.yahoo@mail.yahoo.com> <555E62AA.5070502@redhat.com> Message-ID: <20150522071542.GA17334@mail.corp.redhat.com> On (21/05/15 18:56), Dmitri Pal wrote: >On 05/21/2015 05:54 PM, John Williams wrote: >>I've got a freeIPA client where a user account cannot authenticate. >> >>The log entry for IPA looks like: >> >>audit/audit.log.4:type=USER_AUTH msg=audit(1425316592.375:38090): user >>pid=16485 uid=0 auid=4294967295 ses=4294967295 >>subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication >>acct="aswanda" exe="/usr/sbin/sshd" hostname=172.31.0.162 addr=172.31.0.162 >>terminal=ssh res=failed' >> >>When I try to sudo to the user account, I get the following error: >> >>[root at myhost ~]# sudo su - testuser >>su: user testuser does not exist >> >>However, all that works for my account. >> >>Please help. Thanks in advance. >> >> >> >What do you use on the client? SSSD? >What is the OS version? >What SSSD logs show? > For sssd related issues see https://fedorahosted.org/sssd/wiki/Troubleshooting Firstly, ensure you can get user information (getent passwd user) Secondly, troubleshoot authentication and access control. LS From tbordaz at redhat.com Fri May 22 07:59:14 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 22 May 2015 09:59:14 +0200 Subject: [Freeipa-users] replication again :-( In-Reply-To: <555E0357.3030500@gmail.com> References: <555A9083.5010804@gmail.com> <555A9510.6040403@gmail.com> <555AE069.4010901@redhat.com> <555BDBE1.8060604@gmail.com> <555C85B6.2050104@redhat.com> <555C9049.70607@gmail.com> <555C976E.30202@redhat.com> <555CA000.4030208@redhat.com> <555DC320.30203@gmail.com> <555DCD90.4070306@redhat.com> <555DCEC2.40405@gmail.com> <555DD43C.9040402@redhat.com> <555DD7D8.6080104@gmail.com> <555DDA58.4050403@redhat.com> <555DDA7E.9080704@redhat.com> <555DDD7B.2080003@gmail.com> <555DE1D3.3050501@redhat.com> <555DE4D2.9050801@gmail.com> <555DF5DB.5030800@redhat.com> <555E0357.3030500@gmail.com> Message-ID: <555EE1D2.4080708@redhat.com> On 05/21/2015 06:09 PM, Janelle wrote: > On 5/21/15 8:12 AM, Ludwig Krispenz wrote: >> >> On 05/21/2015 03:59 PM, Janelle wrote: >>> On 5/21/15 6:46 AM, Ludwig Krispenz wrote: >>>> >>>> On 05/21/2015 03:28 PM, Janelle wrote: >>>>> I think I found the problem. >>>>> >>>>> There was a lone replica running in another DC. It was installed >>>>> as a replica some time ago with all the others. Think of this -- >>>>> the original config had 5 servers, one of them was this server. >>>>> Then the other 4 servers were RE-BUILT from scratch, so all the >>>>> replication agreements were changed AND - this is the important >>>>> part - the 5th server was never added back in. BUT - the 5th >>>>> server was left running and never told it that it was not a member >>>>> anymore. It still thought it had a replication agreement with >>>>> original "server 1", but server 1 knew otherwise. >>>>> >>>>> Now, although the first 4 servers were rebuilt, the same domain, >>>>> realm, AND passwords were used. >>>>> >>>>> I am guessing that somehow, this 5th server keeps trying to >>>>> interject its info into the ring of 4 servers, kind of forcing its >>>>> way in. Somehow, because the original credentials still work (but >>>>> certs are all different) is leaving the first 4 servers with a >>>>> "can't decode" issue. >>>>> >>>>> There should be some security checks so this can't happen. It >>>>> should also be easy to replicate. >>>>> >>>>> Now I have to go re-initialize all the servers from a good server, >>>>> so everyone is happy again. The "problem" server has been shutdown >>>>> completely. (and yes, there were actually 3 of them in my scenario >>>>> - I just used 1 to simplify my example - but that explains the 3 >>>>> CSNs that just kept "appearing") >>>>> >>>>> What concerns me most about this - were the servers outside of the >>>>> "good ring" somehow able to inject data into replication which >>>>> might have been causing bad data??? This is bad if it is true. >>>> it depends a bit on what you mean by rebuilt from scratch. >>>> A replication session needs to meet three conditions to be able to >>>> send data: >>>> - the supplier side needs to be able to authenticate and the >>>> authenticated users has to be in the list of binddns of the replica >>>> - the data generation of supplier and consumer side need to be the >>>> same (they all have to have the same common origin) >>>> - the supplier needs to have the changes (CSNs) to be able to >>>> position in its changelog to send updates >>>> >>>> now if you have 5 servers, forget about one of them and do not >>>> change the credentials in the others and do not reinitialize the >>>> database by an ldif import to generate a new database generation, >>>> the fifth server will still be able to connect and eventually send >>>> updates - how should the other servers know that this one is no >>>> longer a "good" one >>>>> >>>>> ~Janelle >>>>> >>>> >>> The only problem left now - is no matter what, this last entry will >>> NOT go away and now I have 2 "stuck" cleanruvs that will not "abort" >>> either. >>> >>> unable to decode {replica 24} 554d53d3000000180000 >>> 554d54a4000200180000 >>> >>> CLEANALLRUV tasks >>> RID 24 None >>> No abort CLEANALLRUV tasks running >>> ===================================== >>> >>> ldapmodify -D "cn=directory manager" -W -a >>> >>> dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config >>> objectclass: extensibleObject >>> replica-base-dn: dc=example,dc=com >>> cn: abort 24 >>> replica-id: 24 >>> replica-certify-all: no >>> adding new entry " cn=abort 24, cn=abort cleanallruv, cn=tasks, >>> cn=config" >>> ldap_add: No such object (32) >> in your dse.ldif do you see something like: >> >> nsds5ReplicaCleanRUV: 300:00000000000000000000:no >> in the replica object ? >> This is where the task lives as long as it couldn't reach all servers >> for which a replication agreement exists. >> >> If abort task doesn't work, you could try to stop the server, remove >> these lines from the dse.ldif, start the server again > > Sadly, nothing even close to that anywhere. And now, after trying to > remove another replica which had been showing as a duplicate, although > authentication is continuing to work, I am afraid to try and do > anything else to replication, for fear of bringing all of production > down. > > I did not notice this at first - but yesterday when I shared my RUVs > -- there was something I missed: > > dc1-ipa1.example.com 389 10 > dc1-ipa2.example.com 389 25 > dc1-ipa2.example.com 389 9 > dc1-ipa3.example.com 389 8 > dc1-ipa4.example.com 389 4 > > ipa2 appears twice with RUV 9 and 25 - with no explanation. > > Frustrated. > ~Janelle > Hi Janelle, Yes I mentioned that duplicate yesterday. That means the node dc1-ipa2.example.com is a master and use to be known with RID 9 and now is known as RID 25 (or the opposite) Did you reinstall that node ? The purpose of CleanAllRuv is to clear the old value from the RUV. Editing dc1-ipa2.example.com dse.ldif you can confirm the current value and choose which one need to be cleared. When you have duplicated RID you may see logs with 'attrlist_replace:..." in the error logs Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanju.a at tcs.com Fri May 22 09:32:40 2015 From: sanju.a at tcs.com (Sanju A) Date: Fri, 22 May 2015 15:02:40 +0530 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <555DDE8D.2000107@redhat.com> References: <555C8D47.7030306@redhat.com> <555DDE8D.2000107@redhat.com> Message-ID: Dear Rob, The result is from ipa master server. Regards Sanju Abraham From: Rob Crittenden To: Sanju A Cc: freeipa-users at redhat.com Date: 21-05-2015 19:03 Subject: Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Sanju A wrote: > Dear Rob, > > Please find the result of getcert list. > > Request ID '20140430124456': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.tcs-mobility.com,O=EXAMPLE.COM > expires: 2016-04-30 12:44:55 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes You need to run getcert list on the IPA master running the CA that can't be contacted, not the host you're trying to delete. rob > > > Regards > Sanju Abraham > > > > > From: Rob Crittenden > To: Sanju A , freeipa-users at redhat.com > Date: 20-05-2015 19:04 > Subject: Re: [Freeipa-users] Certificate operation cannot be completed: > Unable to communicate with CMS (Not Found) > ------------------------------------------------------------------------ > > > > Sanju A wrote: > > Hi, > > > > I am getting the following error while removing a host. > > > > --------------------------------------- > > Certificate operation cannot be completed: Unable to communicate with > > CMS (Not Found) > > --------------------------------------- > > This usually means that the CA is not serving requestss. It may be up > and running but that doesn't mean the webapp is working. > > This is often due to expired CA subsystem certificates. Run getcert list > to check. > > rob > > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri May 22 12:56:44 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 May 2015 08:56:44 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <555C8D47.7030306@redhat.com> <555DDE8D.2000107@redhat.com> Message-ID: <555F278C.30901@redhat.com> Sanju A wrote: > Dear Rob, > > The result is from ipa master server. Ok, then this can't be the entire output. For a master with a CA there should be about 8 certs tracked rob > > > Regards > Sanju Abraham > > > > From: Rob Crittenden > To: Sanju A > Cc: freeipa-users at redhat.com > Date: 21-05-2015 19:03 > Subject: Re: [Freeipa-users] Certificate operation cannot be completed: > Unable to communicate with CMS (Not Found) > ------------------------------------------------------------------------ > > > > Sanju A wrote: > > Dear Rob, > > > > Please find the result of getcert list. > > > > Request ID '20140430124456': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > subject: CN=ipa.tcs-mobility.com,O=EXAMPLE.COM > > expires: 2016-04-30 12:44:55 UTC > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > You need to run getcert list on the IPA master running the CA that can't > be contacted, not the host you're trying to delete. > > rob > > > > > > > Regards > > Sanju Abraham > > > > > > > > > > From: Rob Crittenden > > To: Sanju A , freeipa-users at redhat.com > > Date: 20-05-2015 19:04 > > Subject: Re: [Freeipa-users] Certificate operation cannot be completed: > > Unable to communicate with CMS (Not Found) > > ------------------------------------------------------------------------ > > > > > > > > Sanju A wrote: > > > Hi, > > > > > > I am getting the following error while removing a host. > > > > > > --------------------------------------- > > > Certificate operation cannot be completed: Unable to communicate with > > > CMS (Not Found) > > > --------------------------------------- > > > > This usually means that the CA is not serving requestss. It may be up > > and running but that doesn't mean the webapp is working. > > > > This is often due to expired CA subsystem certificates. Run getcert list > > to check. > > > > rob > > > > > > =====-----=====-----===== > > Notice: The information contained in this e-mail > > message and/or attachments to it may contain > > confidential or privileged information. If you are > > not the intended recipient, any dissemination, use, > > review, distribution, printing or copying of the > > information contained in this e-mail message > > and/or attachments to it are strictly prohibited. If > > you have received this communication in error, > > please notify us by reply e-mail or telephone and > > immediately and permanently delete the message > > and any attachments. Thank you > > > > From nikola at krzalic.com Fri May 22 07:37:04 2015 From: nikola at krzalic.com (=?UTF-8?B?Tmlrb2xhIEtyxb5hbGnEhw==?=) Date: Fri, 22 May 2015 09:37:04 +0200 Subject: [Freeipa-users] FreeIPA groups not shown on client Message-ID: I have a ubuntu system running IPA client. I am able to log in via ssh using IPA users, but I do not get any group memberships or sudo rules. Same configuration works on a different system (running CentOS). sssd domain log output shows that the groups are retrieved from server successfully: (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [ipausers] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [editors] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [trust admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [devops_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [dev_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [sys_team] for user [nkrzalic] However, these groups are not shown on the user upon login: nkrzalic at ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic) I tried cleaning sssd cache but that didn't help. sssd conf is as follows: [sssd] services = nss, pam, ssh, sudo config_file_version = 2 nsswitch.conf seems to be correct as well: # /etc/nsswitch.conf passwd: compat sss group: compat sss shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis sss sudoers: files sss Interestingly after I do "getent group devops_team" this group shows up: nkrzalic at ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic),281200001(devops_team) nkrzalic at ircsrv1:~$ Any ideas? -- Regards, Nikola Kr?ali?. From jhrozek at redhat.com Fri May 22 13:11:13 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 22 May 2015 15:11:13 +0200 Subject: [Freeipa-users] FreeIPA groups not shown on client In-Reply-To: References: Message-ID: <20150522131113.GW4381@hendrix.redhat.com> On Fri, May 22, 2015 at 09:37:04AM +0200, Nikola Kr?ali? wrote: > I have a ubuntu system running IPA client. I am able to log in via ssh > using IPA users, but I do not get any group memberships or sudo rules. > Same configuration works on a different system (running CentOS). > > sssd domain log output shows that the groups are retrieved from server > successfully: > > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [admins] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [ipausers] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [editors] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [trust admins] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [devops_team] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [dev_team] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [sys_team] for user [nkrzalic] Is anything else in the logs? What server version are you running? I guess you might be hitting the derefernce bug that appeared after IPA tightened its ACIs; https://fedorahosted.org/sssd/ticket/2421 From sanju.a at tcs.com Fri May 22 13:16:48 2015 From: sanju.a at tcs.com (Sanju A) Date: Fri, 22 May 2015 18:46:48 +0530 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <555F278C.30901@redhat.com> References: <555C8D47.7030306@redhat.com> <555DDE8D.2000107@redhat.com> <555F278C.30901@redhat.com> Message-ID: Dear Rob, Please find the entire result. ------------------------------------------------------------------------------------------------- Number of certificates and requests being tracked: 8. Request ID '20140430124246': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=CA Audit,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:02 UTC key usage: digitalSignature,nonRepudiation pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124247': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=OCSP Subsystem,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:01 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124248': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=CA Subsystem,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124249': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=IPA RA,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:45 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124250': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=ipa.mydomainname.com,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124308': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-TCS-MOBILITY-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-TCS-MOBILITY-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-TCS-MOBILITY-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=ipa.mydomainname.com,O=MYDOMAINNAME.COM expires: 2016-04-30 12:43:07 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124352': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=mydomainname.com,O=MYDOMAINNAME.COM expires: 2016-04-30 12:43:51 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124456': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=ipa.mydomainname.com,O=MYDOMAINNAME.COM expires: 2016-04-30 12:44:55 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes ------------------------------------------------------------------------------------------------- Regards Sanju Abraham From: Rob Crittenden To: Sanju A Cc: freeipa-users at redhat.com Date: 22-05-2015 18:26 Subject: Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Sanju A wrote: > Dear Rob, > > The result is from ipa master server. Ok, then this can't be the entire output. For a master with a CA there should be about 8 certs tracked rob > > > Regards > Sanju Abraham > > > > From: Rob Crittenden > To: Sanju A > Cc: freeipa-users at redhat.com > Date: 21-05-2015 19:03 > Subject: Re: [Freeipa-users] Certificate operation cannot be completed: > Unable to communicate with CMS (Not Found) > ------------------------------------------------------------------------ > > > > Sanju A wrote: > > Dear Rob, > > > > Please find the result of getcert list. > > > > Request ID '20140430124456': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > subject: CN=ipa.tcs-mobility.com,O=EXAMPLE.COM > > expires: 2016-04-30 12:44:55 UTC > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > You need to run getcert list on the IPA master running the CA that can't > be contacted, not the host you're trying to delete. > > rob > > > > > > > Regards > > Sanju Abraham > > > > > > > > > > From: Rob Crittenden > > To: Sanju A , freeipa-users at redhat.com > > Date: 20-05-2015 19:04 > > Subject: Re: [Freeipa-users] Certificate operation cannot be completed: > > Unable to communicate with CMS (Not Found) > > ------------------------------------------------------------------------ > > > > > > > > Sanju A wrote: > > > Hi, > > > > > > I am getting the following error while removing a host. > > > > > > --------------------------------------- > > > Certificate operation cannot be completed: Unable to communicate with > > > CMS (Not Found) > > > --------------------------------------- > > > > This usually means that the CA is not serving requestss. It may be up > > and running but that doesn't mean the webapp is working. > > > > This is often due to expired CA subsystem certificates. Run getcert list > > to check. > > > > rob > > > > > > =====-----=====-----===== > > Notice: The information contained in this e-mail > > message and/or attachments to it may contain > > confidential or privileged information. If you are > > not the intended recipient, any dissemination, use, > > review, distribution, printing or copying of the > > information contained in this e-mail message > > and/or attachments to it are strictly prohibited. If > > you have received this communication in error, > > please notify us by reply e-mail or telephone and > > immediately and permanently delete the message > > and any attachments. Thank you > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri May 22 13:34:45 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 May 2015 09:34:45 -0400 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: References: <555C8D47.7030306@redhat.com> <555DDE8D.2000107@redhat.com> <555F278C.30901@redhat.com> Message-ID: <555F3075.6090905@redhat.com> Sanju A wrote: > Dear Rob, > > Please find the entire result. Ok, the good news is that renewal already took place and it looks like everything is a-ok certificate-wise. First, make sure the CA is up: # ipactl status If the CA is down, start it with service pki-cad start. If the CA is up, the next thing to check are the trust flags: # certutil -L -d /var/lib/pki-ca/alias The auditSigningCert should be u,u,Pu If it isn't, fix it with: # certutil -M -t u,u,Pu -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' You'll need to restart the CA after changing the trust: # service pki-cad restart If the trust is ok and the CA was already up we'd need to see your CA logs to try to determine what is going on. rob From lslebodn at redhat.com Fri May 22 14:26:12 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 22 May 2015 16:26:12 +0200 Subject: [Freeipa-users] FreeIPA groups not shown on client In-Reply-To: References: Message-ID: <20150522142611.GF17334@mail.corp.redhat.com> On (22/05/15 09:37), Nikola Kr?ali? wrote: >I have a ubuntu system running IPA client. I am able to log in via ssh >using IPA users, but I do not get any group memberships or sudo rules. >Same configuration works on a different system (running CentOS). > >sssd domain log output shows that the groups are retrieved from server >successfully: > >(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >(0x1000): Added group [admins] for user [nkrzalic] >(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >(0x1000): Added group [ipausers] for user [nkrzalic] >(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >(0x1000): Added group [editors] for user [nkrzalic] >(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >(0x1000): Added group [trust admins] for user [nkrzalic] >(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >(0x1000): Added group [devops_team] for user [nkrzalic] >(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >(0x1000): Added group [dev_team] for user [nkrzalic] >(Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >(0x1000): Added group [sys_team] for user [nkrzalic] > >However, these groups are not shown on the user upon login: > >nkrzalic at ircsrv1:~$ id >uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic) > >I tried cleaning sssd cache but that didn't help. > >sssd conf is as follows: > >[sssd] >services = nss, pam, ssh, sudo >config_file_version = 2 > >nsswitch.conf seems to be correct as well: > ># /etc/nsswitch.conf > >passwd: compat sss >group: compat sss >shadow: compat > >hosts: files dns >networks: files > >protocols: db files >services: db files >ethers: db files >rpc: db files > >netgroup: nis sss >sudoers: files sss > >Interestingly after I do "getent group devops_team" this group shows up: > >nkrzalic at ircsrv1:~$ id >uid=281200051(nkrzalic) gid=281200051(nkrzalic) >groups=281200051(nkrzalic),281200001(devops_team) Missing groups on ubuntu (sssd-1.11) can be caused by bug https://fedorahosted.org/sssd/ticket/2471. This bug is fixed on CentOS. Workaround is to amend configuration of domain section. ldap_group_object_class = ipaUserGroup If it does not help then please follow instruction from wiki https://fedorahosted.org/sssd/wiki/Troubleshooting LS From johnnydtan at gmail.com Fri May 22 16:05:54 2015 From: johnnydtan at gmail.com (Johnny Tan) Date: Fri, 22 May 2015 12:05:54 -0400 Subject: [Freeipa-users] ubuntu dns discovery Message-ID: Our servers run CentOS-6.6 and ipa-server-3.0.0-42.el6.centos.x86_64 Our CentOS clients (also 6.6) join the domain seamlessly. Our Ubuntu 14.04 LTS clients, however, don't seem to be able to auto-discover domain, realm, or IPA servers: ``` dpkg -l | grep freeipa ii freeipa-client 3.3.4-0ubuntu3.1 amd64 FreeIPA centralized identity framework -- client /usr/sbin/ipa-client-install --mkhomedir --no-ntp --no-sudo --unattended --hostname testing-ubuntu001.pp --principal admin --password xx --debug /usr/sbin/ipa-client-install was invoked with options: {'domain': None, 'force': False, 'krb5_offline_passwords': True, 'primary': False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': False, 'on_master': False, 'ntp_server': None, 'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname': 'testing-ubuntu001.pp', 'no_ac': False, 'unattended': True, 'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'mkhomedir': True, 'conf_ssh': True, 'force_join': False, 'server': None, 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} missing options might be asked for interactively later Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' [IPA Discovery] Starting IPA discovery with domain=None, servers=None, hostname=testing-ubuntu001.pp Start searching for LDAP SRV record in "pp" (domain of the hostname) and its sub-domains Search DNS for SRV record of _ldap._tcp.pp DNS record not found: EmptyLabel Start searching for LDAP SRV record in ".pp" (search domain from /etc/resolv.conf) and its sub-domains Search DNS for SRV record of _ldap._tcp..pp DNS record not found: EmptyLabel Already searched pp; skipping No LDAP server found No LDAP server found Unable to discover domain, not provided on command line Installation failed. Rolling back changes. IPA client is not configured on this system. ``` Yet on the same client: ``` root at testing-ubuntu001:~# dig srv _ldap._tcp.pp +short 0 100 389 production-ipa003.pp. 0 100 389 production-ipa001.pp. 0 100 389 production-ipa002.pp. ``` Why can't ipa-client-install discover those SRV records? johnny -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.kaminski at biotronik.com Fri May 22 16:28:33 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Fri, 22 May 2015 18:28:33 +0200 Subject: [Freeipa-users] Antwort: FreeIPA groups not shown on client In-Reply-To: References: Message-ID: freeipa-users-bounces at redhat.com schrieb am 22.05.2015 09:37:04: > Von: Nikola Kr?ali? > An: freeipa-users at redhat.com > Datum: 22.05.2015 15:05 > Betreff: [Freeipa-users] FreeIPA groups not shown on client > Gesendet von: freeipa-users-bounces at redhat.com > > I have a ubuntu system running IPA client. I am able to log in via ssh > using IPA users, but I do not get any group memberships or sudo rules. > Same configuration works on a different system (running CentOS). > > sssd domain log output shows that the groups are retrieved from server > successfully: > > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [admins] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [ipausers] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [editors] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [trust admins] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [devops_team] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [dev_team] for user [nkrzalic] > (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] > (0x1000): Added group [sys_team] for user [nkrzalic] > > However, these groups are not shown on the user upon login: > > nkrzalic at ircsrv1:~$ id > uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic) > > I tried cleaning sssd cache but that didn't help. > > sssd conf is as follows: > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > nsswitch.conf seems to be correct as well: > > # /etc/nsswitch.conf > > passwd: compat sss > group: compat sss > shadow: compat > > hosts: files dns > networks: files > > protocols: db files > services: db files > ethers: db files > rpc: db files > > netgroup: nis sss > sudoers: files sss > > Interestingly after I do "getent group devops_team" this group shows up: > > nkrzalic at ircsrv1:~$ id > uid=281200051(nkrzalic) gid=281200051(nkrzalic) > groups=281200051(nkrzalic),281200001(devops_team) > nkrzalic at ircsrv1:~$ > > > Any ideas? > > try to kill the cache with: (stop sssd) rm -rf /var/lib/sss/db/* (start sssd) we has had the same problems often here and only really kill the cache has fixed it (sss_cache -A hasnt help) Greetz Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri May 22 16:53:33 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 22 May 2015 18:53:33 +0200 Subject: [Freeipa-users] Antwort: FreeIPA groups not shown on client In-Reply-To: References: Message-ID: <20150522165332.GH17334@mail.corp.redhat.com> On (22/05/15 18:28), Christoph Kaminski wrote: >freeipa-users-bounces at redhat.com schrieb am 22.05.2015 09:37:04: > >> Von: Nikola Kr?ali? >> An: freeipa-users at redhat.com >> Datum: 22.05.2015 15:05 >> Betreff: [Freeipa-users] FreeIPA groups not shown on client >> Gesendet von: freeipa-users-bounces at redhat.com >> >> I have a ubuntu system running IPA client. I am able to log in via ssh >> using IPA users, but I do not get any group memberships or sudo rules. >> Same configuration works on a different system (running CentOS). >> >> sssd domain log output shows that the groups are retrieved from server >> successfully: >> >> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >> (0x1000): Added group [admins] for user [nkrzalic] >> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >> (0x1000): Added group [ipausers] for user [nkrzalic] >> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >> (0x1000): Added group [editors] for user [nkrzalic] >> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >> (0x1000): Added group [trust admins] for user [nkrzalic] >> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >> (0x1000): Added group [devops_team] for user [nkrzalic] >> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >> (0x1000): Added group [dev_team] for user [nkrzalic] >> (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] >> (0x1000): Added group [sys_team] for user [nkrzalic] >> >> However, these groups are not shown on the user upon login: >> >> nkrzalic at ircsrv1:~$ id >> uid=281200051(nkrzalic) gid=281200051(nkrzalic) >groups=281200051(nkrzalic) >> >> I tried cleaning sssd cache but that didn't help. >> >> sssd conf is as follows: >> >> [sssd] >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> >> nsswitch.conf seems to be correct as well: >> >> # /etc/nsswitch.conf >> >> passwd: compat sss >> group: compat sss >> shadow: compat >> >> hosts: files dns >> networks: files >> >> protocols: db files >> services: db files >> ethers: db files >> rpc: db files >> >> netgroup: nis sss >> sudoers: files sss >> >> Interestingly after I do "getent group devops_team" this group shows up: >> >> nkrzalic at ircsrv1:~$ id >> uid=281200051(nkrzalic) gid=281200051(nkrzalic) >> groups=281200051(nkrzalic),281200001(devops_team) >> nkrzalic at ircsrv1:~$ >> >> >> Any ideas? >> >> > >try to kill the cache with: >(stop sssd) rm -rf /var/lib/sss/db/* (start sssd) > >we has had the same problems often here and only really kill the cache has >fixed it (sss_cache -A hasnt help) > I'm sorry it is not a solution. If you still have a problem and you are able to reproduce it then please file a bug with log files. LS From notify.sina at gmail.com Fri May 22 17:00:09 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Fri, 22 May 2015 18:00:09 +0100 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <555CE0DC.1030509@redhat.com> References: <5559AE81.9000907@redhat.com> <5559F1B6.4030207@redhat.com> <555A28B3.8080503@redhat.com> <555B55DE.8070007@redhat.com> <555C8D03.3050709@redhat.com> <555CE0DC.1030509@redhat.com> Message-ID: Hi Rob And thanks for the new instructions. However, right out of the gate: $ ipa-csreplica-manage set-renewal-master Usage: ipa-csreplica-manage [options] ipa-csreplica-manage: error: must provide a command [force-sync | disconnect | list | del | connect | re-initialize] Are there any RHEL6 specific instructions I can follow to the promised land? On Wed, May 20, 2015 at 8:30 PM, Rob Crittenden wrote: > Sina Owolabi wrote: >> >> Hi Rob >> >> This is the only CA master. The one I cloned it from was >> decommissioned, reinstalled and then made to be a replica of this >> server. >> >> Looks like I'm really stuck. How do I export the data out so I can >> reinstall from scratch, if possible? There are a lot of rules and >> configuration data I'd really like to keep. > > > So in this case you have no master managing the renewal. > > Take a look at > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0 > starting at the step "Reconfigure a CA as the new master" > > Since at least one certificate has expired you'll need to go back in time to > get this working. Be sure to restart IPA after going back to ensure that the > CA is up. > > You'll eventually want to do the CRL changes as well. > > rob > >> >> >> On Wed, May 20, 2015, 2:32 PM Rob Crittenden > > wrote: >> >> Sina Owolabi wrote: >> > Another key difference I noticed is that the problematic certs have >> > CA:IPA in them, while the working certs have CA: >> > dogtag-ipa-retrieve-agent-submit. >> >> Ok, the full output is really helpful. >> >> First an explanation of CA subsystem renewal. >> >> CA clones are just that, exact clones of each other, which means they >> use the same subsystem certificates for OCSP, audit, etc. This also >> means that at renewal time they need to be renewed on only one master >> and then somehow shared with the ohter clones. >> >> The initially-installed CA is designated as the renewal master by >> default. It configures certmonger to renew the CA subsytem >> certificates >> and put the new public cert into a shared area in IPA that will be >> replicated to the other masters. >> >> The non-renewal masters are configured with a special CA, >> dogtag-ipa-retrieve-agent-submit, that looks in this shared area for >> an >> updated certificate and when available, it installs it. >> >> So the issue is that it isn't seeing this updated certificate, hence >> CA_WORKING. >> >> The CA_UNREACHABLE are due to the fact that the IPA RA agent >> certificate >> that IPA uses to talk to the CA expired on 04/29. >> >> So the steps you need to take are: >> >> 1. Check your other CA masters and see if they have been renewed >> properly (getcert list will tell you, look for expiration in 2017). >> 2. If they have, see if the data was pushed to LDAP >> >> $ kinit admin >> $ ldapsearch -Y GSSAPI -b >> cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com >> >> See if there are certificate entries there. Check on multiple masters >> to >> see if there is a replication issue. >> >> If the certs are there you can try restarting certmonger to kickstart >> the request. >> >> rob >> > From abokovoy at redhat.com Fri May 22 19:00:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 22 May 2015 22:00:38 +0300 Subject: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015] Message-ID: <20150522190038.GB21881@redhat.com> Hi, As per attached message, Fedora 22 final release will come to life next week. If you are planning to use FreeIPA in Fedora 22 or upgrade your FreeIPA deployment to Fedora 22, make sure updates-testing repository is enabled. Several last moment bug fixes related to FreeIPA were not rolled into the final Fedora 22 image and they are waiting in updats-testing for the gates to be open after release. One particular area is support for cross-forest trusts with Active Directory --- Samba in Fedora 22 got upgraded to 4.2.1 version which caused some changes in underlying libraries FreeIPA uses for supporting the cross-forest trust. The fixes are awaiting you after install in the updats-testing. Happy Fedora 22 use! -- / Alexander Bokovoy -------------- next part -------------- An embedded message was scrubbed... From: Jaroslav Reznik Subject: [Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015 Date: Fri, 22 May 2015 14:46:39 -0400 (EDT) Size: 6159 URL: From mbasti at redhat.com Fri May 22 19:14:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 21:14:37 +0200 Subject: [Freeipa-users] ubuntu dns discovery In-Reply-To: References: Message-ID: <555F801D.9020602@redhat.com> On 22/05/15 18:05, Johnny Tan wrote: > Our servers run CentOS-6.6 and ipa-server-3.0.0-42.el6.centos.x86_64 > > Our CentOS clients (also 6.6) join the domain seamlessly. > > Our Ubuntu 14.04 LTS clients, however, don't seem to be able to > auto-discover domain, realm, or IPA servers: > ``` > dpkg -l | grep freeipa > ii freeipa-client 3.3.4-0ubuntu3.1 > amd64 FreeIPA centralized identity framework -- client > > /usr/sbin/ipa-client-install --mkhomedir --no-ntp --no-sudo > --unattended --hostname testing-ubuntu001.pp --principal admin > --password xx --debug > /usr/sbin/ipa-client-install was invoked with options: {'domain': > None, 'force': False, 'krb5_offline_passwords': True, 'primary': > False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': True, > 'conf_sshd': True, 'conf_ntp': False, 'on_master': False, > 'ntp_server': None, 'ca_cert_file': None, 'principal': 'admin', > 'keytab': None, 'hostname': 'testing-ubuntu001.pp', 'no_ac': False, > 'unattended': True, 'sssd': True, 'trust_sshfp': False, 'dns_updates': > False, 'mkhomedir': True, 'conf_ssh': True, 'force_join': False, > 'server': None, 'prompt_password': False, 'permit': False, 'debug': > True, 'preserve_sssd': False, 'uninstall': False} > missing options might be asked for interactively later > Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' > [IPA Discovery] > Starting IPA discovery with domain=None, servers=None, > hostname=testing-ubuntu001.pp > Start searching for LDAP SRV record in "pp" (domain of the hostname) > and its sub-domains > Search DNS for SRV record of _ldap._tcp.pp > DNS record not found: EmptyLabel > Start searching for LDAP SRV record in ".pp" (search domain from > /etc/resolv.conf) and its sub-domains > Search DNS for SRV record of _ldap._tcp..pp > DNS record not found: EmptyLabel > Already searched pp; skipping > No LDAP server found > No LDAP server found > Unable to discover domain, not provided on command line > Installation failed. Rolling back changes. > IPA client is not configured on this system. > ``` > > Yet on the same client: > ``` > root at testing-ubuntu001:~# dig srv _ldap._tcp.pp +short > 0 100 389 production-ipa003.pp. > 0 100 389 production-ipa001.pp. > 0 100 389 production-ipa002.pp. > ``` > > Why can't ipa-client-install discover those SRV records? > > johnny > > Hello, this is weird, "DNS record not found: EmptyLabel", this error returns python-dns when empty label is used in domain name. And here is empty label -> _ldap._tcp..pp (two dots). But that doubled dot is not on line above and the error is the same, interesting. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosla1987 at gmail.com Fri May 22 19:51:07 2015 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Fri, 22 May 2015 15:51:07 -0400 Subject: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015] In-Reply-To: <20150522190038.GB21881@redhat.com> References: <20150522190038.GB21881@redhat.com> Message-ID: Hi Alexander Great news, does this also mean that user created in freeipa are self created/synchronized in the windows ad ? Regtards 2015-05-22 15:00 GMT-04:00 Alexander Bokovoy : > Hi, > > As per attached message, Fedora 22 final release will come to life next > week. If you are planning to use FreeIPA in Fedora 22 or upgrade your > FreeIPA deployment to Fedora 22, make sure updates-testing repository is > enabled. Several last moment bug fixes related to FreeIPA were not > rolled into the final Fedora 22 image and they are waiting in > updats-testing for the gates to be open after release. > > One particular area is support for cross-forest trusts with Active > Directory --- Samba in Fedora 22 got upgraded to 4.2.1 version which > caused some changes in underlying libraries FreeIPA uses for supporting > the cross-forest trust. The fixes are awaiting you after install in the > updats-testing. > > Happy Fedora 22 use! > -- > / Alexander Bokovoy > > > ---------- Mensaje reenviado ---------- > From: Jaroslav Reznik > To: devel-announce at lists.fedoraproject.org, test-announce < > test-announce at lists.fedoraproject.org>, Fedora Logistics List < > logistics at lists.fedoraproject.org> > Cc: > Date: Fri, 22 May 2015 14:46:39 -0400 (EDT) > Subject: [Test-Announce] Fedora 22 Final status is Go, release on May 26, > 2015 > At the Fedora 22 Final Go/No-Go Meeting #2 that just occurred, it was > agreed to Go with the Fedora 22 Final by Fedora QA, Release Engineering > and Development. > > Fedora 22 Final will be publicly available on Tuesday, May 26, 2015. > > Meeting details can be seen here: > Minutes: http://bit.ly/1Bh2pH1 > Log: http://bit.ly/1HzMI5g > > Thank you everyone for a great job, sleepless nights validating TCs, > RCs, fixing bugs, composing stuf and everything else needed for > smooth releases. Amazing last three years wrangling releases for me! > > Jaroslav > _______________________________________________ > test-announce mailing list > test-announce at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/test-announce > -- > devel mailing list > devel at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnnydtan at gmail.com Fri May 22 20:00:38 2015 From: johnnydtan at gmail.com (Johnny Tan) Date: Fri, 22 May 2015 16:00:38 -0400 Subject: [Freeipa-users] ubuntu dns discovery In-Reply-To: <555F801D.9020602@redhat.com> References: <555F801D.9020602@redhat.com> Message-ID: On Fri, May 22, 2015 at 3:14 PM, Martin Basti wrote: > On 22/05/15 18:05, Johnny Tan wrote: > > Our servers run CentOS-6.6 and ipa-server-3.0.0-42.el6.centos.x86_64 > > Our CentOS clients (also 6.6) join the domain seamlessly. > > Our Ubuntu 14.04 LTS clients, however, don't seem to be able to > auto-discover domain, realm, or IPA servers: > ``` > dpkg -l | grep freeipa > ii freeipa-client 3.3.4-0ubuntu3.1 > amd64 FreeIPA centralized identity framework -- client > > /usr/sbin/ipa-client-install --mkhomedir --no-ntp --no-sudo --unattended > --hostname testing-ubuntu001.pp --principal admin --password xx --debug > /usr/sbin/ipa-client-install was invoked with options: {'domain': None, > 'force': False, 'krb5_offline_passwords': True, 'primary': False, > 'realm_name': None, 'force_ntpd': False, 'create_sshfp': True, 'conf_sshd': > True, 'conf_ntp': False, 'on_master': False, 'ntp_server': None, > 'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname': > 'testing-ubuntu001.pp', 'no_ac': False, 'unattended': True, 'sssd': True, > 'trust_sshfp': False, 'dns_updates': False, 'mkhomedir': True, 'conf_ssh': > True, 'force_join': False, 'server': None, 'prompt_password': False, > 'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} > missing options might be asked for interactively later > Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' > [IPA Discovery] > Starting IPA discovery with domain=None, servers=None, > hostname=testing-ubuntu001.pp > Start searching for LDAP SRV record in "pp" (domain of the hostname) and > its sub-domains > Search DNS for SRV record of _ldap._tcp.pp > DNS record not found: EmptyLabel > Start searching for LDAP SRV record in ".pp" (search domain from > /etc/resolv.conf) and its sub-domains > Search DNS for SRV record of _ldap._tcp..pp > DNS record not found: EmptyLabel > Already searched pp; skipping > No LDAP server found > No LDAP server found > Unable to discover domain, not provided on command line > Installation failed. Rolling back changes. > IPA client is not configured on this system. > ``` > > Yet on the same client: > ``` > root at testing-ubuntu001:~# dig srv _ldap._tcp.pp +short > 0 100 389 production-ipa003.pp. > 0 100 389 production-ipa001.pp. > 0 100 389 production-ipa002.pp. > ``` > > Why can't ipa-client-install discover those SRV records? > > johnny > > > Hello, > > this is weird, "DNS record not found: EmptyLabel", this error returns > python-dns when empty label is used in domain name. > > And here is empty label -> _ldap._tcp..pp (two dots). > > But that doubled dot is not on line above and the error is the same, > interesting. > Aha! It seems our configuration management system is populating `search` in /etc/resolv.conf with ".pp" rather than "pp". If I manually change that, it now works! Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri May 22 20:39:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 22 May 2015 23:39:53 +0300 Subject: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015] In-Reply-To: References: <20150522190038.GB21881@redhat.com> Message-ID: <20150522203856.GC21881@redhat.com> On Fri, 22 May 2015, Carlos Ra?l Laguna wrote: >Hi Alexander >Great news, does this also mean that user created in freeipa are self >created/synchronized in the windows ad ? Regtards With cross-forest trust we don't synchronize anything to AD. Think about it as if FreeIPA was a separate AD forest, two AD forests don't synchronize anything to each other, they _refer_ to each other's domain controllers for operations that require authentication or other changes. -- / Alexander Bokovoy From carlosla1987 at gmail.com Fri May 22 21:40:13 2015 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Fri, 22 May 2015 17:40:13 -0400 Subject: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015] In-Reply-To: <20150522203856.GC21881@redhat.com> References: <20150522190038.GB21881@redhat.com> <20150522203856.GC21881@redhat.com> Message-ID: Just for clarification, If i create a user in Windows 2008R2 it propagates to Freeipa 4.1 because freeIPA trust the AD domain, in this scenario where AD equally trust the freeIPA domain (Fedora 22), a user created in freeIPA should not propagate as well to AD ? Regards 2015-05-22 16:39 GMT-04:00 Alexander Bokovoy : > On Fri, 22 May 2015, Carlos Ra?l Laguna wrote: > >> Hi Alexander >> Great news, does this also mean that user created in freeipa are self >> created/synchronized in the windows ad ? Regtards >> > With cross-forest trust we don't synchronize anything to AD. Think about > it as if FreeIPA was a separate AD forest, two AD forests don't > synchronize anything to each other, they _refer_ to each other's domain > controllers for operations that require authentication or other changes. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri May 22 22:00:02 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 May 2015 18:00:02 -0400 Subject: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015] In-Reply-To: References: <20150522190038.GB21881@redhat.com> <20150522203856.GC21881@redhat.com> Message-ID: <555FA6E2.1050109@redhat.com> Carlos Ra?l Laguna wrote: > Just for clarification, > If i create a user in Windows 2008R2 it propagates to Freeipa 4.1 > because freeIPA trust the AD domain, in this scenario where AD equally > trust the freeIPA domain (Fedora 22), a user created in freeIPA should > not propagate as well to AD ? Regards Users are not copied, you can reference an AD user from IPA. So you can log into an IPA-managed machine using your AD credentials. This does not add the AD user to IPA. Right now you can't reference IPA users in AD resources, in any version of IPA. So no logging into Windows using your IPA credentials (yet). rob > > > 2015-05-22 16:39 GMT-04:00 Alexander Bokovoy >: > > On Fri, 22 May 2015, Carlos Ra?l Laguna wrote: > > Hi Alexander > Great news, does this also mean that user created in freeipa are > self > created/synchronized in the windows ad ? Regtards > > With cross-forest trust we don't synchronize anything to AD. Think about > it as if FreeIPA was a separate AD forest, two AD forests don't > synchronize anything to each other, they _refer_ to each other's domain > controllers for operations that require authentication or other changes. > > -- > / Alexander Bokovoy > > > > From bob at jackland.demon.co.uk Sat May 23 11:51:48 2015 From: bob at jackland.demon.co.uk (Bob Hinton) Date: Sat, 23 May 2015 12:51:48 +0100 Subject: [Freeipa-users] ipa-backup and ipa-restore Message-ID: <556069D4.2000704@jackland.demon.co.uk> Hello, I've been trying to rebuild an ipamaster by using ipa-backup, destroying and recreating the ipamaster VM then using ipa-restore on the rebuilt master. Most functions of the newly built master work. Logging-in via ssh with keys works but using passwords produces "Permission denied, please try again". Password attempts are logged with Authentication Failure in /var/log/secure May 23 12:17:10 ipa004 sshd[6374]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user auser: 7 (Authentication failure) May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user auser: 7 (Authentication failure) May 23 12:17:20 ipa004 sshd[6374]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser May 23 12:17:32 ipa004 sshd[6382]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=adminuser May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=adminuser May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user adminuser: 7 (Authentication failure) May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=adminuser May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user adminuser: 7 (Authentication failure) I have two test users "adminuser" and "auser". I've tried various things with auser involving kadmin.local to attempt to change the kerberos password and "ipa user-mod auser --principal-expiration=2012-01-01Z" to try and force the user keytab to be invalid in the hope that it would be recreated, but this hasn't had any impact apart from slightly different errors in /var/log/krb5kdc.log (see below). I've also tried replacing the keytab by using " ipa-getkeytab -p host/ipa004.test.jackland.uk at TEST.JACKLAND.UK -k temp.keytab -s localhost" to create a new one and then copy it over /etc/krb5.keytab, but this also didn't have any impact. Can anyone tell me what I need to do to make ssh password authentication work on an newly created ipamaster with ipa populated via ipa-restore ? The VM is RHEL7.1 with the following versions of ipa-server and ipa-client installed. Many thanks Bob Name : ipa-server Arch : x86_64 Version : 4.1.0 Release : 18.el7_1.3 Size : 4.2 M Repo : installed >From repo : rhel-7-server-rpms Summary : The IPA authentication server URL : http://www.freeipa.org/ Licence : GPLv3+ Description : IPA is an integrated solution to provide centrally managed Identity (machine, : user, virtual machines, groups, authentication credentials), Policy : (configuration settings, access control information) and Audit (events, : logs, analysis thereof). If you are installing an IPA server you need : to install this package (in other words, most people should NOT install : this package). Name : ipa-client Arch : x86_64 Version : 4.1.0 Release : 18.el7_1.3 Size : 440 k Repo : installed >From repo : rhel-7-server-rpms Summary : IPA authentication for use on clients URL : http://www.freeipa.org/ Licence : GPLv3+ Description : IPA is an integrated solution to provide centrally managed Identity (machine, : user, virtual machines, groups, authentication credentials), Policy : (configuration settings, access control information) and Audit (events, : logs, analysis thereof). If your network uses IPA for authentication, : this package should be installed on every client machine. May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: for , Decrypt integrity check failed while handling ap-request armor May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Additional pre-authentication required May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, etypes {rep=18 tkt=18 ses=18}, host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, etypes {rep=18 tkt=18 ses=18}, host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432377170, etypes {rep=18 tkt=18 ses=18}, admin at TEST.JACKLAND.UK for ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Password has expired May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional pre-authentication required May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: for , Decrypt integrity check failed while handling ap-request armor May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Password has expired May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional pre-authentication required May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: for , Decrypt integrity check failed while handling ap-request armor May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Additional pre-authentication required May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: for , Decrypt integrity check failed while handling ap-request armor May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Additional pre-authentication required May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: for , Decrypt integrity check failed while handling ap-request armor May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing down fd 11 May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432378168, etypes {rep=18 tkt=18 ses=18}, HTTP/ipa004.test.jackland.uk at TEST.JACKLAND.UK for ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): ... CONSTRAINED-DELEGATION s4u-client=admin at TEST.JACKLAND.UK From janellenicole80 at gmail.com Sat May 23 16:46:34 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sat, 23 May 2015 09:46:34 -0700 Subject: [Freeipa-users] RUV clean error? Message-ID: <5560AEEA.2020104@gmail.com> Hi all, Getting close to being clean again, but have this - which is a new error: CLEANALLRUV tasks RID 9 Waiting to process all the updates from the deleted replica... ??? I had done a ipa-replica-manage del --cleanup on the deleted replica (this is related to that duplicate I had) but can't seem to get it to go away. Thoughts? ~Janelle From janellenicole80 at gmail.com Sat May 23 16:58:14 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sat, 23 May 2015 09:58:14 -0700 Subject: [Freeipa-users] RUV clean error? In-Reply-To: <5560AEEA.2020104@gmail.com> References: <5560AEEA.2020104@gmail.com> Message-ID: <5560B1A6.3060809@gmail.com> Restarts on all the servers seem to have resolved all of the issues. Back to a clean environment again. thanks ~J On 5/23/15 9:46 AM, Janelle wrote: > Hi all, > > Getting close to being clean again, but have this - which is a new error: > > CLEANALLRUV tasks > RID 9 Waiting to process all the updates from the deleted replica... > > ??? > > I had done a ipa-replica-manage del --cleanup on the deleted replica > (this is related to that duplicate I had) but can't seem to get it to > go away. > > Thoughts? > ~Janelle From janellenicole80 at gmail.com Sat May 23 20:21:07 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sat, 23 May 2015 13:21:07 -0700 Subject: [Freeipa-users] passwords Message-ID: <5560E133.1070908@gmail.com> I have a question regarding passwords. It seems IPA does a very nice job of generating random passwords. Is there a way to use that feature without actually setting it on a user? Something akin to "pwgen"? Thank you ~Janelle From janellenicole80 at gmail.com Sun May 24 10:12:29 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sun, 24 May 2015 03:12:29 -0700 Subject: [Freeipa-users] Haunted servers? Message-ID: <5561A40D.4010100@gmail.com> And just like that, my haunted servers have all returned. I am going to just put a gun to my head and be done with it. :-( Why do things run perfectly and then suddenly ??? Logs show little to nothing, mostly because the servers are so busy, they have already rotated out. unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 22} 55371e9e000000160000 553eec64000400160000 unable to decode {replica 23} 5545d61f000200170000 55543240000300170000 unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 unable to decode {replica 25} 554d78bf000000190000 555af302000400190000 unable to decode {replica 9} 55402c39000300090000 55402c39000300090000 Don't know what to do anymore. At my wit's end.. ~J From wgraboyes at cenic.org Sun May 24 22:45:17 2015 From: wgraboyes at cenic.org (Bill Graboyes) Date: Sun, 24 May 2015 15:45:17 -0700 Subject: [Freeipa-users] Freeipa Replicate hung Message-ID: <510f417bbb768e2f4498cf197ee36676@imap-vip.cenic.org> Hi List, I have been digging around on this system that hung for the past hour or two trying to figure out why dirserv seemed to be hung. It was not using resources, nor was there any information in any of the log files (dirserv, sssd, etc), it was just stopped. I was unable to run ipactl and get any response. The server would not even reboot cleanly (I had to power it off). Of note that there didn't seem to be any problems with systems accessing via sssd, but systems that were accessing via direct ldap connections, the connection would just hang. OS and Version information: CentOS Linux release 7.1.1503 (Core) ipa-server-4.1.0-18.el7.centos.3.x86_64 -- Thanks Bill Graboyes CENIC Systems From vaclav.adamec at suchy-zleb.cz Mon May 25 05:30:56 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Mon, 25 May 2015 07:30:56 +0200 Subject: [Freeipa-users] Any thoughts on sssd_sudo memory usage ? Message-ID: Hi, after last update I see this: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5918 root 20 0 4413m 4.1g 1596 S 2.8 35.4 31:12.72 sssd_sudo sssd-common-1.11.6-30.el6_6.4.x86_64 on CentOS release 6.6 final (up2date) restart, sync + swap cleanup and in less then 24h I get same memory usage. Any thoughts, hints ? AV From lslebodn at redhat.com Mon May 25 05:41:23 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 25 May 2015 07:41:23 +0200 Subject: [Freeipa-users] Any thoughts on sssd_sudo memory usage ? In-Reply-To: References: Message-ID: <20150525054119.GA11986@mail.corp.redhat.com> On (25/05/15 07:30), Vaclav Adamec wrote: >Hi, > after last update I see this: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 5918 root 20 0 4413m 4.1g 1596 S 2.8 35.4 31:12.72 sssd_sudo > >sssd-common-1.11.6-30.el6_6.4.x86_64 on CentOS release 6.6 final (up2date) > >restart, sync + swap cleanup and in less then 24h I get same memory usage. > Could you draw a graph of sssd_sudo memory usage? or at least gather data (ps -eo pid,cmd,size,rss | grep sssd_sudo) Can you see any errors in sssd_sudo log after enabling verbose logging? https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs LS From markgrinceri at me.com Mon May 25 06:02:38 2015 From: markgrinceri at me.com (Mark Grinceri) Date: Sun, 24 May 2015 23:02:38 -0700 Subject: [Freeipa-users] LDAPSearch - Email Address Message-ID: Hi All, Hopefully this is quite a simple oversight and that someone might be able to steer me in the correct direction. I?ve setup a postfix server and I?m trying to do a ldap lookup on the relay_recipients_map to my FreeIPA server 4.1.3 to query the attribute mail or email to find the users email address. The problem is when I do an ldapsearch and try to search for the attribute mail or email it doesn?t exist. If I add an email address to another attribute like the title as you can see below and do a ldap lookup from postfix on the attribute title it all works fine and yes the email address attribute is set in FreeIPA under the user. Any ideas? output from the ldapsearch: # mark, users, accounts, example.com dn: uid=mark,cn=users,cn=accounts,dc=example,dc=com title: mark at example.com gidNumber: 441200001 uidNumber: 441200001 sn: Grinceri givenName: Mark uid: mark homeDirectory: /home/mark gecos: Mark Grinceri initials: MG manager: uid=admin,cn=users,cn=accounts,dc=example,dc=com loginShell: /bin/bash objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry objectClass: ipauserauthtypeclass objectClass: ipauser cn: Mark Grinceri displayName: Mark Grinceri -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon May 25 06:10:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 May 2015 08:10:39 +0200 Subject: [Freeipa-users] ipa-backup and ipa-restore In-Reply-To: <556069D4.2000704@jackland.demon.co.uk> References: <556069D4.2000704@jackland.demon.co.uk> Message-ID: <5562BCDF.9000609@redhat.com> On 05/23/2015 01:51 PM, Bob Hinton wrote: > Hello, > > I've been trying to rebuild an ipamaster by using ipa-backup, destroying > and recreating the ipamaster VM then using ipa-restore on the rebuilt > master. > > Most functions of the newly built master work. Logging-in via ssh with > keys works but using passwords produces "Permission denied, please try > again". > > Password attempts are logged with Authentication Failure in /var/log/secure > > May 23 12:17:10 ipa004 sshd[6374]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser > May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser > May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user > auser: 7 (Authentication failure) > May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser > May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user > auser: 7 (Authentication failure) > May 23 12:17:20 ipa004 sshd[6374]: PAM 1 more authentication failure; > logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser > May 23 12:17:32 ipa004 sshd[6382]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 > user=adminuser > May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 > user=adminuser > May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user > adminuser: 7 (Authentication failure) > May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 > user=adminuser > May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user > adminuser: 7 (Authentication failure) > > I have two test users "adminuser" and "auser". I've tried various things > with auser involving kadmin.local to attempt to change the kerberos > password and "ipa user-mod auser --principal-expiration=2012-01-01Z" to > try and force the user keytab to be invalid in the hope that it would be > recreated, but this hasn't had any impact apart from slightly different > errors in /var/log/krb5kdc.log (see below). > > I've also tried replacing the keytab by using " ipa-getkeytab -p > host/ipa004.test.jackland.uk at TEST.JACKLAND.UK -k temp.keytab -s > localhost" to create a new one and then copy it over /etc/krb5.keytab, > but this also didn't have any impact. > > Can anyone tell me what I need to do to make ssh password authentication > work on an newly created ipamaster with ipa populated via ipa-restore ? > > The VM is RHEL7.1 with the following versions of ipa-server and > ipa-client installed. > > Many thanks > > Bob > > Name : ipa-server > Arch : x86_64 > Version : 4.1.0 > Release : 18.el7_1.3 > Size : 4.2 M > Repo : installed >>From repo : rhel-7-server-rpms > Summary : The IPA authentication server > URL : http://www.freeipa.org/ > Licence : GPLv3+ > Description : IPA is an integrated solution to provide centrally managed > Identity (machine, > : user, virtual machines, groups, authentication > credentials), Policy > : (configuration settings, access control information) and > Audit (events, > : logs, analysis thereof). If you are installing an IPA > server you need > : to install this package (in other words, most people > should NOT install > : this package). > > Name : ipa-client > Arch : x86_64 > Version : 4.1.0 > Release : 18.el7_1.3 > Size : 440 k > Repo : installed >>From repo : rhel-7-server-rpms > Summary : IPA authentication for use on clients > URL : http://www.freeipa.org/ > Licence : GPLv3+ > Description : IPA is an integrated solution to provide centrally managed > Identity (machine, > : user, virtual machines, groups, authentication > credentials), Policy > : (configuration settings, access control information) and > Audit (events, > : logs, analysis thereof). If your network uses IPA for > authentication, > : this package should be installed on every client machine. > > > > May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: > for , Decrypt integrity check failed > while handling ap-request armor > May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: > host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for > krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Additional pre-authentication > required > May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, > etypes {rep=18 tkt=18 ses=18}, > host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for > krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK > May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, > etypes {rep=18 tkt=18 ses=18}, > host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for > ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK > May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432377170, > etypes {rep=18 tkt=18 ses=18}, admin at TEST.JACKLAND.UK for > ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK > May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: > auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, > Password has expired > May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: > auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional > pre-authentication required > May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: > for , Decrypt integrity check failed > while handling ap-request armor > May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: > auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, > Password has expired > May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: > auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional > pre-authentication required > May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: > for , Decrypt integrity check failed > while handling ap-request armor > May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: > adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, > Additional pre-authentication required > May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: > for , Decrypt integrity check failed > while handling ap-request armor > May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: > adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, > Additional pre-authentication required > May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: > for , Decrypt integrity check failed > while handling ap-request armor > May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing > down fd 11 > May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 > etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432378168, > etypes {rep=18 tkt=18 ses=18}, > HTTP/ipa004.test.jackland.uk at TEST.JACKLAND.UK for > ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK > May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): ... > CONSTRAINED-DELEGATION s4u-client=admin at TEST.JACKLAND.UK > This log strange: > for , Decrypt integrity check failed > while handling ap-request armor I assume SSSD's attempts generate this log. Would stopping SSSD, cleaning it's caches (including fast ccache) in /var/lib/sss/db/ and starting again help? From mkosek at redhat.com Mon May 25 06:21:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 May 2015 08:21:42 +0200 Subject: [Freeipa-users] passwords In-Reply-To: <5560E133.1070908@gmail.com> References: <5560E133.1070908@gmail.com> Message-ID: <5562BF76.2070603@redhat.com> On 05/23/2015 10:21 PM, Janelle wrote: > I have a question regarding passwords. > > It seems IPA does a very nice job of generating random passwords. Thanks! > Is there a > way to use that feature without actually setting it on a user? Something akin > to "pwgen"? > > Thank you > ~Janelle > There is no explicit script to do , there was no demand or value so far. You would need to call for that functionality yourself in a python script. This works for me with FreeIPA 4.1 for example: # python -c "from ipalib import api; api.bootstrap(); api.finalize(); from ipalib.plugins.user import user_pwdchars; from ipapython.ipautil import ipa_generate_password; print ipa_generate_password(user_pwdchars)" dIbhUAM3puoA If you have a vision/idea why/how/when FreeIPA could be used as a Password generated, please feel free to file RFE (and send patches :-) Martin From mkosek at redhat.com Mon May 25 06:24:40 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 May 2015 08:24:40 +0200 Subject: [Freeipa-users] Freeipa Replicate hung In-Reply-To: <510f417bbb768e2f4498cf197ee36676@imap-vip.cenic.org> References: <510f417bbb768e2f4498cf197ee36676@imap-vip.cenic.org> Message-ID: <5562C028.8040609@redhat.com> On 05/25/2015 12:45 AM, Bill Graboyes wrote: > Hi List, > > I have been digging around on this system that hung for the past hour or two > trying to figure out why dirserv seemed to be hung. It was not using > resources, nor was there any information in any of the log files (dirserv, > sssd, etc), it was just stopped. I was unable to run ipactl and get any > response. The server would not even reboot cleanly (I had to power it off). > Of note that there didn't seem to be any problems with systems accessing via > sssd, but systems that were accessing via direct ldap connections, the > connection would just hang. > > OS and Version information: > CentOS Linux release 7.1.1503 (Core) > ipa-server-4.1.0-18.el7.centos.3.x86_64 Hello, I would suggesting starting with providing the information asked for in the 389 DS FAQ: http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs Martin From leszek.mis at gmail.com Mon May 25 07:45:11 2015 From: leszek.mis at gmail.com (crony) Date: Mon, 25 May 2015 09:45:11 +0200 Subject: [Freeipa-users] SSH GSSAPI + FreeIPA with Windows 2008 Trust Message-ID: Hi All, we have setup FreeIPA 4.1 (Centos 7) Trust with Windows 2008R2. All (HBAC, SUDO) works pretty well except SSH SSO using GSSAPI from Windows AD clients (ex. putty) to Linux client machines (Centos 6). Password authentication works, just gssapi fails. Actually, there is one scenario where SSH GSSAPI authentication works -> when connecting to FreeIPA master or replica (trust were established here), but not to FreeIPA host clients. Important sections of configuration files (servers/clients): /etc/ssh/sshd_config: GSSAPIAuthentication yes KerberosAuthentication yes /etc/krb5.conf: auth_to_local = RULE:[1:$1 $0](^.* WINDOWS.DOMAIN$)s/ WINDOWS.DOMAIN/ windows.domain/ auth_to_local = DEFAULT BTW. after I log in by password to linux client machine I can use gssapi within the same host by ssh-ing in a loop to the localhost, so locally GSSAPI works here. Is there something I missed? Any help would be greatly appreciated. /lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From leszek.mis at gmail.com Mon May 25 07:54:03 2015 From: leszek.mis at gmail.com (crony) Date: Mon, 25 May 2015 09:54:03 +0200 Subject: [Freeipa-users] Web interface session timeout Message-ID: Hi All, Is there any way we can change web interface session timeout? I am using form based auth. /lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at jackland.demon.co.uk Mon May 25 09:00:27 2015 From: bob at jackland.demon.co.uk (Bob Hinton) Date: Mon, 25 May 2015 10:00:27 +0100 Subject: [Freeipa-users] ipa-backup and ipa-restore In-Reply-To: <5562BCDF.9000609@redhat.com> References: <556069D4.2000704@jackland.demon.co.uk> <5562BCDF.9000609@redhat.com> Message-ID: <5562E4AB.9060802@jackland.demon.co.uk> Hi Martin, Yes. This fixes the problem on a newly recreated ipamaster - it didn't work on the one I'd been playing around with. So the complete rebuild sequence was... 1) On old ipamaster VM ipa004 (did this on 22/05/2015) login as an admin user with sudo to root access sudo -i ipa-backup tar cvfPz ipa004_backups_22052015.tgz /var/lib/ipa/backup scp ipa004_backups_22052015.tgz to a backup system, destroy old ipamaster VM 2) Recreate ipamaster VM (identical configuration to original) From backup system - scp ipa004_backups_22052015.tgz admin at ipa004: ssh admin at ipa004 su (enter root password - no users with sudo access exist yet) tar xvfPz ipa004_backups_22052015.tgz ipa-restore ipa-full-2015-05-22-17-28-01 systemctl stop sssd rm -f /var/lib/sss/db/* systemctl start sssd Many thanks Bob On 25/05/2015 07:10, Martin Kosek wrote: > On 05/23/2015 01:51 PM, Bob Hinton wrote: >> Hello, >> >> I've been trying to rebuild an ipamaster by using ipa-backup, destroying >> and recreating the ipamaster VM then using ipa-restore on the rebuilt >> master. >> >> Most functions of the newly built master work. Logging-in via ssh with >> keys works but using passwords produces "Permission denied, please try >> again". >> >> Password attempts are logged with Authentication Failure in /var/log/secure >> >> May 23 12:17:10 ipa004 sshd[6374]: pam_unix(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >> May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >> May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user >> auser: 7 (Authentication failure) >> May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >> May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user >> auser: 7 (Authentication failure) >> May 23 12:17:20 ipa004 sshd[6374]: PAM 1 more authentication failure; >> logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >> May 23 12:17:32 ipa004 sshd[6382]: pam_unix(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 >> user=adminuser >> May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 >> user=adminuser >> May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user >> adminuser: 7 (Authentication failure) >> May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 >> user=adminuser >> May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user >> adminuser: 7 (Authentication failure) >> >> I have two test users "adminuser" and "auser". I've tried various things >> with auser involving kadmin.local to attempt to change the kerberos >> password and "ipa user-mod auser --principal-expiration=2012-01-01Z" to >> try and force the user keytab to be invalid in the hope that it would be >> recreated, but this hasn't had any impact apart from slightly different >> errors in /var/log/krb5kdc.log (see below). >> >> I've also tried replacing the keytab by using " ipa-getkeytab -p >> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK -k temp.keytab -s >> localhost" to create a new one and then copy it over /etc/krb5.keytab, >> but this also didn't have any impact. >> >> Can anyone tell me what I need to do to make ssh password authentication >> work on an newly created ipamaster with ipa populated via ipa-restore ? >> >> The VM is RHEL7.1 with the following versions of ipa-server and >> ipa-client installed. >> >> Many thanks >> >> Bob >> >> Name : ipa-server >> Arch : x86_64 >> Version : 4.1.0 >> Release : 18.el7_1.3 >> Size : 4.2 M >> Repo : installed >> >From repo : rhel-7-server-rpms >> Summary : The IPA authentication server >> URL : http://www.freeipa.org/ >> Licence : GPLv3+ >> Description : IPA is an integrated solution to provide centrally managed >> Identity (machine, >> : user, virtual machines, groups, authentication >> credentials), Policy >> : (configuration settings, access control information) and >> Audit (events, >> : logs, analysis thereof). If you are installing an IPA >> server you need >> : to install this package (in other words, most people >> should NOT install >> : this package). >> >> Name : ipa-client >> Arch : x86_64 >> Version : 4.1.0 >> Release : 18.el7_1.3 >> Size : 440 k >> Repo : installed >> >From repo : rhel-7-server-rpms >> Summary : IPA authentication for use on clients >> URL : http://www.freeipa.org/ >> Licence : GPLv3+ >> Description : IPA is an integrated solution to provide centrally managed >> Identity (machine, >> : user, virtual machines, groups, authentication >> credentials), Policy >> : (configuration settings, access control information) and >> Audit (events, >> : logs, analysis thereof). If your network uses IPA for >> authentication, >> : this package should be installed on every client machine. >> >> >> >> May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >> for , Decrypt integrity check failed >> while handling ap-request armor >> May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >> krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Additional pre-authentication >> required >> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, >> etypes {rep=18 tkt=18 ses=18}, >> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >> krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK >> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, >> etypes {rep=18 tkt=18 ses=18}, >> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >> ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK >> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432377170, >> etypes {rep=18 tkt=18 ses=18}, admin at TEST.JACKLAND.UK for >> ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK >> May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: >> auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >> Password has expired >> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >> auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional >> pre-authentication required >> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >> for , Decrypt integrity check failed >> while handling ap-request armor >> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: >> auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >> Password has expired >> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >> auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional >> pre-authentication required >> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >> for , Decrypt integrity check failed >> while handling ap-request armor >> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >> adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >> Additional pre-authentication required >> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >> for , Decrypt integrity check failed >> while handling ap-request armor >> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >> adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >> Additional pre-authentication required >> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >> for , Decrypt integrity check failed >> while handling ap-request armor >> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing >> down fd 11 >> May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432378168, >> etypes {rep=18 tkt=18 ses=18}, >> HTTP/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >> ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK >> May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): ... >> CONSTRAINED-DELEGATION s4u-client=admin at TEST.JACKLAND.UK >> > > This log strange: > >> for , Decrypt integrity check failed >> while handling ap-request armor > I assume SSSD's attempts generate this log. Would stopping SSSD, cleaning it's > caches (including fast ccache) in /var/lib/sss/db/ and starting again help? > . > From mkosek at redhat.com Mon May 25 10:37:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 May 2015 12:37:39 +0200 Subject: [Freeipa-users] ipa-backup and ipa-restore In-Reply-To: <5562E4AB.9060802@jackland.demon.co.uk> References: <556069D4.2000704@jackland.demon.co.uk> <5562BCDF.9000609@redhat.com> <5562E4AB.9060802@jackland.demon.co.uk> Message-ID: <5562FB73.8020000@redhat.com> Good, thanks for confirmation. I filed Bugzilla to add this information to the IPA guide: https://bugzilla.redhat.com/show_bug.cgi?id=1224682 Please feel free to add any useful information you would like to see in the guide to the Bugzilla comment. Thank you, Martin On 05/25/2015 11:00 AM, Bob Hinton wrote: > Hi Martin, > > Yes. This fixes the problem on a newly recreated ipamaster - it didn't > work on the one I'd been playing around with. > > So the complete rebuild sequence was... > > 1) On old ipamaster VM ipa004 (did this on 22/05/2015) > login as an admin user with sudo to root access > sudo -i > ipa-backup > tar cvfPz ipa004_backups_22052015.tgz /var/lib/ipa/backup > scp ipa004_backups_22052015.tgz to a backup system, destroy old > ipamaster VM > > 2) Recreate ipamaster VM (identical configuration to original) > From backup system - > scp ipa004_backups_22052015.tgz admin at ipa004: > ssh admin at ipa004 > su (enter root password - no users with sudo > access exist yet) > tar xvfPz ipa004_backups_22052015.tgz > ipa-restore ipa-full-2015-05-22-17-28-01 > systemctl stop sssd > rm -f /var/lib/sss/db/* > systemctl start sssd > > Many thanks > > Bob > > On 25/05/2015 07:10, Martin Kosek wrote: >> On 05/23/2015 01:51 PM, Bob Hinton wrote: >>> Hello, >>> >>> I've been trying to rebuild an ipamaster by using ipa-backup, destroying >>> and recreating the ipamaster VM then using ipa-restore on the rebuilt >>> master. >>> >>> Most functions of the newly built master work. Logging-in via ssh with >>> keys works but using passwords produces "Permission denied, please try >>> again". >>> >>> Password attempts are logged with Authentication Failure in /var/log/secure >>> >>> May 23 12:17:10 ipa004 sshd[6374]: pam_unix(sshd:auth): authentication >>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >>> May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication >>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >>> May 23 12:17:10 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user >>> auser: 7 (Authentication failure) >>> May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): authentication >>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >>> May 23 12:17:17 ipa004 sshd[6374]: pam_sss(sshd:auth): received for user >>> auser: 7 (Authentication failure) >>> May 23 12:17:20 ipa004 sshd[6374]: PAM 1 more authentication failure; >>> logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 user=auser >>> May 23 12:17:32 ipa004 sshd[6382]: pam_unix(sshd:auth): authentication >>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 >>> user=adminuser >>> May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication >>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 >>> user=adminuser >>> May 23 12:17:33 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user >>> adminuser: 7 (Authentication failure) >>> May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): authentication >>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.1 >>> user=adminuser >>> May 23 12:17:38 ipa004 sshd[6382]: pam_sss(sshd:auth): received for user >>> adminuser: 7 (Authentication failure) >>> >>> I have two test users "adminuser" and "auser". I've tried various things >>> with auser involving kadmin.local to attempt to change the kerberos >>> password and "ipa user-mod auser --principal-expiration=2012-01-01Z" to >>> try and force the user keytab to be invalid in the hope that it would be >>> recreated, but this hasn't had any impact apart from slightly different >>> errors in /var/log/krb5kdc.log (see below). >>> >>> I've also tried replacing the keytab by using " ipa-getkeytab -p >>> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK -k temp.keytab -s >>> localhost" to create a new one and then copy it over /etc/krb5.keytab, >>> but this also didn't have any impact. >>> >>> Can anyone tell me what I need to do to make ssh password authentication >>> work on an newly created ipamaster with ipa populated via ipa-restore ? >>> >>> The VM is RHEL7.1 with the following versions of ipa-server and >>> ipa-client installed. >>> >>> Many thanks >>> >>> Bob >>> >>> Name : ipa-server >>> Arch : x86_64 >>> Version : 4.1.0 >>> Release : 18.el7_1.3 >>> Size : 4.2 M >>> Repo : installed >>> >From repo : rhel-7-server-rpms >>> Summary : The IPA authentication server >>> URL : http://www.freeipa.org/ >>> Licence : GPLv3+ >>> Description : IPA is an integrated solution to provide centrally managed >>> Identity (machine, >>> : user, virtual machines, groups, authentication >>> credentials), Policy >>> : (configuration settings, access control information) and >>> Audit (events, >>> : logs, analysis thereof). If you are installing an IPA >>> server you need >>> : to install this package (in other words, most people >>> should NOT install >>> : this package). >>> >>> Name : ipa-client >>> Arch : x86_64 >>> Version : 4.1.0 >>> Release : 18.el7_1.3 >>> Size : 440 k >>> Repo : installed >>> >From repo : rhel-7-server-rpms >>> Summary : IPA authentication for use on clients >>> URL : http://www.freeipa.org/ >>> Licence : GPLv3+ >>> Description : IPA is an integrated solution to provide centrally managed >>> Identity (machine, >>> : user, virtual machines, groups, authentication >>> credentials), Policy >>> : (configuration settings, access control information) and >>> Audit (events, >>> : logs, analysis thereof). If your network uses IPA for >>> authentication, >>> : this package should be installed on every client machine. >>> >>> >>> >>> May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >>> for , Decrypt integrity check failed >>> while handling ap-request armor >>> May 23 12:09:20 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >>> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >>> krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, Additional pre-authentication >>> required >>> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, >>> etypes {rep=18 tkt=18 ses=18}, >>> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >>> krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK >>> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432379419, >>> etypes {rep=18 tkt=18 ses=18}, >>> host/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >>> ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK >>> May 23 12:10:19 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432377170, >>> etypes {rep=18 tkt=18 ses=18}, admin at TEST.JACKLAND.UK for >>> ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK >>> May 23 12:11:30 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: >>> auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >>> Password has expired >>> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >>> auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional >>> pre-authentication required >>> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >>> for , Decrypt integrity check failed >>> while handling ap-request armor >>> May 23 12:17:10 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: CLIENT KEY EXPIRED: >>> auser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >>> Password has expired >>> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >>> auser at TEST.JACKLAND.UK for kadmin/changepw at TEST.JACKLAND.UK, Additional >>> pre-authentication required >>> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >>> for , Decrypt integrity check failed >>> while handling ap-request armor >>> May 23 12:17:17 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >>> adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >>> Additional pre-authentication required >>> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >>> for , Decrypt integrity check failed >>> while handling ap-request armor >>> May 23 12:17:33 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: NEEDED_PREAUTH: >>> adminuser at TEST.JACKLAND.UK for krbtgt/TEST.JACKLAND.UK at TEST.JACKLAND.UK, >>> Additional pre-authentication required >>> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: error decoding FAST: >>> for , Decrypt integrity check failed >>> while handling ap-request armor >>> May 23 12:17:38 ipa004.test.jackland.uk krb5kdc[2724](info): closing >>> down fd 11 >>> May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): TGS_REQ (6 >>> etypes {18 17 16 23 25 26}) 172.16.128.159: ISSUE: authtime 1432378168, >>> etypes {rep=18 tkt=18 ses=18}, >>> HTTP/ipa004.test.jackland.uk at TEST.JACKLAND.UK for >>> ldap/ipa004.test.jackland.uk at TEST.JACKLAND.UK >>> May 23 12:19:07 ipa004.test.jackland.uk krb5kdc[2724](info): ... >>> CONSTRAINED-DELEGATION s4u-client=admin at TEST.JACKLAND.UK >>> >> >> This log strange: >> >>> for , Decrypt integrity check failed >>> while handling ap-request armor >> I assume SSSD's attempts generate this log. Would stopping SSSD, cleaning it's >> caches (including fast ccache) in /var/lib/sss/db/ and starting again help? >> . >> > From abokovoy at redhat.com Mon May 25 11:25:30 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 May 2015 14:25:30 +0300 Subject: [Freeipa-users] SSH GSSAPI + FreeIPA with Windows 2008 Trust In-Reply-To: References: Message-ID: <20150525112530.GC19176@redhat.com> On Mon, 25 May 2015, crony wrote: >Hi All, >we have setup FreeIPA 4.1 (Centos 7) Trust with Windows 2008R2. All (HBAC, >SUDO) works pretty well except SSH SSO using GSSAPI from Windows AD clients >(ex. putty) to Linux client machines (Centos 6). Password authentication >works, just gssapi fails. Do you have have anything in the SSH server logs when using high enough debug level? SSH GSSAPI (single sign-on) should just work fine. On contrary, delegation or forwarding of credentials (i.e. Kerberos TGT from AD side being available after login to SSH server) should not work unless ok-as-delegate flag is set on the host principal -- see 'ipa host-mod --ok-as-delegate=TRUE'. So what exactly is not working: 1. Logging in without entering a password from AD-joined Windows station with PuTTY? 2. Logging in without the password works but no Kerberos ticket available in the shell? 3. Logging in always requires password and then Kerberos ticket is not available in the shell? 4. Something else? > >Actually, there is one scenario where SSH GSSAPI authentication works -> >when connecting to FreeIPA master or replica (trust were established here), >but not to FreeIPA host clients. > >Important sections of configuration files (servers/clients): > >/etc/ssh/sshd_config: >GSSAPIAuthentication yes >KerberosAuthentication yes Remove 'KerberosAuthentication yes', you don't want it to be used, only GSSAPI. >/etc/krb5.conf: >auth_to_local = RULE:[1:$1 $0](^.* WINDOWS.DOMAIN$)s/ >WINDOWS.DOMAIN/ windows.domain/ >auth_to_local = DEFAULT You don't need to specify auth_to_local rules in krb5.conf in RHEL 7.1 because we now have this filled in by SSSD. As you are claiming FreeIPA 4.1 is in use, it means CentOS 7.1, thus SSSD automatically contributing auth_to_local plugin. >BTW. after I log in by password to linux client machine I can use gssapi >within the same host by ssh-ing in a loop to the localhost, so locally >GSSAPI works here. This is expected and is by design. >Is there something I missed? >Any help would be greatly appreciated. Answer my questions above, I suspect all you need is to mark the host principal as available for delegation. -- / Alexander Bokovoy From pspacek at redhat.com Mon May 25 11:30:05 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 May 2015 13:30:05 +0200 Subject: [Freeipa-users] ubuntu dns discovery In-Reply-To: References: <555F801D.9020602@redhat.com> Message-ID: <556307BD.4050006@redhat.com> On 22.5.2015 22:00, Johnny Tan wrote: > On Fri, May 22, 2015 at 3:14 PM, Martin Basti wrote: > >> On 22/05/15 18:05, Johnny Tan wrote: >> >> Our servers run CentOS-6.6 and ipa-server-3.0.0-42.el6.centos.x86_64 >> >> Our CentOS clients (also 6.6) join the domain seamlessly. >> >> Our Ubuntu 14.04 LTS clients, however, don't seem to be able to >> auto-discover domain, realm, or IPA servers: >> ``` >> dpkg -l | grep freeipa >> ii freeipa-client 3.3.4-0ubuntu3.1 >> amd64 FreeIPA centralized identity framework -- client >> >> /usr/sbin/ipa-client-install --mkhomedir --no-ntp --no-sudo --unattended >> --hostname testing-ubuntu001.pp --principal admin --password xx --debug >> /usr/sbin/ipa-client-install was invoked with options: {'domain': None, >> 'force': False, 'krb5_offline_passwords': True, 'primary': False, >> 'realm_name': None, 'force_ntpd': False, 'create_sshfp': True, 'conf_sshd': >> True, 'conf_ntp': False, 'on_master': False, 'ntp_server': None, >> 'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname': >> 'testing-ubuntu001.pp', 'no_ac': False, 'unattended': True, 'sssd': True, >> 'trust_sshfp': False, 'dns_updates': False, 'mkhomedir': True, 'conf_ssh': >> True, 'force_join': False, 'server': None, 'prompt_password': False, >> 'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} >> missing options might be asked for interactively later >> Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' >> [IPA Discovery] >> Starting IPA discovery with domain=None, servers=None, >> hostname=testing-ubuntu001.pp >> Start searching for LDAP SRV record in "pp" (domain of the hostname) and >> its sub-domains >> Search DNS for SRV record of _ldap._tcp.pp >> DNS record not found: EmptyLabel >> Start searching for LDAP SRV record in ".pp" (search domain from >> /etc/resolv.conf) and its sub-domains >> Search DNS for SRV record of _ldap._tcp..pp >> DNS record not found: EmptyLabel >> Already searched pp; skipping >> No LDAP server found >> No LDAP server found >> Unable to discover domain, not provided on command line >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> ``` >> >> Yet on the same client: >> ``` >> root at testing-ubuntu001:~# dig srv _ldap._tcp.pp +short >> 0 100 389 production-ipa003.pp. >> 0 100 389 production-ipa001.pp. >> 0 100 389 production-ipa002.pp. >> ``` >> >> Why can't ipa-client-install discover those SRV records? >> >> johnny >> >> >> Hello, >> >> this is weird, "DNS record not found: EmptyLabel", this error returns >> python-dns when empty label is used in domain name. >> >> And here is empty label -> _ldap._tcp..pp (two dots). >> >> But that doubled dot is not on line above and the error is the same, >> interesting. >> > > Aha! It seems our configuration management system is populating `search` in > /etc/resolv.conf with ".pp" rather than "pp". If I manually change that, it > now works! Thank you. Martin, do you see in code why it did not work before? We should fix that (assuming that we are able to find the root cause :-). -- Petr^2 Spacek From striker at redhat.com Mon May 25 14:27:58 2015 From: striker at redhat.com (Striker Leggette) Date: Mon, 25 May 2015 10:27:58 -0400 Subject: [Freeipa-users] Restore deleted RBAC Rules? Message-ID: <5563316E.30204@redhat.com> Is it possible to restore deleted RBAC rules that were deleted from "Permissions and Privileges"? -- Striker From notify.sina at gmail.com Mon May 25 15:46:55 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 25 May 2015 16:46:55 +0100 Subject: [Freeipa-users] How to restore data to a fresh IPA reinstall from a CA-less replica Message-ID: Hi! Please how do I restore data to a freshly reinstalled IPA server from an existing CA-less replica that has had replication agreements removed? Both servers are running rhel 6.6 with ipa-server versions 3.0.0 ( For some reason the IPA servers do not upgrade beyond this version). I have been searching for information from RHEL knowledgebase and from the FreeIPA site but I do not find information that exactly matches my situation. I am grateful for any assistance in this. Thanks! From rmeggins at redhat.com Mon May 25 16:15:27 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 May 2015 10:15:27 -0600 Subject: [Freeipa-users] Freeipa Replicate hung In-Reply-To: <5562C028.8040609@redhat.com> References: <510f417bbb768e2f4498cf197ee36676@imap-vip.cenic.org> <5562C028.8040609@redhat.com> Message-ID: <55634A9F.2000300@redhat.com> On 05/25/2015 12:24 AM, Martin Kosek wrote: > On 05/25/2015 12:45 AM, Bill Graboyes wrote: >> Hi List, >> >> I have been digging around on this system that hung for the past hour or two >> trying to figure out why dirserv seemed to be hung. It was not using >> resources, nor was there any information in any of the log files (dirserv, >> sssd, etc), it was just stopped. I was unable to run ipactl and get any >> response. The server would not even reboot cleanly (I had to power it off). >> Of note that there didn't seem to be any problems with systems accessing via >> sssd, but systems that were accessing via direct ldap connections, the >> connection would just hang. >> >> OS and Version information: >> CentOS Linux release 7.1.1503 (Core) >> ipa-server-4.1.0-18.el7.centos.3.x86_64 > Hello, > > I would suggesting starting with providing the information asked for in the 389 > DS FAQ: > > http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs > > Martin > For IPA, you will also need to do: debuginfo-install ipa-server slapi-nis From carlosla1987 at gmail.com Mon May 25 17:06:50 2015 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Mon, 25 May 2015 13:06:50 -0400 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. Message-ID: How i can use a single backend for a email deployment in such scenario ? Since i am using forest trust, therefore users are not present in one place. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Mon May 25 18:59:14 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 25 May 2015 20:59:14 +0200 Subject: [Freeipa-users] OSX login very slow Message-ID: Hello, I'm using OSX 10.10.3 (Yosemite) and I've followed the Freeipa/OSX guide at linsec.ca. I can do the following with very fast response time: - id on osx host - klist/kdestroy/kinit a ticket - ssh via SSO to ipaserver with this ticket - ping osxhost & osxhost.local from ipaserver - lookup users in OSX directory app - IPA server has "green light" in OSX network account server The thing that fails for me is login from OSX login window. Well, it doesn't fail but it took 12 minutes for an IPA user to login. Any ideas what to look for? -- john -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Mon May 25 22:20:22 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 25 May 2015 15:20:22 -0700 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <5561A40D.4010100@gmail.com> References: <5561A40D.4010100@gmail.com> Message-ID: <5563A026.8060809@gmail.com> On 5/24/15 3:12 AM, Janelle wrote: > And just like that, my haunted servers have all returned. > I am going to just put a gun to my head and be done with it. :-( > > Why do things run perfectly and then suddenly ??? > Logs show little to nothing, mostly because the servers are so busy, > they have already rotated out. > > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 22} 55371e9e000000160000 553eec64000400160000 > unable to decode {replica 23} 5545d61f000200170000 55543240000300170000 > unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 > unable to decode {replica 25} 554d78bf000000190000 555af302000400190000 > unable to decode {replica 9} 55402c39000300090000 55402c39000300090000 > > Don't know what to do anymore. At my wit's end.. > > ~J So things are getting more interesting. Still trying to find the "leaking server(s)". here is what I mean by that. As you see, I continue to find these -- BUT, notice a new symptom -- replica 9 does NOT show any other data - it is blank? unable to decode {replica 16} 55356472000300100000 55356472000300100000 unable to decode {replica 22} 55371e9e000000160000 553eec64000400160000 unable to decode {replica 24} 554d53d3000100180000 554d54a4000200180000 unable to decode {replica 25} 554d78bf000200190000 555af302000400190000 unable to decode {replica 9} Now, if I delete these from a server using the ldapmodify method - they go away briefly, but then if I restart the server, they come back. Let me try to explain -- given a number of servers, say 8, if I user ldapmodify to delete from 1 of those, they seem to go away from maybe 4 of them -- but if I wait a few minutes, it is almost as though "replication" is re-adding these bad replicas from the servers that I have NOT deleted them from. So my question is simple - is there something in the logs I can look for that would indicate the SOURCE of these bogus entries? Is the replica 9 with NO extra data any indication of something I could look for? I am not willing to give up easily (as you might have already guessed) and I am determined to find the cause of these. I know we need more logs, but with all the traffic, the logs rollover within a few hours, and if the problem is happening at 3am for example, I am not able to track it down because the logs have rolled. Back to my investigations. ~J From carlosla1987 at gmail.com Mon May 25 22:21:48 2015 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Mon, 25 May 2015 18:21:48 -0400 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: References: Message-ID: Any ideas how to overcome this? Winsync may be a better approach for us instead of cross-trust.Regards 2015-05-25 13:06 GMT-04:00 Carlos Ra?l Laguna : > How i can use a single backend for a email deployment in such scenario ? > Since i am using forest trust, therefore users are not present in one > place. Regards > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaclav.adamec at suchy-zleb.cz Tue May 26 04:39:26 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 26 May 2015 06:39:26 +0200 Subject: [Freeipa-users] Any thoughts on sssd_sudo memory usage ? In-Reply-To: <20150525054119.GA11986@mail.corp.redhat.com> References: <20150525054119.GA11986@mail.corp.redhat.com> Message-ID: ps -eo pid,cmd,size,rss | grep sssd_sudo 1533 /usr/libexec/sssd/sssd_sudo 4245972 4247700 and huge amount of this (trying again and again): (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback] (0x0040): Could not look up the user [2]: No such file or directory (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_get_user] (0x0080): No results for getpwnam call but other servers in same datacenter looks ok in the same time, but later this error was visible also on others, it's just question of time. On Mon, May 25, 2015 at 7:41 AM, Lukas Slebodnik wrote: > On (25/05/15 07:30), Vaclav Adamec wrote: >>Hi, >> after last update I see this: >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 5918 root 20 0 4413m 4.1g 1596 S 2.8 35.4 31:12.72 sssd_sudo >> >>sssd-common-1.11.6-30.el6_6.4.x86_64 on CentOS release 6.6 final (up2date) >> >>restart, sync + swap cleanup and in less then 24h I get same memory usage. >> > Could you draw a graph of sssd_sudo memory usage? > or at least gather data > (ps -eo pid,cmd,size,rss | grep sssd_sudo) > > Can you see any errors in sssd_sudo log after enabling verbose logging? > https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs > > LS -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " From vaclav.adamec at suchy-zleb.cz Tue May 26 04:44:23 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 26 May 2015 06:44:23 +0200 Subject: [Freeipa-users] Any thoughts on sssd_sudo memory usage ? In-Reply-To: References: <20150525054119.GA11986@mail.corp.redhat.com> Message-ID: With higher debug level I see that sssd sudo trying to resolve local account (for nagios monitoring) Vasek On Tue, May 26, 2015 at 6:39 AM, Vaclav Adamec wrote: > ps -eo pid,cmd,size,rss | grep sssd_sudo > 1533 /usr/libexec/sssd/sssd_sudo 4245972 4247700 > > and huge amount of this (trying again and again): > > (Tue May 26 06:35:47 2015) [sssd[sudo]] > [sudosrv_check_user_dp_callback] (0x0040): Could not look up the user > [2]: No such file or directory > (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_get_user] (0x0080): > No results for getpwnam call > > but other servers in same datacenter looks ok in the same time, but > later this error was visible also on others, it's just question of > time. > > > On Mon, May 25, 2015 at 7:41 AM, Lukas Slebodnik wrote: >> On (25/05/15 07:30), Vaclav Adamec wrote: >>>Hi, >>> after last update I see this: >>> >>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>> 5918 root 20 0 4413m 4.1g 1596 S 2.8 35.4 31:12.72 sssd_sudo >>> >>>sssd-common-1.11.6-30.el6_6.4.x86_64 on CentOS release 6.6 final (up2date) >>> >>>restart, sync + swap cleanup and in less then 24h I get same memory usage. >>> >> Could you draw a graph of sssd_sudo memory usage? >> or at least gather data >> (ps -eo pid,cmd,size,rss | grep sssd_sudo) >> >> Can you see any errors in sssd_sudo log after enabling verbose logging? >> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs >> >> LS > > > > -- > -- May the fox be with you ... > /\ > (~( > ) ) /\_/\ > (_=---_(@ @) > ( \ / > /|/----\|\ V > " " " " -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " From lslebodn at redhat.com Tue May 26 05:53:22 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 26 May 2015 07:53:22 +0200 Subject: [Freeipa-users] Any thoughts on sssd_sudo memory usage ? In-Reply-To: References: <20150525054119.GA11986@mail.corp.redhat.com> Message-ID: <20150526055322.GA12025@mail.corp.redhat.com> On (26/05/15 06:44), Vaclav Adamec wrote: >With higher debug level I see that sssd sudo trying to resolve local >account (for nagios monitoring) > There was/is a bug which does not respect filter_user in sudo provider https://fedorahosted.org/sssd/ticket/2625. (It's already fixed in fedora >= 22) It would be a workaround for you. >On Tue, May 26, 2015 at 6:39 AM, Vaclav Adamec > wrote: >> ps -eo pid,cmd,size,rss | grep sssd_sudo >> 1533 /usr/libexec/sssd/sssd_sudo 4245972 4247700 >> >> and huge amount of this (trying again and again): >> >> (Tue May 26 06:35:47 2015) [sssd[sudo]] >> [sudosrv_check_user_dp_callback] (0x0040): Could not look up the user >> [2]: No such file or directory >> (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_get_user] (0x0080): >> No results for getpwnam call >> >> but other servers in same datacenter looks ok in the same time, but >> later this error was visible also on others, it's just question of >> time. I assume you have sssd-1.11 because such bug was fixed in sssd-1.12 https://git.fedorahosted.org/cgit/sssd.git/commit/?id=09579ae252c181c7884defc0612c36108f6cf509 You can test with my pre-release of sssd-1.12.5 https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ (It already contains fix for #2625) LS From mkosek at redhat.com Tue May 26 06:38:15 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 08:38:15 +0200 Subject: [Freeipa-users] Restore deleted RBAC Rules? In-Reply-To: <5563316E.30204@redhat.com> References: <5563316E.30204@redhat.com> Message-ID: <556414D7.60009@redhat.com> On 05/25/2015 04:27 PM, Striker Leggette wrote: > Is it possible to restore deleted RBAC rules that were deleted from > "Permissions and Privileges"? Hello Striker, Only if you did a data backup. I do not know about other way... More information and ideas about Backup and Restore in FreeIPA: http://www.freeipa.org/page/Backup_and_Restore Martin From mkosek at redhat.com Tue May 26 06:42:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 08:42:25 +0200 Subject: [Freeipa-users] How to restore data to a fresh IPA reinstall from a CA-less replica In-Reply-To: References: Message-ID: <556415D1.2090903@redhat.com> On 05/25/2015 05:46 PM, Sina Owolabi wrote: > Hi! > > Please how do I restore data to a freshly reinstalled IPA server from > an existing CA-less replica that has had replication agreements > removed? By restore, you mean actually migrate? We have a pending RFE for this: https://fedorahosted.org/freeipa/ticket/3656 Migration of users/groups can be done via migrate-ds command. Migration of SUDO/HBAC/automount/... can be done by LDIF export and import (with some changes realms, etc.). But we have no automated way how to migrate Kerberos keys or certificates as the underlying keys are different. > Both servers are running rhel 6.6 with ipa-server versions 3.0.0 > ( For some reason the IPA servers do not upgrade beyond this version). If you want a higher version than FreeIPA 3.0.0, please use RHEL-7.x. RHEL-7.1 has FreeIPA 4.1, which is much more cooler than 3.0.0 :-) This is what we recommend for new deployments anyway. > I have been searching for information from RHEL knowledgebase and from > the FreeIPA site but I do not find information that exactly matches my > situation. > > I am grateful for any assistance in this. > > > Thanks! > HTH, Martin From mkosek at redhat.com Tue May 26 06:47:17 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 08:47:17 +0200 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <5563A026.8060809@gmail.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> Message-ID: <556416F5.3030107@redhat.com> On 05/26/2015 12:20 AM, Janelle wrote: > On 5/24/15 3:12 AM, Janelle wrote: >> And just like that, my haunted servers have all returned. >> I am going to just put a gun to my head and be done with it. :-( >> >> Why do things run perfectly and then suddenly ??? >> Logs show little to nothing, mostly because the servers are so busy, they >> have already rotated out. >> >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 22} 55371e9e000000160000 553eec64000400160000 >> unable to decode {replica 23} 5545d61f000200170000 55543240000300170000 >> unable to decode {replica 24} 554d53d3000000180000 554d54a4000200180000 >> unable to decode {replica 25} 554d78bf000000190000 555af302000400190000 >> unable to decode {replica 9} 55402c39000300090000 55402c39000300090000 >> >> Don't know what to do anymore. At my wit's end.. >> >> ~J > So things are getting more interesting. Still trying to find the "leaking > server(s)". here is what I mean by that. As you see, I continue to find these > -- BUT, notice a new symptom -- replica 9 does NOT show any other data - it is > blank? Hello Janelle, Thanks for update. So you worry that there might still be the "rogue IPA replica" that would be injecting the wrong replica data? In any case, I bet Ludwig and Thierry will follow up with your thread, there is just delay caused by the various public holidays and PTOs this week and we need to rest before digging into the fun with RUVs - as you already know yourself :-) > unable to decode {replica 16} 55356472000300100000 55356472000300100000 > unable to decode {replica 22} 55371e9e000000160000 553eec64000400160000 > unable to decode {replica 24} 554d53d3000100180000 554d54a4000200180000 > unable to decode {replica 25} 554d78bf000200190000 555af302000400190000 > unable to decode {replica 9} > > Now, if I delete these from a server using the ldapmodify method - they go away > briefly, but then if I restart the server, they come back. > > Let me try to explain -- given a number of servers, say 8, if I user ldapmodify > to delete from 1 of those, they seem to go away from maybe 4 of them -- but if > I wait a few minutes, it is almost as though "replication" is re-adding these > bad replicas from the servers that I have NOT deleted them from. > > So my question is simple - is there something in the logs I can look for that > would indicate the SOURCE of these bogus entries? Is the replica 9 with NO > extra data any indication of something I could look for? > > I am not willing to give up easily (as you might have already guessed) and I am > determined to find the cause of these. I know we need more logs, but with all > the traffic, the logs rollover within a few hours, and if the problem is > happening at 3am for example, I am not able to track it down because the logs > have rolled. > > Back to my investigations. > ~J > From mkosek at redhat.com Tue May 26 06:49:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 08:49:53 +0200 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: References: Message-ID: <55641791.2020702@redhat.com> On 05/26/2015 12:21 AM, Carlos Ra?l Laguna wrote: > Any ideas how to overcome this? Winsync may be a better approach for us instead > of cross-trust.Regards > > 2015-05-25 13:06 GMT-04:00 Carlos Ra?l Laguna >: > > How i can use a single backend for a email deployment in such scenario ? > Since i am using forest trust, therefore users are not present in one > place. Regards Hello Carlos, I think you will need to deploy the use case better, what do you mean by "email deployment". If you want LDAP BIND-like authentication for a mail server, it should work with trusts also, if you direct the LDAP base to cn=compat. Some related reading: https://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf https://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts HOWTOs on mails: http://www.freeipa.org/page/HowTos#Mail_Services HTH, Martin From notify.sina at gmail.com Tue May 26 07:04:36 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Tue, 26 May 2015 07:04:36 +0000 Subject: [Freeipa-users] How to restore data to a fresh IPA reinstall from a CA-less replica In-Reply-To: <556415D1.2090903@redhat.com> References: <556415D1.2090903@redhat.com> Message-ID: Hi Martin I actually mean restore. It's a complicated situation... There once was a primary and it's CA replica. The primary got hosed and was cloned a few years ago from the replica. Then the replica got hosed a few times too, saved by the "primary", only now it wouldn't install a CA during replica setup. Now the cloned primary got hosed (it sees itself as a clone and being a the only CA, has nowhere to go to renew certs). We opted to reinstall a fresh primary and now we are looking for how to copy existing data from the standing CA-less replica (everything is the same, realms, DNS hosts, HBAC, sudo rules, etc ) to the freshly installed CA primary. This would be amazing if we could or we'll have to setup the entire network and rules from scratch. I would really appreciate some example commands we could run to import data into the new primary. We've already run db2bak and db2ldif on the replica to export from a helpful script we found in a thread. I hope you can help us! On Tue, May 26, 2015, 7:42 AM Martin Kosek wrote: > On 05/25/2015 05:46 PM, Sina Owolabi wrote: > > Hi! > > > > Please how do I restore data to a freshly reinstalled IPA server from > > an existing CA-less replica that has had replication agreements > > removed? > > By restore, you mean actually migrate? We have a pending RFE for this: > https://fedorahosted.org/freeipa/ticket/3656 > > Migration of users/groups can be done via migrate-ds command. Migration of > SUDO/HBAC/automount/... can be done by LDIF export and import (with some > changes realms, etc.). But we have no automated way how to migrate Kerberos > keys or certificates as the underlying keys are different. > > > Both servers are running rhel 6.6 with ipa-server versions 3.0.0 > > ( For some reason the IPA servers do not upgrade beyond this version). > > If you want a higher version than FreeIPA 3.0.0, please use RHEL-7.x. > RHEL-7.1 > has FreeIPA 4.1, which is much more cooler than 3.0.0 :-) This is what we > recommend for new deployments anyway. > > > I have been searching for information from RHEL knowledgebase and from > > the FreeIPA site but I do not find information that exactly matches my > > situation. > > > > I am grateful for any assistance in this. > > > > > > Thanks! > > > > HTH, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue May 26 07:14:32 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 09:14:32 +0200 Subject: [Freeipa-users] How to restore data to a fresh IPA reinstall from a CA-less replica In-Reply-To: References: <556415D1.2090903@redhat.com> Message-ID: <55641D58.6030306@redhat.com> On 05/26/2015 09:04 AM, Sina Owolabi wrote: > Hi Martin > > I actually mean restore. It's a complicated situation... There once was a > primary and it's CA replica. The primary got hosed and was cloned a few years > ago from the replica. Then the replica got hosed a few times too, saved by the > "primary", only now it wouldn't install a CA during replica setup. Now the > cloned primary got hosed (it sees itself as a clone and being a the only CA, > has nowhere to go to renew certs). We opted to reinstall a fresh primary and > now we are looking for how to copy existing data from the standing CA-less > replica (everything is the same, realms, DNS hosts, HBAC, sudo rules, etc ) > to the freshly installed CA primary. What do you mean by "hosed" replica? Do you know why it happened? This is obviously something that should not happen with FreeIPA, it being the backbone of the infrastructure. This is another reason why I think you should better build your infrastructure on RHEL-7.1, it has more Backup&Restore options (ipa-backup, ipa-restore): https://www.freeipa.org/page/Backup_and_Restore > This would be amazing if we could or > we'll have to setup the entire network and rules from scratch. > I would really appreciate some example commands we could run to import data > into the new primary. We've already run db2bak and db2ldif on the replica to > export from a helpful script we found in a thread. > I hope you can help us! If realms is the same, I think db2ldif and then importing the LDIF can be very effective in restoring the DNS, HBAC, SUDO entries. You may just need to extract those from the LDIF and then ldapadd it to your server so that you do not overwrite other critical settings. As I wrote below, certificates or Kerberos keys cannot be that easily migrated and you would need to rebuild the keytabs when the services are created (ipa-getkeytab). I do not have any other specific scripts or examples at hand, maybe other users here has something. Martin > > > On Tue, May 26, 2015, 7:42 AM Martin Kosek > wrote: > > On 05/25/2015 05:46 PM, Sina Owolabi wrote: > > Hi! > > > > Please how do I restore data to a freshly reinstalled IPA server from > > an existing CA-less replica that has had replication agreements > > removed? > > By restore, you mean actually migrate? We have a pending RFE for this: > https://fedorahosted.org/freeipa/ticket/3656 > > Migration of users/groups can be done via migrate-ds command. Migration of > SUDO/HBAC/automount/... can be done by LDIF export and import (with some > changes realms, etc.). But we have no automated way how to migrate Kerberos > keys or certificates as the underlying keys are different. > > > Both servers are running rhel 6.6 with ipa-server versions 3.0.0 > > ( For some reason the IPA servers do not upgrade beyond this version). > > If you want a higher version than FreeIPA 3.0.0, please use RHEL-7.x. RHEL-7.1 > has FreeIPA 4.1, which is much more cooler than 3.0.0 :-) This is what we > recommend for new deployments anyway. > > > I have been searching for information from RHEL knowledgebase and from > > the FreeIPA site but I do not find information that exactly matches my > > situation. > > > > I am grateful for any assistance in this. > > > > > > Thanks! > > > > HTH, > Martin > From notify.sina at gmail.com Tue May 26 07:42:08 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Tue, 26 May 2015 07:42:08 +0000 Subject: [Freeipa-users] How to restore data to a fresh IPA reinstall from a CA-less replica In-Reply-To: <55641D58.6030306@redhat.com> References: <556415D1.2090903@redhat.com> <55641D58.6030306@redhat.com> Message-ID: Thanks Martin. Would upgrading both servers to 7.1 and then attempting a backup and restore from the CA-less replica to the new master be a safe option? Would this work better? On Tue, May 26, 2015, 8:14 AM Martin Kosek wrote: > On 05/26/2015 09:04 AM, Sina Owolabi wrote: > > Hi Martin > > > > I actually mean restore. It's a complicated situation... There once was a > > primary and it's CA replica. The primary got hosed and was cloned a few > years > > ago from the replica. Then the replica got hosed a few times too, saved > by the > > "primary", only now it wouldn't install a CA during replica setup. Now > the > > cloned primary got hosed (it sees itself as a clone and being a the only > CA, > > has nowhere to go to renew certs). We opted to reinstall a fresh primary > and > > now we are looking for how to copy existing data from the standing > CA-less > > replica (everything is the same, realms, DNS hosts, HBAC, sudo rules, > etc ) > > to the freshly installed CA primary. > > What do you mean by "hosed" replica? Do you know why it happened? This is > obviously something that should not happen with FreeIPA, it being the > backbone > of the infrastructure. > > This is another reason why I think you should better build your > infrastructure > on RHEL-7.1, it has more Backup&Restore options (ipa-backup, ipa-restore): > > https://www.freeipa.org/page/Backup_and_Restore > > > This would be amazing if we could or > > we'll have to setup the entire network and rules from scratch. > > I would really appreciate some example commands we could run to import > data > > into the new primary. We've already run db2bak and db2ldif on the > replica to > > export from a helpful script we found in a thread. > > I hope you can help us! > > If realms is the same, I think db2ldif and then importing the LDIF can be > very > effective in restoring the DNS, HBAC, SUDO entries. You may just need to > extract those from the LDIF and then ldapadd it to your server so that you > do > not overwrite other critical settings. > > As I wrote below, certificates or Kerberos keys cannot be that easily > migrated > and you would need to rebuild the keytabs when the services are created > (ipa-getkeytab). > > I do not have any other specific scripts or examples at hand, maybe other > users > here has something. > > Martin > > > > > > > On Tue, May 26, 2015, 7:42 AM Martin Kosek > > wrote: > > > > On 05/25/2015 05:46 PM, Sina Owolabi wrote: > > > Hi! > > > > > > Please how do I restore data to a freshly reinstalled IPA server > from > > > an existing CA-less replica that has had replication agreements > > > removed? > > > > By restore, you mean actually migrate? We have a pending RFE for > this: > > https://fedorahosted.org/freeipa/ticket/3656 > > > > Migration of users/groups can be done via migrate-ds command. > Migration of > > SUDO/HBAC/automount/... can be done by LDIF export and import (with > some > > changes realms, etc.). But we have no automated way how to migrate > Kerberos > > keys or certificates as the underlying keys are different. > > > > > Both servers are running rhel 6.6 with ipa-server versions 3.0.0 > > > ( For some reason the IPA servers do not upgrade beyond this > version). > > > > If you want a higher version than FreeIPA 3.0.0, please use > RHEL-7.x. RHEL-7.1 > > has FreeIPA 4.1, which is much more cooler than 3.0.0 :-) This is > what we > > recommend for new deployments anyway. > > > > > I have been searching for information from RHEL knowledgebase and > from > > > the FreeIPA site but I do not find information that exactly > matches my > > > situation. > > > > > > I am grateful for any assistance in this. > > > > > > > > > Thanks! > > > > > > > HTH, > > Martin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaclav.adamec at suchy-zleb.cz Tue May 26 09:15:01 2015 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 26 May 2015 11:15:01 +0200 Subject: [Freeipa-users] Any thoughts on sssd_sudo memory usage ? In-Reply-To: <20150526055322.GA12025@mail.corp.redhat.com> References: <20150525054119.GA11986@mail.corp.redhat.com> <20150526055322.GA12025@mail.corp.redhat.com> Message-ID: Thanks, I'll try some workarounds and wait for new package in centos repositories On Tue, May 26, 2015 at 7:53 AM, Lukas Slebodnik wrote: > On (26/05/15 06:44), Vaclav Adamec wrote: >>With higher debug level I see that sssd sudo trying to resolve local >>account (for nagios monitoring) >> > There was/is a bug which does not respect filter_user in sudo provider > https://fedorahosted.org/sssd/ticket/2625. (It's already fixed in fedora >= 22) > > It would be a workaround for you. > >>On Tue, May 26, 2015 at 6:39 AM, Vaclav Adamec >> wrote: >>> ps -eo pid,cmd,size,rss | grep sssd_sudo >>> 1533 /usr/libexec/sssd/sssd_sudo 4245972 4247700 >>> >>> and huge amount of this (trying again and again): >>> >>> (Tue May 26 06:35:47 2015) [sssd[sudo]] >>> [sudosrv_check_user_dp_callback] (0x0040): Could not look up the user >>> [2]: No such file or directory >>> (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_get_user] (0x0080): >>> No results for getpwnam call >>> >>> but other servers in same datacenter looks ok in the same time, but >>> later this error was visible also on others, it's just question of >>> time. > I assume you have sssd-1.11 because such bug was fixed in sssd-1.12 > https://git.fedorahosted.org/cgit/sssd.git/commit/?id=09579ae252c181c7884defc0612c36108f6cf509 > > You can test with my pre-release of sssd-1.12.5 > https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ > (It already contains fix for #2625) > > LS -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " From viktor.voltaire at aphelion.se Tue May 26 11:12:32 2015 From: viktor.voltaire at aphelion.se (Viktor Voltaire) Date: Tue, 26 May 2015 13:12:32 +0200 Subject: [Freeipa-users] ERROR: Operations error: Allocation of a new value for range cn=posix ids, cn=distributed numeric assignment plugin, cn=plugins, cn=config failed! Unable to proceed. Message-ID: <55645520.1030601@aphelion.se> I run a setup of two freeipa servers 4.1 on centos 7. I have recently migrated from my my old master to a new one, decommissioning the two old servers and setting up another new replica. When i try to add a new user i get the following error: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Any thoughts? Regards, -- Viktor Voltaire Mobile: +46 725 057 447 Mail: viktor.voltaire at aphelion.se Aphelion AB | Kungsgatan 2, SE-111 43 Stockholm, Sweden | Phone: +46 8 588 977 00 Aphelion eFX Trading Inc | 31 Penn Plaza, New York, NY 10001, USA | Phone: +1 646 821 4585 ***** Email confidentiality notice ***** This email and any files transmitted with it may contain confidential information and is intended only for the person or entity which it is addressed to. If you have received this email in error, please notify the sender immediately by e-mail and delete the e-mail without taking notice of its content. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Aphelion Group. Therefore this e-mail does not represent a binding agreement nor an offer to deal. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Neither the Aphelion Group nor the sender can accept any liability for any kind of damage as the result of viruses, transmission errors or omissions in the contents of this message. If verification should be required please request a hard-copy version. Aphelion AB, Kungsgatan 2, 111 43 Stockholm, Sweden, www.aphelion.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue May 26 11:17:20 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 13:17:20 +0200 Subject: [Freeipa-users] Web interface session timeout In-Reply-To: References: Message-ID: <55645640.4050908@redhat.com> On 05/25/2015 09:54 AM, crony wrote: > Hi All, > Is there any way we can change web interface session timeout? I am using > form based auth. > > /lm > Hi, Could be changed by setting: session_auth_duration property in /etc/ipa/default.conf or /etc/ipa/server.conf IPA's default value is '20 minutes' -- Petr Vobornik From pvoborni at redhat.com Tue May 26 11:22:22 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 13:22:22 +0200 Subject: [Freeipa-users] ERROR: Operations error: Allocation of a new value for range cn=posix ids, cn=distributed numeric assignment plugin, cn=plugins, cn=config failed! Unable to proceed. In-Reply-To: <55645520.1030601@aphelion.se> References: <55645520.1030601@aphelion.se> Message-ID: <5564576E.9040806@redhat.com> On 05/26/2015 01:12 PM, Viktor Voltaire wrote: > I run a setup of two freeipa servers 4.1 on centos 7. > > I have recently migrated from my my old master to a new one, > decommissioning the two old servers and setting up another new replica. > > When i try to add a new user i get the following error: > > ERROR: Operations error: Allocation of a new value for range cn=posix > ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config > failed! Unable to proceed. > > Any thoughts? > > Regards, > > Hello Viktor, please read "RANGES" section of `man ipa-replica-manage` Guessing what could have happened: - new servers were created but none got DNA range because no new user nor group was created there - when servers were decommissioned, their ranges were not returned back to different master (this might be bug). Could be fixed by creating new DNA ranges on the new masters using ipa-replica-manage tool. -- Petr Vobornik From viktor.voltaire at aphelion.se Tue May 26 11:38:56 2015 From: viktor.voltaire at aphelion.se (Viktor Voltaire) Date: Tue, 26 May 2015 13:38:56 +0200 Subject: [Freeipa-users] ERROR: Operations error: Allocation of a new value for range cn=posix ids, cn=distributed numeric assignment plugin, cn=plugins, cn=config failed! Unable to proceed. In-Reply-To: <5564576E.9040806@redhat.com> References: <55645520.1030601@aphelion.se> <5564576E.9040806@redhat.com> Message-ID: <55645B50.5070706@aphelion.se> Hi Petr, I created new DNA ranges on my primary master, this resolved the issue. I think the issue was not adding any new user on the new master before decommissioning the old ones. Regards, Viktor Petr Vobornik skrev den 2015-05-26 13:22: > On 05/26/2015 01:12 PM, Viktor Voltaire wrote: >> I run a setup of two freeipa servers 4.1 on centos 7. >> >> I have recently migrated from my my old master to a new one, >> decommissioning the two old servers and setting up another new replica. >> >> When i try to add a new user i get the following error: >> >> ERROR: Operations error: Allocation of a new value for range cn=posix >> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config >> failed! Unable to proceed. >> >> Any thoughts? >> >> Regards, >> >> > > Hello Viktor, > > please read "RANGES" section of `man ipa-replica-manage` > > Guessing what could have happened: > - new servers were created but none got DNA range because no new user > nor group was created there > - when servers were decommissioned, their ranges were not returned > back to different master (this might be bug). > > Could be fixed by creating new DNA ranges on the new masters using > ipa-replica-manage tool. From leszek.mis at gmail.com Tue May 26 12:31:59 2015 From: leszek.mis at gmail.com (=?UTF-8?Q?Leszek_Mi=C5=9B?=) Date: Tue, 26 May 2015 14:31:59 +0200 Subject: [Freeipa-users] SSH GSSAPI + FreeIPA with Windows 2008 Trust In-Reply-To: <20150525112530.GC19176@redhat.com> References: <20150525112530.GC19176@redhat.com> Message-ID: Hi Alexander, thank you for your fast reply. I've already executed: # ipa host-mod --ok-as-delegate=TRUE but still cant log in using GSSAPI to ipa clients. Please find answers below: 1. Yes, logging to Linux IPA Client (Centos 6.6) without entering password is not working from AD-joined Windows station with PuTTY. Logging to IPA Master server without entering password (using gssapi) works ok. 2. - 3. Logging in to ipa clients from AD-joined Windows station with Putty (0.64) always requires password and then Kerberos ticket is available in the shell. After I changed loglevel in /etc/sshd/sshd_config on ipa client to LogLevel Debug i found in /var/log/secure: .... debug1: userauth-request for user leszek service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "leszek" ... debug1: Postponed gssapi-with-mic for leszek from X.X.X.X debug1: Got no client credentials Failed gssapi-with-mic for user leszek After entering password and logging to system I found this in /var/log/secure: ... debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism /var/log/sssd/sssd_domain.log ... [ipa_subdom_get_forest] (0x0400: 4th component is not 'trust', nothing to do. ... Any ideas? /lm 2015-05-25 13:25 GMT+02:00 Alexander Bokovoy : > On Mon, 25 May 2015, crony wrote: > >> Hi All, >> we have setup FreeIPA 4.1 (Centos 7) Trust with Windows 2008R2. All (HBAC, >> SUDO) works pretty well except SSH SSO using GSSAPI from Windows AD >> clients >> (ex. putty) to Linux client machines (Centos 6). Password authentication >> works, just gssapi fails. >> > Do you have have anything in the SSH server logs when using high enough > debug level? > > SSH GSSAPI (single sign-on) should just work fine. On contrary, delegation > or forwarding > of credentials (i.e. Kerberos TGT from AD side being available after > login to SSH server) should not work unless ok-as-delegate flag is set > on the host principal -- see 'ipa host-mod --ok-as-delegate=TRUE'. > > So what exactly is not working: > > 1. Logging in without entering a password from AD-joined Windows > station with PuTTY? > > 2. Logging in without the password works but no Kerberos ticket > available in the shell? > > 3. Logging in always requires password and then Kerberos ticket is not > available in the shell? > > 4. Something else? > > >> Actually, there is one scenario where SSH GSSAPI authentication works -> >> when connecting to FreeIPA master or replica (trust were established >> here), >> but not to FreeIPA host clients. >> >> Important sections of configuration files (servers/clients): >> >> /etc/ssh/sshd_config: >> GSSAPIAuthentication yes >> KerberosAuthentication yes >> > Remove 'KerberosAuthentication yes', you don't want it to be used, only > GSSAPI. > > /etc/krb5.conf: >> auth_to_local = RULE:[1:$1 $0](^.* WINDOWS.DOMAIN$)s/ >> WINDOWS.DOMAIN/ windows.domain/ >> auth_to_local = DEFAULT >> > You don't need to specify auth_to_local rules in krb5.conf in RHEL 7.1 > because we now have this filled in by SSSD. As you are claiming FreeIPA > 4.1 is in use, it means CentOS 7.1, thus SSSD automatically contributing > auth_to_local plugin. > > BTW. after I log in by password to linux client machine I can use gssapi >> within the same host by ssh-ing in a loop to the localhost, so locally >> GSSAPI works here. >> > This is expected and is by design. > > > Is there something I missed? >> Any help would be greatly appreciated. >> > Answer my questions above, I suspect all you need is to mark the host > principal as available for delegation. > > -- > / Alexander Bokovoy > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue May 26 13:45:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 May 2015 09:45:32 -0400 Subject: [Freeipa-users] Restore deleted RBAC Rules? In-Reply-To: <556414D7.60009@redhat.com> References: <5563316E.30204@redhat.com> <556414D7.60009@redhat.com> Message-ID: <556478FC.1090001@redhat.com> Martin Kosek wrote: > On 05/25/2015 04:27 PM, Striker Leggette wrote: >> Is it possible to restore deleted RBAC rules that were deleted from >> "Permissions and Privileges"? > > Hello Striker, > > Only if you did a data backup. I do not know about other way... > > More information and ideas about Backup and Restore in FreeIPA: > http://www.freeipa.org/page/Backup_and_Restore > > Martin > It depends on what was deleted. If he deleted common rules shipped by IPA then re-running ipa-ldap-updater should re-add them. The --test option will show you what it would do without updating the entries, assuming you have a version that has --test. Regardless, the next package update will re-run the updater and add them back anyway. rob From rcritten at redhat.com Tue May 26 13:47:30 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 May 2015 09:47:30 -0400 Subject: [Freeipa-users] OSX login very slow In-Reply-To: References: Message-ID: <55647972.3020308@redhat.com> John Obaterspok wrote: > Hello, > > I'm using OSX 10.10.3 (Yosemite) and I've followed the Freeipa/OSX guide > at linsec.ca . > I can do the following with very fast response time: > - id on osx host > - klist/kdestroy/kinit a ticket > - ssh via SSO to ipaserver with this ticket > - ping osxhost & osxhost.local from ipaserver > - lookup users in OSX directory app > - IPA server has "green light" in OSX network account server > > The thing that fails for me is login from OSX login window. Well, it > doesn't fail but it took 12 minutes for an IPA user to login. > > Any ideas what to look for? My guess is DNS issues. Wireshark may help you sort out what is going on. rob From tbordaz at redhat.com Tue May 26 14:04:18 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 26 May 2015 16:04:18 +0200 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <556416F5.3030107@redhat.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> Message-ID: <55647D62.4090800@redhat.com> On 05/26/2015 08:47 AM, Martin Kosek wrote: > On 05/26/2015 12:20 AM, Janelle wrote: >> On 5/24/15 3:12 AM, Janelle wrote: >>> And just like that, my haunted servers have all returned. >>> I am going to just put a gun to my head and be done with it. :-( >>> >>> Why do things run perfectly and then suddenly ??? >>> Logs show little to nothing, mostly because the servers are so busy, >>> they >>> have already rotated out. >>> >>> unable to decode {replica 16} 55356472000300100000 >>> 55356472000300100000 >>> unable to decode {replica 22} 55371e9e000000160000 >>> 553eec64000400160000 >>> unable to decode {replica 23} 5545d61f000200170000 >>> 55543240000300170000 >>> unable to decode {replica 24} 554d53d3000000180000 >>> 554d54a4000200180000 >>> unable to decode {replica 25} 554d78bf000000190000 >>> 555af302000400190000 >>> unable to decode {replica 9} 55402c39000300090000 55402c39000300090000 >>> >>> Don't know what to do anymore. At my wit's end.. >>> >>> ~J >> So things are getting more interesting. Still trying to find the >> "leaking >> server(s)". here is what I mean by that. As you see, I continue to >> find these >> -- BUT, notice a new symptom -- replica 9 does NOT show any other >> data - it is >> blank? > > Hello Janelle, > > Thanks for update. So you worry that there might still be the "rogue > IPA replica" that would be injecting the wrong replica data? > > In any case, I bet Ludwig and Thierry will follow up with your thread, > there is just delay caused by the various public holidays and PTOs > this week and we need to rest before digging into the fun with RUVs - > as you already know yourself :-) > >> unable to decode {replica 16} 55356472000300100000 55356472000300100000 >> unable to decode {replica 22} 55371e9e000000160000 553eec64000400160000 >> unable to decode {replica 24} 554d53d3000100180000 554d54a4000200180000 >> unable to decode {replica 25} 554d78bf000200190000 555af302000400190000 >> unable to decode {replica 9} >> >> Now, if I delete these from a server using the ldapmodify method - >> they go away >> briefly, but then if I restart the server, they come back. >> >> Let me try to explain -- given a number of servers, say 8, if I user >> ldapmodify >> to delete from 1 of those, they seem to go away from maybe 4 of them >> -- but if >> I wait a few minutes, it is almost as though "replication" is >> re-adding these >> bad replicas from the servers that I have NOT deleted them from. On each replica (master/replica) there are one RUV in the database and one RUV in the changelog. When cleanallruv succeeds it clears both of them. All replica should be reachable when you issue cleanallruv, so that it can clean the RUVs on all the replicas in almost "single" operation. If some replica are not reachable, they keep information of about the cleaned RID and then can later propagate those "old" RID to the rest of the replica. Ludwig managed to reproduce the issue with a quite complex test case (3 replicas and multiple cleanallruv). We have not yet identified the reason how a cleaned replicaId can get resurrected. In parallel we just reproduced it without a clear test case but in a 2 replica topology. >> >> So my question is simple - is there something in the logs I can look >> for that >> would indicate the SOURCE of these bogus entries? Is the replica 9 >> with NO >> extra data any indication of something I could look for? I guess that if I have the answer to your question we would have understood the bug .. >> >> I am not willing to give up easily (as you might have already >> guessed) and I am >> determined to find the cause of these. I know we need more logs, but >> with all >> the traffic, the logs rollover within a few hours, and if the problem is >> happening at 3am for example, I am not able to track it down because >> the logs >> have rolled. >> >> Back to my investigations. >> ~J >> > From traiano at gmail.com Tue May 26 14:36:39 2015 From: traiano at gmail.com (Traiano Welcome) Date: Tue, 26 May 2015 17:36:39 +0300 Subject: [Freeipa-users] FreeIPA On SuSE (SLES 11, 12, and up) Message-ID: Hi All Has anyone successfully configured IPA v4.xx on SLES (specifically 11.x)? Thanks in advance, Traiano From abokovoy at redhat.com Tue May 26 14:45:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 26 May 2015 17:45:27 +0300 Subject: [Freeipa-users] SSH GSSAPI + FreeIPA with Windows 2008 Trust In-Reply-To: References: <20150525112530.GC19176@redhat.com> Message-ID: <20150526144527.GG19176@redhat.com> On Tue, 26 May 2015, Leszek Mi? wrote: >Hi Alexander, >thank you for your fast reply. > >I've already executed: # ipa host-mod --ok-as-delegate=TRUE but still cant >log in using GSSAPI to ipa clients. > >Please find answers below: >1. Yes, logging to Linux IPA Client (Centos 6.6) without entering password >is not working from AD-joined Windows station with PuTTY. Logging to IPA >Master server without entering password (using gssapi) works ok. >2. - >3. Logging in to ipa clients from AD-joined Windows station with Putty >(0.64) always requires password and then Kerberos ticket is available in >the shell. > >After I changed loglevel in /etc/sshd/sshd_config on ipa client to LogLevel >Debug i found in /var/log/secure: >.... >debug1: userauth-request for user leszek service ssh-connection method none >debug1: attempt 0 failures 0 >debug1: PAM: initializing for "leszek" >... >debug1: Postponed gssapi-with-mic for leszek from X.X.X.X >debug1: Got no client credentials >Failed gssapi-with-mic for user leszek > >After entering password and logging to system I found this in >/var/log/secure: >... >debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism Can you provide a full log level DEBUG3 off the list? I'm a bit busy so it will take some time to respond. >/var/log/sssd/sssd_domain.log >... >[ipa_subdom_get_forest] (0x0400: 4th component is not 'trust', nothing to >do. >... This can be ignored, it is SSSD internal debug output, not related to your issues. -- / Alexander Bokovoy From janellenicole80 at gmail.com Tue May 26 14:56:16 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 26 May 2015 07:56:16 -0700 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <55647D62.4090800@redhat.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> Message-ID: <55648990.2050001@gmail.com> On 5/26/15 7:04 AM, thierry bordaz wrote: > On 05/26/2015 08:47 AM, Martin Kosek wrote: >> On 05/26/2015 12:20 AM, Janelle wrote: >>> On 5/24/15 3:12 AM, Janelle wrote: >>>> And just like that, my haunted servers have all returned. >>>> I am going to just put a gun to my head and be done with it. :-( >>>> >>>> Why do things run perfectly and then suddenly ??? >>>> Logs show little to nothing, mostly because the servers are so >>>> busy, they >>>> have already rotated out. >>>> >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 22} 55371e9e000000160000 >>>> 553eec64000400160000 >>>> unable to decode {replica 23} 5545d61f000200170000 >>>> 55543240000300170000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> unable to decode {replica 25} 554d78bf000000190000 >>>> 555af302000400190000 >>>> unable to decode {replica 9} 55402c39000300090000 >>>> 55402c39000300090000 >>>> >>>> Don't know what to do anymore. At my wit's end.. >>>> >>>> ~J >>> So things are getting more interesting. Still trying to find the >>> "leaking >>> server(s)". here is what I mean by that. As you see, I continue to >>> find these >>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>> data - it is >>> blank? >> >> Hello Janelle, >> >> Thanks for update. So you worry that there might still be the "rogue >> IPA replica" that would be injecting the wrong replica data? >> >> In any case, I bet Ludwig and Thierry will follow up with your >> thread, there is just delay caused by the various public holidays and >> PTOs this week and we need to rest before digging into the fun with >> RUVs - as you already know yourself :-) >> >>> unable to decode {replica 16} 55356472000300100000 >>> 55356472000300100000 >>> unable to decode {replica 22} 55371e9e000000160000 >>> 553eec64000400160000 >>> unable to decode {replica 24} 554d53d3000100180000 >>> 554d54a4000200180000 >>> unable to decode {replica 25} 554d78bf000200190000 >>> 555af302000400190000 >>> unable to decode {replica 9} >>> >>> Now, if I delete these from a server using the ldapmodify method - >>> they go away >>> briefly, but then if I restart the server, they come back. >>> >>> Let me try to explain -- given a number of servers, say 8, if I user >>> ldapmodify >>> to delete from 1 of those, they seem to go away from maybe 4 of them >>> -- but if >>> I wait a few minutes, it is almost as though "replication" is >>> re-adding these >>> bad replicas from the servers that I have NOT deleted them from. > > On each replica (master/replica) there are one RUV in the database and > one RUV in the changelog. > When cleanallruv succeeds it clears both of them. All replica should > be reachable when you issue cleanallruv, so that > it can clean the RUVs on all the replicas in almost "single" > operation. If some replica are not reachable, they keep > information of about the cleaned RID and then can later propagate > those "old" RID to the rest of the replica. > > Ludwig managed to reproduce the issue with a quite complex test case > (3 replicas and multiple cleanallruv). > We have not yet identified the reason how a cleaned replicaId can get > resurrected. > In parallel we just reproduced it without a clear test case but in a 2 > replica topology. > > >>> >>> So my question is simple - is there something in the logs I can look >>> for that >>> would indicate the SOURCE of these bogus entries? Is the replica 9 >>> with NO >>> extra data any indication of something I could look for? > > I guess that if I have the answer to your question we would have > understood the bug .. > > A little more information to go on: I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? ~J From carlosla1987 at gmail.com Tue May 26 17:36:02 2015 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Tue, 26 May 2015 13:36:02 -0400 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: <55641791.2020702@redhat.com> References: <55641791.2020702@redhat.com> Message-ID: Hello Martin, The email deployment it is a groupware in this scenario Kolab, kolab use 389 ad as main backend and it require some kolab ldap specific attribute to work properly, this is not a problem in fact is quite easy to use freeipa as kolab backend, so far so good but the romance only get this far. Since we also use Windows Ad with forest-trust not all user are present in the FreeIPA directory and there it is where my problem lays. Since not all user are in the same box it become difficult to implement one mail system for all users. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue May 26 17:52:22 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 May 2015 13:52:22 -0400 Subject: [Freeipa-users] FreeIPA On SuSE (SLES 11, 12, and up) In-Reply-To: References: Message-ID: <5564B2D6.6000203@redhat.com> Traiano Welcome wrote: > Hi All > > Has anyone successfully configured IPA v4.xx on SLES (specifically 11.x)? As a client or a server? I'm pretty sure that sssd is built for SLES 12, I don't see it on 11 and that would be the major hurdle for a client. You can probably connect it using nss_ldap in any case. rob From n3g4s at hotmail.com Tue May 26 21:48:28 2015 From: n3g4s at hotmail.com (Ricardo Oliveira) Date: Tue, 26 May 2015 21:48:28 +0000 Subject: [Freeipa-users] Installation on CentOS 6.6 with DNS Message-ID: Hi, I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option on, using the CentOS provided packages: rpm My problem is that everything is installed except when I use this flag. So, when I run: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U The installation finishes successfully. If I add DNS switches to the installation, it fails almost at the end: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns --no-forwarders Output (clipped): --------------------------------------------------- ... Configuring the web interface (httpd): Estimated time 1 minute [1/13]: setting mod_nss port to 443 [2/13]: setting mod_nss password file [3/13]: enabling mod_nss renegotiate [4/13]: adding URL rewriting rules [5/13]: configuring httpd [6/13]: setting up ssl [7/13]: setting up browser autoconfig [8/13]: publish CA cert [9/13]: creating a keytab for httpd [10/13]: clean up any existing httpd ccache [11/13]: configuring SELinux for httpd [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Can't contact LDAP server [root at ipa ~]# --------------------------------------------------- The screen output is at http://pastebin.com/HKiUwKq4The end of the error log is at http://pastebin.com/jDUhBCL7 (it's a 29 MB file so I only pasted the end of it). If anyone has come across anything like this, I would appreciate your help. Thanks. Ricardo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dewanggaba at xtremenitro.org Tue May 26 23:14:34 2015 From: dewanggaba at xtremenitro.org (NitrouZ) Date: Wed, 27 May 2015 06:14:34 +0700 Subject: [Freeipa-users] Installation on CentOS 6.6 with DNS In-Reply-To: References: Message-ID: Have you add your ipa.domain.com ip address on /etc/hosts file? The error seems like your installation can't resolve the ip address. On Wednesday, May 27, 2015, Ricardo Oliveira wrote: > Hi, > > I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option > on, using the CentOS provided packages: > > rpm > > My problem is that everything is installed except when I use this flag. > So, when I run: > > ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r > MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U > > The installation finishes successfully. > If I add DNS switches to the installation, it fails almost at the end: > > ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r > MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns > --no-forwarders > > Output (clipped): > --------------------------------------------------- > ... > Configuring the web interface (httpd): Estimated time 1 minute > [1/13]: setting mod_nss port to 443 > [2/13]: setting mod_nss password file > [3/13]: enabling mod_nss renegotiate > [4/13]: adding URL rewriting rules > [5/13]: configuring httpd > [6/13]: setting up ssl > [7/13]: setting up browser autoconfig > [8/13]: publish CA cert > [9/13]: creating a keytab for httpd > [10/13]: clean up any existing httpd ccache > [11/13]: configuring SELinux for httpd > [12/13]: restarting httpd > [13/13]: configuring httpd to start on boot > Done configuring the web interface (httpd). > Applying LDAP updates > Restarting the directory server > Restarting the KDC > Can't contact LDAP server > [root at ipa ~]# > --------------------------------------------------- > The screen output is at http://pastebin.com/HKiUwKq4 > The end of the error log is at http://pastebin.com/jDUhBCL7 (it's a 29 MB > file so I only pasted the end of it). > If anyone has come across anything like this, I would appreciate your help. > > Thanks. > Ricardo. > -- Sent from iDewangga Device -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlau at tetrioncapital.com Wed May 27 02:14:43 2015 From: tlau at tetrioncapital.com (Thomas Lau) Date: Wed, 27 May 2015 10:14:43 +0800 Subject: [Freeipa-users] FreeIPA 3.3.3 backup and restore Message-ID: Hi All, I was reading this page but seems very confusing: https://www.freeipa.org/page/V3/Backup_and_Restore#Data_Backup_.26_Restore_Process_.28online.29 ?ipa-backup and ipa-restore command doesn't exists. I know full system backup works, but is there have a way to do core Kerberos DB backup? or the most important DB would be LDAP only?? ?Other than full system backup, is there have any other way to do backup and restore for FreeIPA?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Wed May 27 06:04:58 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 27 May 2015 08:04:58 +0200 Subject: [Freeipa-users] ipa-backup and ipa-restore In-Reply-To: <5562E4AB.9060802@jackland.demon.co.uk> References: <556069D4.2000704@jackland.demon.co.uk> <5562BCDF.9000609@redhat.com> <5562E4AB.9060802@jackland.demon.co.uk> Message-ID: <20150527060458.GC12030@mail.corp.redhat.com> On (25/05/15 10:00), Bob Hinton wrote: >Hi Martin, > >Yes. This fixes the problem on a newly recreated ipamaster - it didn't >work on the one I'd been playing around with. > >So the complete rebuild sequence was... > >1) On old ipamaster VM ipa004 (did this on 22/05/2015) > login as an admin user with sudo to root access > sudo -i > ipa-backup > tar cvfPz ipa004_backups_22052015.tgz /var/lib/ipa/backup > scp ipa004_backups_22052015.tgz to a backup system, destroy old >ipamaster VM > >2) Recreate ipamaster VM (identical configuration to original) > From backup system - > scp ipa004_backups_22052015.tgz admin at ipa004: > ssh admin at ipa004 > su (enter root password - no users with sudo >access exist yet) > tar xvfPz ipa004_backups_22052015.tgz > ipa-restore ipa-full-2015-05-22-17-28-01 > systemctl stop sssd > rm -f /var/lib/sss/db/* > systemctl start sssd Could ipa-restore do previous 3 operations? LS From sanju.a at tcs.com Wed May 27 07:09:33 2015 From: sanju.a at tcs.com (Sanju A) Date: Wed, 27 May 2015 12:39:33 +0530 Subject: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) In-Reply-To: <555F3075.6090905@redhat.com> References: <555C8D47.7030306@redhat.com> <555DDE8D.2000107@redhat.com> <555F278C.30901@redhat.com> <555F3075.6090905@redhat.com> Message-ID: Hi Rob, ipactl status is up and the flag is also in the correct state. However I have restarted pki-cad and the issue got fixed. Thanks for your help in fixing the issue. Regards Sanju Abraham From: Rob Crittenden To: Sanju A Cc: freeipa-users at redhat.com Date: 22-05-2015 19:05 Subject: Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Sanju A wrote: > Dear Rob, > > Please find the entire result. Ok, the good news is that renewal already took place and it looks like everything is a-ok certificate-wise. First, make sure the CA is up: # ipactl status If the CA is down, start it with service pki-cad start. If the CA is up, the next thing to check are the trust flags: # certutil -L -d /var/lib/pki-ca/alias The auditSigningCert should be u,u,Pu If it isn't, fix it with: # certutil -M -t u,u,Pu -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' You'll need to restart the CA after changing the trust: # service pki-cad restart If the trust is ok and the CA was already up we'd need to see your CA logs to try to determine what is going on. rob =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 27 07:27:22 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 09:27:22 +0200 Subject: [Freeipa-users] ipa-backup and ipa-restore In-Reply-To: <20150527060458.GC12030@mail.corp.redhat.com> References: <556069D4.2000704@jackland.demon.co.uk> <5562BCDF.9000609@redhat.com> <5562E4AB.9060802@jackland.demon.co.uk> <20150527060458.GC12030@mail.corp.redhat.com> Message-ID: <556571DA.6030804@redhat.com> On 05/27/2015 08:04 AM, Lukas Slebodnik wrote: > On (25/05/15 10:00), Bob Hinton wrote: >> Hi Martin, >> >> Yes. This fixes the problem on a newly recreated ipamaster - it didn't >> work on the one I'd been playing around with. >> >> So the complete rebuild sequence was... >> >> 1) On old ipamaster VM ipa004 (did this on 22/05/2015) >> login as an admin user with sudo to root access >> sudo -i >> ipa-backup >> tar cvfPz ipa004_backups_22052015.tgz /var/lib/ipa/backup >> scp ipa004_backups_22052015.tgz to a backup system, destroy old >> ipamaster VM >> >> 2) Recreate ipamaster VM (identical configuration to original) >> From backup system - >> scp ipa004_backups_22052015.tgz admin at ipa004: >> ssh admin at ipa004 >> su (enter root password - no users with sudo >> access exist yet) >> tar xvfPz ipa004_backups_22052015.tgz >> ipa-restore ipa-full-2015-05-22-17-28-01 >> systemctl stop sssd >> rm -f /var/lib/sss/db/* >> systemctl start sssd > Could ipa-restore do previous 3 operations? > > LS It could - on IPA master that is being restored. We still need to address the other masters and clients... From mkosek at redhat.com Wed May 27 07:31:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 09:31:02 +0200 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: References: <55641791.2020702@redhat.com> Message-ID: <556572B6.40705@redhat.com> On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: > Hello Martin, > > The email deployment it is a groupware in this scenario Kolab, kolab use > 389 ad as main backend and it require some kolab ldap specific attribute to > work properly, this is not a problem in fact is quite easy to use freeipa > as kolab backend, so far so good but the romance only get this far. Since > we also use Windows Ad with forest-trust not all user are present in the > FreeIPA directory and there it is where my problem lays. Since not all user > are in the same box it become difficult to implement one mail system for > all users. Regards As I said, we have compat tree that allows LDAP BIND authentication and LDAP identity (not enumeration) for both IPA users and AD users when realm is in place. You can even update the configuration of the compat tree and add the kolab specific fields to be generated there too. There was very similar request on freeipa-users. It was for vSphere, but dealing with very similar use case and the final solution: http://www.freeipa.org/page/HowTo/vsphere5_integration Would that approach work for you? From abokovoy at redhat.com Wed May 27 08:08:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 May 2015 11:08:53 +0300 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: <556572B6.40705@redhat.com> References: <55641791.2020702@redhat.com> <556572B6.40705@redhat.com> Message-ID: <20150527080853.GJ19176@redhat.com> On Wed, 27 May 2015, Martin Kosek wrote: >On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: >> Hello Martin, >> >> The email deployment it is a groupware in this scenario Kolab, kolab use >> 389 ad as main backend and it require some kolab ldap specific attribute to >> work properly, this is not a problem in fact is quite easy to use freeipa >> as kolab backend, so far so good but the romance only get this far. Since >> we also use Windows Ad with forest-trust not all user are present in the >> FreeIPA directory and there it is where my problem lays. Since not all user >> are in the same box it become difficult to implement one mail system for >> all users. Regards > >As I said, we have compat tree that allows LDAP BIND authentication and LDAP >identity (not enumeration) for both IPA users and AD users when realm is in place. > >You can even update the configuration of the compat tree and add the kolab >specific fields to be generated there too. There was very similar request on >freeipa-users. It was for vSphere, but dealing with very similar use case and >the final solution: > >http://www.freeipa.org/page/HowTo/vsphere5_integration > >Would that approach work for you? I don't think it will work. compat tree is run-time read-only view of the data coming from somewhere else. You need to have Kolab-specific data available somewhere to be able to inject it in the compat tree. Where would that data be stored for Kolab for AD-specific entries? Additionally, Kolab wants to modify these custom attributes and compat tree simply does not support modification, they all are refused. -- / Alexander Bokovoy From barrykfl at gmail.com Wed May 27 08:30:06 2015 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 27 May 2015 16:30:06 +0800 Subject: [Freeipa-users] free ipa cluster replication features Message-ID: hi aLL; i have 2 free ipa in same cluster. if a node1 fail stop... i found the connection of their replciation stop after nod1 fail. now i directly input to the node 2 new accounts , will these new accounts syn back when node 1 start up again.? my issue is that it seem no. Regards Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 27 08:38:55 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 10:38:55 +0200 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: <20150527080853.GJ19176@redhat.com> References: <55641791.2020702@redhat.com> <556572B6.40705@redhat.com> <20150527080853.GJ19176@redhat.com> Message-ID: <5565829F.4090005@redhat.com> On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: > On Wed, 27 May 2015, Martin Kosek wrote: >> On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: >>> Hello Martin, >>> >>> The email deployment it is a groupware in this scenario Kolab, kolab use >>> 389 ad as main backend and it require some kolab ldap specific attribute to >>> work properly, this is not a problem in fact is quite easy to use freeipa >>> as kolab backend, so far so good but the romance only get this far. Since >>> we also use Windows Ad with forest-trust not all user are present in the >>> FreeIPA directory and there it is where my problem lays. Since not all user >>> are in the same box it become difficult to implement one mail system for >>> all users. Regards >> >> As I said, we have compat tree that allows LDAP BIND authentication and LDAP >> identity (not enumeration) for both IPA users and AD users when realm is in >> place. >> >> You can even update the configuration of the compat tree and add the kolab >> specific fields to be generated there too. There was very similar request on >> freeipa-users. It was for vSphere, but dealing with very similar use case and >> the final solution: >> >> http://www.freeipa.org/page/HowTo/vsphere5_integration >> >> Would that approach work for you? > I don't think it will work. compat tree is run-time read-only view of > the data coming from somewhere else. You need to have Kolab-specific > data available somewhere to be able to inject it in the compat tree. > Where would that data be stored for Kolab for AD-specific entries? It would work as long as the attributes are in the "real" user entries in form of custom attributes and compat plugin can be updated to add those to compat view. > Additionally, Kolab wants to modify these custom attributes and compat > tree simply does not support modification, they all are refused. If Kolab requires modifications, then this approach would not work with current FreeIPA implementation, yes. From abokovoy at redhat.com Wed May 27 08:46:48 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 May 2015 11:46:48 +0300 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: <5565829F.4090005@redhat.com> References: <55641791.2020702@redhat.com> <556572B6.40705@redhat.com> <20150527080853.GJ19176@redhat.com> <5565829F.4090005@redhat.com> Message-ID: <20150527084648.GL19176@redhat.com> On Wed, 27 May 2015, Martin Kosek wrote: >On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: >> On Wed, 27 May 2015, Martin Kosek wrote: >>> On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: >>>> Hello Martin, >>>> >>>> The email deployment it is a groupware in this scenario Kolab, kolab use >>>> 389 ad as main backend and it require some kolab ldap specific attribute to >>>> work properly, this is not a problem in fact is quite easy to use freeipa >>>> as kolab backend, so far so good but the romance only get this far. Since >>>> we also use Windows Ad with forest-trust not all user are present in the >>>> FreeIPA directory and there it is where my problem lays. Since not all user >>>> are in the same box it become difficult to implement one mail system for >>>> all users. Regards >>> >>> As I said, we have compat tree that allows LDAP BIND authentication and LDAP >>> identity (not enumeration) for both IPA users and AD users when realm is in >>> place. >>> >>> You can even update the configuration of the compat tree and add the kolab >>> specific fields to be generated there too. There was very similar request on >>> freeipa-users. It was for vSphere, but dealing with very similar use case and >>> the final solution: >>> >>> http://www.freeipa.org/page/HowTo/vsphere5_integration >>> >>> Would that approach work for you? >> I don't think it will work. compat tree is run-time read-only view of >> the data coming from somewhere else. You need to have Kolab-specific >> data available somewhere to be able to inject it in the compat tree. >> Where would that data be stored for Kolab for AD-specific entries? > >It would work as long as the attributes are in the "real" user entries in form >of custom attributes and compat plugin can be updated to add those to compat view. What real user entries you are talking about for AD users? >> Additionally, Kolab wants to modify these custom attributes and compat >> tree simply does not support modification, they all are refused. > >If Kolab requires modifications, then this approach would not work with current >FreeIPA implementation, yes. No, we are not going into enabling modifications over compat tree, this is simply impossible to achieve, sorry. -- / Alexander Bokovoy From Alexander.Frolushkin at megafon.ru Wed May 27 09:06:09 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Wed, 27 May 2015 09:06:09 +0000 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <55648990.2050001@gmail.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> Message-ID: <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> For common information - we also have a "ghost" replica id: unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 and trying to get it away with help of Red Hat support, but at this point - no luck... WBR, Alexander Frolushkin -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle Sent: Tuesday, May 26, 2015 8:56 PM To: thierry bordaz; Martin Kosek Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Haunted servers? On 5/26/15 7:04 AM, thierry bordaz wrote: > On 05/26/2015 08:47 AM, Martin Kosek wrote: >> On 05/26/2015 12:20 AM, Janelle wrote: >>> On 5/24/15 3:12 AM, Janelle wrote: >>>> And just like that, my haunted servers have all returned. >>>> I am going to just put a gun to my head and be done with it. :-( >>>> >>>> Why do things run perfectly and then suddenly ??? >>>> Logs show little to nothing, mostly because the servers are so >>>> busy, they have already rotated out. >>>> >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 22} 55371e9e000000160000 >>>> 553eec64000400160000 >>>> unable to decode {replica 23} 5545d61f000200170000 >>>> 55543240000300170000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> unable to decode {replica 25} 554d78bf000000190000 >>>> 555af302000400190000 >>>> unable to decode {replica 9} 55402c39000300090000 >>>> 55402c39000300090000 >>>> >>>> Don't know what to do anymore. At my wit's end.. >>>> >>>> ~J >>> So things are getting more interesting. Still trying to find the >>> "leaking server(s)". here is what I mean by that. As you see, I >>> continue to find these >>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>> data - it is blank? >> >> Hello Janelle, >> >> Thanks for update. So you worry that there might still be the "rogue >> IPA replica" that would be injecting the wrong replica data? >> >> In any case, I bet Ludwig and Thierry will follow up with your >> thread, there is just delay caused by the various public holidays and >> PTOs this week and we need to rest before digging into the fun with >> RUVs - as you already know yourself :-) >> >>> unable to decode {replica 16} 55356472000300100000 >>> 55356472000300100000 >>> unable to decode {replica 22} 55371e9e000000160000 >>> 553eec64000400160000 >>> unable to decode {replica 24} 554d53d3000100180000 >>> 554d54a4000200180000 >>> unable to decode {replica 25} 554d78bf000200190000 >>> 555af302000400190000 >>> unable to decode {replica 9} >>> >>> Now, if I delete these from a server using the ldapmodify method - >>> they go away briefly, but then if I restart the server, they come >>> back. >>> >>> Let me try to explain -- given a number of servers, say 8, if I user >>> ldapmodify to delete from 1 of those, they seem to go away from >>> maybe 4 of them >>> -- but if >>> I wait a few minutes, it is almost as though "replication" is >>> re-adding these bad replicas from the servers that I have NOT >>> deleted them from. > > On each replica (master/replica) there are one RUV in the database and > one RUV in the changelog. > When cleanallruv succeeds it clears both of them. All replica should > be reachable when you issue cleanallruv, so that it can clean the RUVs > on all the replicas in almost "single" > operation. If some replica are not reachable, they keep information of > about the cleaned RID and then can later propagate those "old" RID to > the rest of the replica. > > Ludwig managed to reproduce the issue with a quite complex test case > (3 replicas and multiple cleanallruv). > We have not yet identified the reason how a cleaned replicaId can get > resurrected. > In parallel we just reproduced it without a clear test case but in a 2 > replica topology. > > >>> >>> So my question is simple - is there something in the logs I can look >>> for that would indicate the SOURCE of these bogus entries? Is the >>> replica 9 with NO extra data any indication of something I could >>> look for? > > I guess that if I have the answer to your question we would have > understood the bug .. > > A little more information to go on: I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? ~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 project ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 From mkosek at redhat.com Wed May 27 09:54:52 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 11:54:52 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 backup and restore In-Reply-To: References: Message-ID: <5565946C.601@redhat.com> On 05/27/2015 04:14 AM, Thomas Lau wrote: > Hi All, > > I was reading this page but seems very confusing: > https://www.freeipa.org/page/V3/Backup_and_Restore#Data_Backup_.26_Restore_Process_.28online.29 We also have this: https://www.freeipa.org/page/Backup_and_Restore > ?ipa-backup and ipa-restore command doesn't exists. What platform do you use? RHEL/CentOS speaking, the command was introduced in 7.1. > I know full system > backup works, but is there have a way to do core Kerberos DB backup? or the > most important DB would be LDAP only?? Yup, this is what ipa-backup does. > ?Other than full system backup, is there have any other way to do backup > and restore for FreeIPA?? ipa-backup/ipa-restore in RHEL-7.1+. From mkosek at redhat.com Wed May 27 09:56:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 11:56:30 +0200 Subject: [Freeipa-users] free ipa cluster replication features In-Reply-To: References: Message-ID: <556594CE.8000208@redhat.com> On 05/27/2015 10:30 AM, barrykfl at gmail.com wrote: > hi aLL; > i have 2 free ipa in same cluster. > > if a node1 fail stop... i found the connection of their replciation stop > after nod1 fail. now i directly input to the node 2 new accounts , > > will these new accounts syn back when node 1 start up again.? > > my issue is that it seem no. > > Regards > > Barry I would suggest following http://www.freeipa.org/page/Troubleshooting#Replication_issues There will probably be a replication error, maybe time is not synced or DNS is broken. From n3g4s at hotmail.com Wed May 27 10:13:14 2015 From: n3g4s at hotmail.com (Ricardo Oliveira) Date: Wed, 27 May 2015 10:13:14 +0000 Subject: [Freeipa-users] Installation on CentOS 6.6 with DNS In-Reply-To: References: , Message-ID: Hi, Thanks for your reply. The host is indeed in the hosts file, and even in the DNS server's "mydomain.com" zone and reverse zone, which is a local Bind instance which is the one I expect IPA to manage once the setup is complete. In fact, if both DNS and reverse DNS resolution are not configured, IPA server setup fails in the beginning with something like "Host not found". Best, Ricardo. Date: Wed, 27 May 2015 06:14:34 +0700 Subject: Re: [Freeipa-users] Installation on CentOS 6.6 with DNS From: dewanggaba at xtremenitro.org To: n3g4s at hotmail.com CC: freeipa-users at redhat.com Have you add your ipa.domain.com ip address on /etc/hosts file? The error seems like your installation can't resolve the ip address. On Wednesday, May 27, 2015, Ricardo Oliveira wrote: Hi, I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option on, using the CentOS provided packages: rpm My problem is that everything is installed except when I use this flag. So, when I run: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U The installation finishes successfully. If I add DNS switches to the installation, it fails almost at the end: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns --no-forwarders Output (clipped): --------------------------------------------------- ... Configuring the web interface (httpd): Estimated time 1 minute [1/13]: setting mod_nss port to 443 [2/13]: setting mod_nss password file [3/13]: enabling mod_nss renegotiate [4/13]: adding URL rewriting rules [5/13]: configuring httpd [6/13]: setting up ssl [7/13]: setting up browser autoconfig [8/13]: publish CA cert [9/13]: creating a keytab for httpd [10/13]: clean up any existing httpd ccache [11/13]: configuring SELinux for httpd [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Can't contact LDAP server [root at ipa ~]# --------------------------------------------------- The screen output is at http://pastebin.com/HKiUwKq4The end of the error log is at http://pastebin.com/jDUhBCL7 (it's a 29 MB file so I only pasted the end of it). If anyone has come across anything like this, I would appreciate your help. Thanks. Ricardo. -- Sent from iDewangga Device -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlau at tetrioncapital.com Wed May 27 10:16:44 2015 From: tlau at tetrioncapital.com (Thomas Lau) Date: Wed, 27 May 2015 18:16:44 +0800 Subject: [Freeipa-users] FreeIPA 3.3.3 backup and restore In-Reply-To: <5565946C.601@redhat.com> References: <5565946C.601@redhat.com> Message-ID: CentOS Linux release 7.0.1406 (Core) <- this is the version we are using now. On Wed, May 27, 2015 at 5:54 PM, Martin Kosek wrote: > On 05/27/2015 04:14 AM, Thomas Lau wrote: > > Hi All, > > > > I was reading this page but seems very confusing: > > > https://www.freeipa.org/page/V3/Backup_and_Restore#Data_Backup_.26_Restore_Process_.28online.29 > > We also have this: > https://www.freeipa.org/page/Backup_and_Restore > > > ?ipa-backup and ipa-restore command doesn't exists. > > What platform do you use? RHEL/CentOS speaking, the command was introduced > in 7.1. > > > I know full system > > backup works, but is there have a way to do core Kerberos DB backup? or > the > > most important DB would be LDAP only?? > > Yup, this is what ipa-backup does. > > > ?Other than full system backup, is there have any other way to do backup > > and restore for FreeIPA?? > > ipa-backup/ipa-restore in RHEL-7.1+. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 27 10:24:12 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 12:24:12 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 backup and restore In-Reply-To: References: <5565946C.601@redhat.com> Message-ID: <55659B4C.1080600@redhat.com> Ok. If you upgrade to CentOS 7.1/FreeIPA 4.1+, you will have the command available. On 05/27/2015 12:16 PM, Thomas Lau wrote: > CentOS Linux release 7.0.1406 (Core) <- this is the version we are using > now. > > On Wed, May 27, 2015 at 5:54 PM, Martin Kosek wrote: > >> On 05/27/2015 04:14 AM, Thomas Lau wrote: >>> Hi All, >>> >>> I was reading this page but seems very confusing: >>> >> https://www.freeipa.org/page/V3/Backup_and_Restore#Data_Backup_.26_Restore_Process_.28online.29 >> >> We also have this: >> https://www.freeipa.org/page/Backup_and_Restore >> >>> ?ipa-backup and ipa-restore command doesn't exists. >> >> What platform do you use? RHEL/CentOS speaking, the command was introduced >> in 7.1. >> >>> I know full system >>> backup works, but is there have a way to do core Kerberos DB backup? or >> the >>> most important DB would be LDAP only?? >> >> Yup, this is what ipa-backup does. >> >>> ?Other than full system backup, is there have any other way to do backup >>> and restore for FreeIPA?? >> >> ipa-backup/ipa-restore in RHEL-7.1+. >> > From holger at layer-acht.org Wed May 27 10:56:00 2015 From: holger at layer-acht.org (Holger Levsen) Date: Wed, 27 May 2015 12:56:00 +0200 Subject: [Freeipa-users] replication on Debian and Ubuntu Message-ID: <201505271256.08051.holger@layer-acht.org> Hi, first of all: thanks for FreeIPA, I think it's pretty usefull, well done and was missing for a long time. IOW: I really like it, thank you for your work! That, I'm having a serious problem with it: replication on Debian doesnt work at all. Which is partly expected (as Debian uses openldap build against gnutls, while Fedora builds openldap against libNSS), so I have rebuild my Debian packages against libNSS too. It still doesnt work. This I have documented extensivly in https://bugs.debian.org/786411 - please have a look at the full story there. I'd be really thankful for any hints resolving this - it could simple be a configuration problem, I think the software should do it. Also, I've heard that 4.2 will be using GSSAPI for replication so this issue should become mood, but we would really like to deploy a (Debian based) FreeIPA server now and not in a few months. (And while FreeIPA is really really cool, without working replication I don't think I can recommend it.) If there is anything I could help with, eg more logs or trying some options or building a patch, I'd be glad to. You can comment directly to https://bugs.debian.org/786411 by sending an email to 786411 at bugs.debian.org - or just reply to this mail / me and I'll append to the bug if its useful. Thanks! cheers, Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: This is a digitally signed message part. URL: From leszek.mis at gmail.com Wed May 27 11:52:05 2015 From: leszek.mis at gmail.com (=?UTF-8?Q?Leszek_Mi=C5=9B?=) Date: Wed, 27 May 2015 13:52:05 +0200 Subject: [Freeipa-users] Web interface session timeout In-Reply-To: <55645640.4050908@redhat.com> References: <55645640.4050908@redhat.com> Message-ID: Thank you! I didn't find it in documentation, could be useful information for someone. 2015-05-26 13:17 GMT+02:00 Petr Vobornik : > On 05/25/2015 09:54 AM, crony wrote: > >> Hi All, >> Is there any way we can change web interface session timeout? I am using >> form based auth. >> >> /lm >> >> > Hi, > > Could be changed by setting: > > session_auth_duration property > > in /etc/ipa/default.conf or /etc/ipa/server.conf > > IPA's default value is '20 minutes' > -- > Petr Vobornik > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 27 13:33:56 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 May 2015 09:33:56 -0400 Subject: [Freeipa-users] replication on Debian and Ubuntu In-Reply-To: <201505271256.08051.holger@layer-acht.org> References: <201505271256.08051.holger@layer-acht.org> Message-ID: <5565C7C4.1000007@redhat.com> Holger Levsen wrote: > Hi, > > first of all: thanks for FreeIPA, I think it's pretty usefull, well done and > was missing for a long time. IOW: I really like it, thank you for your work! > > That, I'm having a serious problem with it: replication on Debian doesnt work > at all. Which is partly expected (as Debian uses openldap build against > gnutls, while Fedora builds openldap against libNSS), so I have rebuild my > Debian packages against libNSS too. It still doesnt work. > > This I have documented extensivly in https://bugs.debian.org/786411 - please > have a look at the full story there. I'd be really thankful for any hints > resolving this - it could simple be a configuration problem, I think the > software should do it. > > Also, I've heard that 4.2 will be using GSSAPI for replication so this issue > should become mood, but we would really like to deploy a (Debian based) > FreeIPA server now and not in a few months. (And while FreeIPA is really > really cool, without working replication I don't think I can recommend it.) > > If there is anything I could help with, eg more logs or trying some options or > building a patch, I'd be glad to. > > You can comment directly to https://bugs.debian.org/786411 by sending an email > to 786411 at bugs.debian.org - or just reply to this mail / me and I'll append to > the bug if its useful. You need to resolve this error: TLS: could not initialize moznss PEM module - error -5977:Failure to load dynamic library. Without this you have no SSL in openldap, so lots of things won't work. This is probably also causing the ldappasswd to fail at the end of ipa-server-install. rob From holger at layer-acht.org Wed May 27 13:46:44 2015 From: holger at layer-acht.org (Holger Levsen) Date: Wed, 27 May 2015 15:46:44 +0200 Subject: [Freeipa-users] replication on Debian and Ubuntu In-Reply-To: <5565C7C4.1000007@redhat.com> References: <201505271256.08051.holger@layer-acht.org> <5565C7C4.1000007@redhat.com> Message-ID: <201505271546.47423.holger@layer-acht.org> Hi Rob, On Mittwoch, 27. Mai 2015, Rob Crittenden wrote: > You need to resolve this error: > > TLS: could not initialize moznss PEM module - error -5977:Failure to > load dynamic library. thanks! I suspected that but it's great to have that confirmed. > Without this you have no SSL in openldap, so lots of things won't work. I'm currently rebuilding krb5 against the openldap build against libnss, to then rebuild libapache-mod-auth-kerb against that same openldap, to then rebuild freeipa against all those. Hoping that this will fix it. > This is probably also causing the ldappasswd to fail at the end of > ipa-server-install. ah! Thanks again, will keep you posted about my progress or failure! :-) cheers, Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: This is a digitally signed message part. URL: From Kurt.Bendl at nrel.gov Wed May 27 17:53:24 2015 From: Kurt.Bendl at nrel.gov (Bendl, Kurt) Date: Wed, 27 May 2015 17:53:24 +0000 Subject: [Freeipa-users] OTP vs VPN Message-ID: Hi, I want to know if I can configure FreeIPA's native OTP solution to require an account to use OTP when authenticating from a specific app (OpenVPN or StrongSwan) but not require 2FA when logging into a system/server or the IPA app. My (not completely baked) thought is to provision the VPN solution by setting up a role or group in IPA that I'd add accounts into. The VPN would allow users of that group to auth, using userid and password+OTP to successfully. I've been reading through docs on the freeipa and red hat sites, e.g., https://www.freeipa.org/page/V4/OTP/Detail and http://www.freeipa.org/page/V4/OTP#Enabling_OTP_and_RADIUS, to determine if or how that might be doable. >From what I read, an alternate approach from FreeIPA's built-in OTP might be to set up a stand-alone OTP solution and use radius and/or a PAM module to handle the VPN auth. I've DL'd the source, but there's so much there it'll take me some time to figure out what's happening. Any pointers on what approach I should take or where to find some notes and examples on how this might be accomplished would be greatly appreciated. Thanks, Kurt From benjamen at dollarshaveclub.com Wed May 27 18:21:11 2015 From: benjamen at dollarshaveclub.com (Benjamen Keroack) Date: Wed, 27 May 2015 11:21:11 -0700 Subject: [Freeipa-users] OTP vs VPN In-Reply-To: References: Message-ID: We've found it easier to integrate a 2FA solution into OpenVPN and local login separately. If you go with a solution that works with PAM, setting it up with OpenVPN Access Server (the commercial product) and local login (FreeIPA-backed) is pretty straightforward. The only thing it won't protect is the FreeIPA web UI, but if you put that behind a VPN or IP whitelist it should be less of an issue. Ben On Wed, May 27, 2015 at 10:53 AM, Bendl, Kurt wrote: > Hi, > > I want to know if I can configure FreeIPA's native OTP solution to require > an account to use OTP when authenticating from a specific app (OpenVPN or > StrongSwan) but not require 2FA when logging into a system/server or the > IPA app. > > My (not completely baked) thought is to provision the VPN solution by > setting up a role or group in IPA that I'd add accounts into. The VPN would > allow users of that group to auth, using userid and password+OTP to > successfully. > > I've been reading through docs on the freeipa and red hat sites, e.g., > https://www.freeipa.org/page/V4/OTP/Detail and > http://www.freeipa.org/page/V4/OTP#Enabling_OTP_and_RADIUS, to determine > if or how that might be doable. > > >From what I read, an alternate approach from FreeIPA's built-in OTP might > be to set up a stand-alone OTP solution and use radius and/or a PAM module > to handle the VPN auth. > > I've DL'd the source, but there's so much there it'll take me some time to > figure out what's happening. > > Any pointers on what approach I should take or where to find some notes > and examples on how this might be accomplished would be greatly appreciated. > > Thanks, > Kurt > > > -- > 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 > -- Benjamen Keroack *Infrastructure/DevOps Engineer* benjamen at dollarshaveclub.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed May 27 18:33:25 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 May 2015 21:33:25 +0300 Subject: [Freeipa-users] OTP vs VPN In-Reply-To: References: Message-ID: <20150527183325.GU19176@redhat.com> On Wed, 27 May 2015, Bendl, Kurt wrote: >Hi, > >I want to know if I can configure FreeIPA's native OTP solution to >require an account to use OTP when authenticating from a specific app >(OpenVPN or StrongSwan) but not require 2FA when logging into a >system/server or the IPA app. > >My (not completely baked) thought is to provision the VPN solution by >setting up a role or group in IPA that I'd add accounts into. The VPN >would allow users of that group to auth, using userid and password+OTP >to successfully. > >I've been reading through docs on the freeipa and red hat sites, e.g., >https://www.freeipa.org/page/V4/OTP/Detail and >http://www.freeipa.org/page/V4/OTP#Enabling_OTP_and_RADIUS, to >determine if or how that might be doable. > >>From what I read, an alternate approach from FreeIPA's built-in OTP >>might be to set up a stand-alone OTP solution and use radius and/or a >>PAM module to handle the VPN auth. > >I've DL'd the source, but there's so much there it'll take me some time >to figure out what's happening. > >Any pointers on what approach I should take or where to find some notes >and examples on how this might be accomplished would be greatly >appreciated. There is no way to define per-service target 2FA yet in FreeIPA. Setting up OpenVPN against IPA is easy. Use HBAC rules to confine who can access there. As for forcing 2FA for such access, my only suggestion right now is to have separate user accounts for this purpose. Let's say, they would be prefixed with vpn- (vpn-userfoo, for example), and then tokens can be assigned to them. -- / Alexander Bokovoy From nathan at nathanpeters.com Wed May 27 21:22:34 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 27 May 2015 14:22:34 -0700 Subject: [Freeipa-users] dereference processing failed : Invalid argument Message-ID: <14a1b03db37ff7fa5c6e821cd6338c5d.squirrel@webmail.nathanpeters.com> I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when one of my FreeIPA users tries to sudo (he has permissions via group membership) I get the following error in /var/log/messages May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing failed : Invalid argument I have read that this is a known bug (https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the suggested fix is to add the following line to the domain section of the sssd.conf : ldap_group_object_class = ipaUserGroup I tried adding that and then restarting the client, but it did not fix the problem. I have also read that this problem may only apply to POSIX groups so I removed my user from all POSIX groups, added him to non posix groups and then created some new sudo rules and hbac rules. I restarted the client again and still had the same issue where I could login but not sudo. Is there a known workaround that actually works? I see this bug is supposed to be fixed in sssd 1.11.8. Is this version of sssd going to be released into any repo for CentOS 6? I just had a look at the CentOS 6 updates repo and sssd is still at 1.11.6-30 From carlosla1987 at gmail.com Wed May 27 23:26:53 2015 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Wed, 27 May 2015 19:26:53 -0400 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: <20150527084648.GL19176@redhat.com> References: <55641791.2020702@redhat.com> <556572B6.40705@redhat.com> <20150527080853.GJ19176@redhat.com> <5565829F.4090005@redhat.com> <20150527084648.GL19176@redhat.com> Message-ID: Hello Martin, Alexander Seem that the time shift is large between us, If i understand correctly, compat tree will allow me to see all users, regardless they location Windows or FreeIPA, however the kolab-specific attribute must come from FreeIPA and Windows AD where the users entries lays. This means creating custom object classes and attributes for AD schema them update compat plugin to see the custom attribute. The second part where kolab needs to update some value in any of this attribute, for example mailQuota it would be rejected and therefor it must be done from Windows AD or FreeIPA, is this correct? Thanks both of you for your time and input in this matter. Regards 2015-05-27 4:46 GMT-04:00 Alexander Bokovoy : > On Wed, 27 May 2015, Martin Kosek wrote: > >> On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: >> >>> On Wed, 27 May 2015, Martin Kosek wrote: >>> >>>> On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: >>>> >>>>> Hello Martin, >>>>> >>>>> The email deployment it is a groupware in this scenario Kolab, kolab >>>>> use >>>>> 389 ad as main backend and it require some kolab ldap specific >>>>> attribute to >>>>> work properly, this is not a problem in fact is quite easy to use >>>>> freeipa >>>>> as kolab backend, so far so good but the romance only get this far. >>>>> Since >>>>> we also use Windows Ad with forest-trust not all user are present in >>>>> the >>>>> FreeIPA directory and there it is where my problem lays. Since not all >>>>> user >>>>> are in the same box it become difficult to implement one mail system >>>>> for >>>>> all users. Regards >>>>> >>>> >>>> As I said, we have compat tree that allows LDAP BIND authentication and >>>> LDAP >>>> identity (not enumeration) for both IPA users and AD users when realm >>>> is in >>>> place. >>>> >>>> You can even update the configuration of the compat tree and add the >>>> kolab >>>> specific fields to be generated there too. There was very similar >>>> request on >>>> freeipa-users. It was for vSphere, but dealing with very similar use >>>> case and >>>> the final solution: >>>> >>>> http://www.freeipa.org/page/HowTo/vsphere5_integration >>>> >>>> Would that approach work for you? >>>> >>> I don't think it will work. compat tree is run-time read-only view of >>> the data coming from somewhere else. You need to have Kolab-specific >>> data available somewhere to be able to inject it in the compat tree. >>> Where would that data be stored for Kolab for AD-specific entries? >>> >> >> It would work as long as the attributes are in the "real" user entries in >> form >> of custom attributes and compat plugin can be updated to add those to >> compat view. >> > What real user entries you are talking about for AD users? > > Additionally, Kolab wants to modify these custom attributes and compat >>> tree simply does not support modification, they all are refused. >>> >> >> If Kolab requires modifications, then this approach would not work with >> current >> FreeIPA implementation, yes. >> > No, we are not going into enabling modifications over compat tree, this > is simply impossible to achieve, sorry. > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Wed May 27 23:27:45 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 27 May 2015 16:27:45 -0700 Subject: [Freeipa-users] dereference processing failed : Invalid argument In-Reply-To: <14a1b03db37ff7fa5c6e821cd6338c5d.squirrel@webmail.nathanpeters.com> References: <14a1b03db37ff7fa5c6e821cd6338c5d.squirrel@webmail.nathanpeters.com> Message-ID: <0438849cf1be7cc037472ba0f8eec677.squirrel@webmail.nathanpeters.com> > I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when > one of my FreeIPA users tries to sudo (he has permissions via group > membership) I get the following error in /var/log/messages > > May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing > failed : Invalid argument > > I have read that this is a known bug > (https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the > suggested fix is to add the following line to the domain section of the > sssd.conf : > > ldap_group_object_class = ipaUserGroup > > I tried adding that and then restarting the client, but it did not fix the > problem. I have also read that this problem may only apply to POSIX > groups so I removed my user from all POSIX groups, added him to non posix > groups and then created some new sudo rules and hbac rules. I restarted > the client again and still had the same issue where I could login but not > sudo. > > Is there a known workaround that actually works? > > I see this bug is supposed to be fixed in sssd 1.11.8. Is this version of > sssd going to be released into any repo for CentOS 6? > > I just had a look at the CentOS 6 updates repo and sssd is still at > 1.11.6-30 > > > -- Well, I found that if I updated to CentOS 6.5 and then put the user in all non posix groups and renamed my sudo rules so they were different names than my hbac rules I could finally log in and sudo properly with no messing with my sssd.conf file. Nothing I tried in CentOS 6.3 would work though. From janellenicole80 at gmail.com Thu May 28 01:26:49 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 27 May 2015 18:26:49 -0700 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <55647D62.4090800@redhat.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> Message-ID: <55666ED9.8010709@gmail.com> On 5/26/15 7:04 AM, thierry bordaz wrote: > On 05/26/2015 08:47 AM, Martin Kosek wrote: >> On 05/26/2015 12:20 AM, Janelle wrote: >>> On 5/24/15 3:12 AM, Janelle wrote: >>>> And just like that, my haunted servers have all returned. >>>> I am going to just put a gun to my head and be done with it. :-( >>>> >>>> Why do things run perfectly and then suddenly ??? >>>> Logs show little to nothing, mostly because the servers are so >>>> busy, they >>>> have already rotated out. >>>> >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 22} 55371e9e000000160000 >>>> 553eec64000400160000 >>>> unable to decode {replica 23} 5545d61f000200170000 >>>> 55543240000300170000 >>>> unable to decode {replica 24} 554d53d3000000180000 >>>> 554d54a4000200180000 >>>> unable to decode {replica 25} 554d78bf000000190000 >>>> 555af302000400190000 >>>> unable to decode {replica 9} 55402c39000300090000 >>>> 55402c39000300090000 >>>> >>>> Don't know what to do anymore. At my wit's end.. >>>> >>>> ~J >>> So things are getting more interesting. Still trying to find the >>> "leaking >>> server(s)". here is what I mean by that. As you see, I continue to >>> find these >>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>> data - it is >>> blank? >> >> Hello Janelle, >> >> Thanks for update. So you worry that there might still be the "rogue >> IPA replica" that would be injecting the wrong replica data? >> >> In any case, I bet Ludwig and Thierry will follow up with your >> thread, there is just delay caused by the various public holidays and >> PTOs this week and we need to rest before digging into the fun with >> RUVs - as you already know yourself :-) >> >>> unable to decode {replica 16} 55356472000300100000 >>> 55356472000300100000 >>> unable to decode {replica 22} 55371e9e000000160000 >>> 553eec64000400160000 >>> unable to decode {replica 24} 554d53d3000100180000 >>> 554d54a4000200180000 >>> unable to decode {replica 25} 554d78bf000200190000 >>> 555af302000400190000 >>> unable to decode {replica 9} >>> >>> Now, if I delete these from a server using the ldapmodify method - >>> they go away >>> briefly, but then if I restart the server, they come back. >>> >>> Let me try to explain -- given a number of servers, say 8, if I user >>> ldapmodify >>> to delete from 1 of those, they seem to go away from maybe 4 of them >>> -- but if >>> I wait a few minutes, it is almost as though "replication" is >>> re-adding these >>> bad replicas from the servers that I have NOT deleted them from. > > On each replica (master/replica) there are one RUV in the database and > one RUV in the changelog. > When cleanallruv succeeds it clears both of them. All replica should > be reachable when you issue cleanallruv, so that > it can clean the RUVs on all the replicas in almost "single" > operation. If some replica are not reachable, they keep > information of about the cleaned RID and then can later propagate > those "old" RID to the rest of the replica. > > Ludwig managed to reproduce the issue with a quite complex test case > (3 replicas and multiple cleanallruv). > We have not yet identified the reason how a cleaned replicaId can get > resurrected. > In parallel we just reproduced it without a clear test case but in a 2 > replica topology. > After spending well over 2 days trying to clean things -- I am now here: CLEANALLRUV tasks RID 16 Not all replicas finished cleaning, retrying in 14400 seconds RID 19 None RID 22 None What is going on here? All the same data still exists as shown above in the original thread, but I seem to be stuck. I know I am not the only person having replica issues. Is there anything else I can try? ~J From abokovoy at redhat.com Thu May 28 04:25:35 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 28 May 2015 07:25:35 +0300 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: References: <55641791.2020702@redhat.com> <556572B6.40705@redhat.com> <20150527080853.GJ19176@redhat.com> <5565829F.4090005@redhat.com> <20150527084648.GL19176@redhat.com> Message-ID: <20150528042535.GY19176@redhat.com> On Wed, 27 May 2015, Carlos Ra?l Laguna wrote: >Hello Martin, Alexander > >Seem that the time shift is large between us, If i understand correctly, >compat tree will allow me to see all users, regardless they location >Windows or FreeIPA, however the kolab-specific attribute must come from >FreeIPA and Windows AD where the users entries lays. This means creating >custom object classes and attributes for AD schema them update compat >plugin to see the custom attribute. > >The second part where kolab needs to update some value in any of this >attribute, for example mailQuota it would be rejected and therefor it must >be done from Windows AD or FreeIPA, is this correct? Thanks both of you for >your time and input in this matter. Regards Just to make you absolutely clear: using compat tree will not help you at all. Nothing else in FreeIPA could help you in getting Kolab to work with both IPA and AD users at the same time. It would be nice if kolab could grow a capability to connect to multiple LDAP servers at the same time, with non-overlapping user and group trees. I don't think it is there now and I don't see other possibilities here. > >2015-05-27 4:46 GMT-04:00 Alexander Bokovoy : > >> On Wed, 27 May 2015, Martin Kosek wrote: >> >>> On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: >>> >>>> On Wed, 27 May 2015, Martin Kosek wrote: >>>> >>>>> On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: >>>>> >>>>>> Hello Martin, >>>>>> >>>>>> The email deployment it is a groupware in this scenario Kolab, kolab >>>>>> use >>>>>> 389 ad as main backend and it require some kolab ldap specific >>>>>> attribute to >>>>>> work properly, this is not a problem in fact is quite easy to use >>>>>> freeipa >>>>>> as kolab backend, so far so good but the romance only get this far. >>>>>> Since >>>>>> we also use Windows Ad with forest-trust not all user are present in >>>>>> the >>>>>> FreeIPA directory and there it is where my problem lays. Since not all >>>>>> user >>>>>> are in the same box it become difficult to implement one mail system >>>>>> for >>>>>> all users. Regards >>>>>> >>>>> >>>>> As I said, we have compat tree that allows LDAP BIND authentication and >>>>> LDAP >>>>> identity (not enumeration) for both IPA users and AD users when realm >>>>> is in >>>>> place. >>>>> >>>>> You can even update the configuration of the compat tree and add the >>>>> kolab >>>>> specific fields to be generated there too. There was very similar >>>>> request on >>>>> freeipa-users. It was for vSphere, but dealing with very similar use >>>>> case and >>>>> the final solution: >>>>> >>>>> http://www.freeipa.org/page/HowTo/vsphere5_integration >>>>> >>>>> Would that approach work for you? >>>>> >>>> I don't think it will work. compat tree is run-time read-only view of >>>> the data coming from somewhere else. You need to have Kolab-specific >>>> data available somewhere to be able to inject it in the compat tree. >>>> Where would that data be stored for Kolab for AD-specific entries? >>>> >>> >>> It would work as long as the attributes are in the "real" user entries in >>> form >>> of custom attributes and compat plugin can be updated to add those to >>> compat view. >>> >> What real user entries you are talking about for AD users? >> >> Additionally, Kolab wants to modify these custom attributes and compat >>>> tree simply does not support modification, they all are refused. >>>> >>> >>> If Kolab requires modifications, then this approach would not work with >>> current >>> FreeIPA implementation, yes. >>> >> No, we are not going into enabling modifications over compat tree, this >> is simply impossible to achieve, sorry. >> -- >> / 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 -- / Alexander Bokovoy From christoph.kaminski at biotronik.com Thu May 28 05:18:01 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Thu, 28 May 2015 07:18:01 +0200 Subject: [Freeipa-users] Antwort: Re: Haunted servers? In-Reply-To: <55666ED9.8010709@gmail.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55666ED9.8010709@gmail.com> Message-ID: > > After spending well over 2 days trying to clean things -- I am now here: > > CLEANALLRUV tasks > RID 16 Not all replicas finished cleaning, retrying in 14400 seconds > RID 19 None > RID 22 None > > What is going on here? All the same data still exists as shown above in > the original thread, but I seem to be stuck. I know I am not the only > person having replica issues. Is there anything else I can try? > > ~J > we have the same problem here... additionally we cant delete/disconnect defect replica see here: https://access.redhat.com/support/cases/#/case/01429034?commentId=a0aA000000DjxzgIAB its seems to be a very big problem of 389ds/IPA and no solution at this time (sad for software what (supposedly) has an enterprise level) MfG Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu May 28 06:52:11 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 08:52:11 +0200 Subject: [Freeipa-users] Installation on CentOS 6.6 with DNS In-Reply-To: References: , Message-ID: <5566BB1B.1050800@redhat.com> Hello, I think that this more related to LDAP server than to DNS server. Could you system check logs (journalctl or /var/log/messages) to see if ns-slapd process crashed or something like that? Petr^2 Spacek On 27.5.2015 12:13, Ricardo Oliveira wrote: > Hi, > > Thanks for your reply. The host is indeed in the hosts file, > and even in the DNS server's "mydomain.com" zone and reverse zone, which > is a local Bind instance which is the one I expect IPA to manage once > the setup is complete. > In fact, if both DNS and reverse DNS > resolution are not configured, IPA server setup fails in the beginning > with something like "Host not found". > > Best, > Ricardo. > > Date: Wed, 27 May 2015 06:14:34 +0700 > Subject: Re: [Freeipa-users] Installation on CentOS 6.6 with DNS > From: dewanggaba at xtremenitro.org > To: n3g4s at hotmail.com > CC: freeipa-users at redhat.com > > Have you add your ipa.domain.com ip address on /etc/hosts file? The error seems like your installation can't resolve the ip address. > On Wednesday, May 27, 2015, Ricardo Oliveira wrote: > > > > > > > > > > Hi, > > I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option on, using the CentOS provided packages: > > rpm > > My problem is that everything is installed except when I use this flag. > So, when I run: > > ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U > > The installation finishes successfully. > If I add DNS switches to the installation, it fails almost at the end: > > ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns --no-forwarders > > Output (clipped): > --------------------------------------------------- > ... > Configuring the web interface (httpd): Estimated time 1 minute > [1/13]: setting mod_nss port to 443 > [2/13]: setting mod_nss password file > [3/13]: enabling mod_nss renegotiate > [4/13]: adding URL rewriting rules > [5/13]: configuring httpd > [6/13]: setting up ssl > [7/13]: setting up browser autoconfig > [8/13]: publish CA cert > [9/13]: creating a keytab for httpd > [10/13]: clean up any existing httpd ccache > [11/13]: configuring SELinux for httpd > [12/13]: restarting httpd > [13/13]: configuring httpd to start on boot > Done configuring the web interface (httpd). > Applying LDAP updates > Restarting the directory server > Restarting the KDC > Can't contact LDAP server > [root at ipa ~]# > --------------------------------------------------- > The screen output is at http://pastebin.com/HKiUwKq4The end of the error log is at http://pastebin.com/jDUhBCL7 (it's a 29 MB file so I only pasted the end of it). > If anyone has come across anything like this, I would appreciate your help. > Thanks. > Ricardo. > > > > > > > -- Petr^2 Spacek From jhrozek at redhat.com Thu May 28 07:09:38 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 28 May 2015 09:09:38 +0200 Subject: [Freeipa-users] dereference processing failed : Invalid argument In-Reply-To: <0438849cf1be7cc037472ba0f8eec677.squirrel@webmail.nathanpeters.com> References: <14a1b03db37ff7fa5c6e821cd6338c5d.squirrel@webmail.nathanpeters.com> <0438849cf1be7cc037472ba0f8eec677.squirrel@webmail.nathanpeters.com> Message-ID: <20150528070938.GA788@hendrix.arn.redhat.com> On Wed, May 27, 2015 at 04:27:45PM -0700, nathan at nathanpeters.com wrote: > > I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when > > one of my FreeIPA users tries to sudo (he has permissions via group > > membership) I get the following error in /var/log/messages > > > > May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing > > failed : Invalid argument > > > > I have read that this is a known bug > > (https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the > > suggested fix is to add the following line to the domain section of the > > sssd.conf : > > > > ldap_group_object_class = ipaUserGroup > > > > I tried adding that and then restarting the client, but it did not fix the > > problem. I have also read that this problem may only apply to POSIX > > groups so I removed my user from all POSIX groups, added him to non posix > > groups and then created some new sudo rules and hbac rules. I restarted > > the client again and still had the same issue where I could login but not > > sudo. > > > > Is there a known workaround that actually works? > > > > I see this bug is supposed to be fixed in sssd 1.11.8. Is this version of > > sssd going to be released into any repo for CentOS 6? > > > > I just had a look at the CentOS 6 updates repo and sssd is still at > > 1.11.6-30 > > > > > > -- > > Well, I found that if I updated to CentOS 6.5 and then put the user in all > non posix groups and renamed my sudo rules so they were different names > than my hbac rules I could finally log in and sudo properly with no > messing with my sssd.conf file. > > Nothing I tried in CentOS 6.3 would work though. btw in upstream we relaxed the dereference processing a bit and now we just skip the faulty rules. From tbordaz at redhat.com Thu May 28 07:23:51 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 28 May 2015 09:23:51 +0200 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> Message-ID: <5566C287.7070708@redhat.com> Hello Alexander, Cleanallruv can hang to do the cleanup (depending on task options and if replica are reachable). Did you try using CLEANRUV that is a more basic tool but that should not fail to do the cleanup. Before using cleanruv, you need to abort all cleanallruv pending tasks. Then for each RID that you want to clean, you have to log on each replica and run dn: cn=replica,cn=,cn=mapping tree,cn=config changetype: modify replace: nsds5task nsds5task:CLEANRUV This task should succeeds but there is possibility that a given RID resurects in case a replication session occurs before all cleanRUV are completed. So we may have to do cleanRUV a second time. thanks thierry On 05/27/2015 11:06 AM, Alexander Frolushkin wrote: > For common information - we also have a "ghost" replica id: > unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 > and trying to get it away with help of Red Hat support, but at this point - no luck... > > WBR, > Alexander Frolushkin > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle > Sent: Tuesday, May 26, 2015 8:56 PM > To: thierry bordaz; Martin Kosek > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Haunted servers? > > On 5/26/15 7:04 AM, thierry bordaz wrote: >> On 05/26/2015 08:47 AM, Martin Kosek wrote: >>> On 05/26/2015 12:20 AM, Janelle wrote: >>>> On 5/24/15 3:12 AM, Janelle wrote: >>>>> And just like that, my haunted servers have all returned. >>>>> I am going to just put a gun to my head and be done with it. :-( >>>>> >>>>> Why do things run perfectly and then suddenly ??? >>>>> Logs show little to nothing, mostly because the servers are so >>>>> busy, they have already rotated out. >>>>> >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>> 553eec64000400160000 >>>>> unable to decode {replica 23} 5545d61f000200170000 >>>>> 55543240000300170000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> unable to decode {replica 25} 554d78bf000000190000 >>>>> 555af302000400190000 >>>>> unable to decode {replica 9} 55402c39000300090000 >>>>> 55402c39000300090000 >>>>> >>>>> Don't know what to do anymore. At my wit's end.. >>>>> >>>>> ~J >>>> So things are getting more interesting. Still trying to find the >>>> "leaking server(s)". here is what I mean by that. As you see, I >>>> continue to find these >>>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>>> data - it is blank? >>> Hello Janelle, >>> >>> Thanks for update. So you worry that there might still be the "rogue >>> IPA replica" that would be injecting the wrong replica data? >>> >>> In any case, I bet Ludwig and Thierry will follow up with your >>> thread, there is just delay caused by the various public holidays and >>> PTOs this week and we need to rest before digging into the fun with >>> RUVs - as you already know yourself :-) >>> >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 22} 55371e9e000000160000 >>>> 553eec64000400160000 >>>> unable to decode {replica 24} 554d53d3000100180000 >>>> 554d54a4000200180000 >>>> unable to decode {replica 25} 554d78bf000200190000 >>>> 555af302000400190000 >>>> unable to decode {replica 9} >>>> >>>> Now, if I delete these from a server using the ldapmodify method - >>>> they go away briefly, but then if I restart the server, they come >>>> back. >>>> >>>> Let me try to explain -- given a number of servers, say 8, if I user >>>> ldapmodify to delete from 1 of those, they seem to go away from >>>> maybe 4 of them >>>> -- but if >>>> I wait a few minutes, it is almost as though "replication" is >>>> re-adding these bad replicas from the servers that I have NOT >>>> deleted them from. >> On each replica (master/replica) there are one RUV in the database and >> one RUV in the changelog. >> When cleanallruv succeeds it clears both of them. All replica should >> be reachable when you issue cleanallruv, so that it can clean the RUVs >> on all the replicas in almost "single" >> operation. If some replica are not reachable, they keep information of >> about the cleaned RID and then can later propagate those "old" RID to >> the rest of the replica. >> >> Ludwig managed to reproduce the issue with a quite complex test case >> (3 replicas and multiple cleanallruv). >> We have not yet identified the reason how a cleaned replicaId can get >> resurrected. >> In parallel we just reproduced it without a clear test case but in a 2 >> replica topology. >> >> >>>> So my question is simple - is there something in the logs I can look >>>> for that would indicate the SOURCE of these bogus entries? Is the >>>> replica 9 with NO extra data any indication of something I could >>>> look for? >> I guess that if I have the answer to your question we would have >> understood the bug .. >> >> > A little more information to go on: > > I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. > I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. > > I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. > > Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? > > ~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 project > > ________________________________ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. > > (c)20mf50 > From lslebodn at redhat.com Thu May 28 07:30:38 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 28 May 2015 09:30:38 +0200 Subject: [Freeipa-users] dereference processing failed : Invalid argument In-Reply-To: <14a1b03db37ff7fa5c6e821cd6338c5d.squirrel@webmail.nathanpeters.com> References: <14a1b03db37ff7fa5c6e821cd6338c5d.squirrel@webmail.nathanpeters.com> Message-ID: <20150528073037.GA28046@mail.corp.redhat.com> On (27/05/15 14:22), nathan at nathanpeters.com wrote: >I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when >one of my FreeIPA users tries to sudo (he has permissions via group >membership) I get the following error in /var/log/messages > >May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing >failed : Invalid argument > >I have read that this is a known bug >(https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the >suggested fix is to add the following line to the domain section of the >sssd.conf : > >ldap_group_object_class = ipaUserGroup > You cannot hit BZ1154042, because it is already fixed in 1.11.6-30.el6_6.4 @see https://bugzilla.redhat.com/show_bug.cgi?id=1165074 >I tried adding that and then restarting the client, but it did not fix the >problem. I have also read that this problem may only apply to POSIX >groups so I removed my user from all POSIX groups, added him to non posix >groups and then created some new sudo rules and hbac rules. I restarted >the client again and still had the same issue where I could login but not >sudo. > >Is there a known workaround that actually works? > >I see this bug is supposed to be fixed in sssd 1.11.8. Is this version of >sssd going to be released into any repo for CentOS 6? > No 1.11.8 will not be release in CentOS 6. CentOS just rebuild rhel src.rpm packages. However rhel 6.7-beta has already sssd-1.12.4-x. If you want you can test with pre-release of upstream 1.12.5 https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ LS From Alexander.Frolushkin at megafon.ru Thu May 28 07:33:16 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Thu, 28 May 2015 07:33:16 +0000 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <5566C287.7070708@redhat.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> Message-ID: <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> Hello! Thank you for this info. Things seems to be complicated for now... We have this: "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" on all of our 17 servers. After launching cleanallruv we have it disappeared from 16 servers and one server hangs (any requests addressed ldap just freezes, including "ipactl status"). After dirsrv restart (via "systemctl restart ipa") I found "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" on this server (and only on it), run cleanallruv and get it from this server, but right after that unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 reappeared on three other servers. Now I'm waiting response from support, they requested dirsrv logs form hanged server and from servers where error appeared again. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 -----Original Message----- From: thierry bordaz [mailto:tbordaz at redhat.com] Sent: Thursday, May 28, 2015 1:24 PM To: Alexander Frolushkin (SIB) Cc: freeipa-users at redhat.com; 'Janelle' Subject: Re: [Freeipa-users] Haunted servers? Hello Alexander, Cleanallruv can hang to do the cleanup (depending on task options and if replica are reachable). Did you try using CLEANRUV that is a more basic tool but that should not fail to do the cleanup. Before using cleanruv, you need to abort all cleanallruv pending tasks. Then for each RID that you want to clean, you have to log on each replica and run dn: cn=replica,cn=,cn=mapping tree,cn=config changetype: modify replace: nsds5task nsds5task:CLEANRUV This task should succeeds but there is possibility that a given RID resurects in case a replication session occurs before all cleanRUV are completed. So we may have to do cleanRUV a second time. thanks thierry On 05/27/2015 11:06 AM, Alexander Frolushkin wrote: > For common information - we also have a "ghost" replica id: > unable to decode: {replica 16} 548a8126000000100000 > 548a8126000000100000 and trying to get it away with help of Red Hat support, but at this point - no luck... > > WBR, > Alexander Frolushkin > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle > Sent: Tuesday, May 26, 2015 8:56 PM > To: thierry bordaz; Martin Kosek > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Haunted servers? > > On 5/26/15 7:04 AM, thierry bordaz wrote: >> On 05/26/2015 08:47 AM, Martin Kosek wrote: >>> On 05/26/2015 12:20 AM, Janelle wrote: >>>> On 5/24/15 3:12 AM, Janelle wrote: >>>>> And just like that, my haunted servers have all returned. >>>>> I am going to just put a gun to my head and be done with it. :-( >>>>> >>>>> Why do things run perfectly and then suddenly ??? >>>>> Logs show little to nothing, mostly because the servers are so >>>>> busy, they have already rotated out. >>>>> >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>> 553eec64000400160000 >>>>> unable to decode {replica 23} 5545d61f000200170000 >>>>> 55543240000300170000 >>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>> 554d54a4000200180000 >>>>> unable to decode {replica 25} 554d78bf000000190000 >>>>> 555af302000400190000 >>>>> unable to decode {replica 9} 55402c39000300090000 >>>>> 55402c39000300090000 >>>>> >>>>> Don't know what to do anymore. At my wit's end.. >>>>> >>>>> ~J >>>> So things are getting more interesting. Still trying to find the >>>> "leaking server(s)". here is what I mean by that. As you see, I >>>> continue to find these >>>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>>> data - it is blank? >>> Hello Janelle, >>> >>> Thanks for update. So you worry that there might still be the "rogue >>> IPA replica" that would be injecting the wrong replica data? >>> >>> In any case, I bet Ludwig and Thierry will follow up with your >>> thread, there is just delay caused by the various public holidays >>> and PTOs this week and we need to rest before digging into the fun >>> with RUVs - as you already know yourself :-) >>> >>>> unable to decode {replica 16} 55356472000300100000 >>>> 55356472000300100000 >>>> unable to decode {replica 22} 55371e9e000000160000 >>>> 553eec64000400160000 >>>> unable to decode {replica 24} 554d53d3000100180000 >>>> 554d54a4000200180000 >>>> unable to decode {replica 25} 554d78bf000200190000 >>>> 555af302000400190000 >>>> unable to decode {replica 9} >>>> >>>> Now, if I delete these from a server using the ldapmodify method - >>>> they go away briefly, but then if I restart the server, they come >>>> back. >>>> >>>> Let me try to explain -- given a number of servers, say 8, if I >>>> user ldapmodify to delete from 1 of those, they seem to go away >>>> from maybe 4 of them >>>> -- but if >>>> I wait a few minutes, it is almost as though "replication" is >>>> re-adding these bad replicas from the servers that I have NOT >>>> deleted them from. >> On each replica (master/replica) there are one RUV in the database >> and one RUV in the changelog. >> When cleanallruv succeeds it clears both of them. All replica should >> be reachable when you issue cleanallruv, so that it can clean the >> RUVs on all the replicas in almost "single" >> operation. If some replica are not reachable, they keep information >> of about the cleaned RID and then can later propagate those "old" RID >> to the rest of the replica. >> >> Ludwig managed to reproduce the issue with a quite complex test case >> (3 replicas and multiple cleanallruv). >> We have not yet identified the reason how a cleaned replicaId can get >> resurrected. >> In parallel we just reproduced it without a clear test case but in a >> 2 replica topology. >> >> >>>> So my question is simple - is there something in the logs I can >>>> look for that would indicate the SOURCE of these bogus entries? Is >>>> the replica 9 with NO extra data any indication of something I >>>> could look for? >> I guess that if I have the answer to your question we would have >> understood the bug .. >> >> > A little more information to go on: > > I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. > I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. > > I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. > > Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? > > ~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 project > > ________________________________ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. > > (c)20mf50 > ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 From tbordaz at redhat.com Thu May 28 07:49:27 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 28 May 2015 09:49:27 +0200 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> Message-ID: <5566C887.4050206@redhat.com> On 05/28/2015 09:33 AM, Alexander Frolushkin wrote: > Hello! > Thank you for this info. > > Things seems to be complicated for now... > We have this: > "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" > on all of our 17 servers. > After launching cleanallruv we have it disappeared from 16 servers and one server hangs (any requests addressed ldap just freezes, including "ipactl status"). After dirsrv restart (via "systemctl restart ipa") I found > "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" > on this server (and only on it), run cleanallruv and get it from this server, but right after that > unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 > reappeared on three other servers. Hello, Yes this is exactly why cleanallruv is the first tool to use, it does the job on all replicas. When you restarted the hanging server, some (3) of them established a replication session with it and "learned" this old/invalid RUVelement. Janelle, Alexander, do you remember if you ran the command : 'ipa-replica-manage del --force --clean'. (with the option --force and --clean) ? thanks thierry > Now I'm waiting response from support, they requested dirsrv logs form hanged server and from servers where error appeared again. > > WBR, > Alexander Frolushkin > Cell +79232508764 > Work +79232507764 > > > -----Original Message----- > From: thierry bordaz [mailto:tbordaz at redhat.com] > Sent: Thursday, May 28, 2015 1:24 PM > To: Alexander Frolushkin (SIB) > Cc: freeipa-users at redhat.com; 'Janelle' > Subject: Re: [Freeipa-users] Haunted servers? > > Hello Alexander, > > Cleanallruv can hang to do the cleanup (depending on task options and if replica are reachable). > Did you try using CLEANRUV that is a more basic tool but that should not fail to do the cleanup. > > Before using cleanruv, you need to abort all cleanallruv pending tasks. > > Then for each RID that you want to clean, you have to log on each replica and run > dn: cn=replica,cn=,cn=mapping tree,cn=config > changetype: modify > replace: nsds5task > nsds5task:CLEANRUV > > This task should succeeds but there is possibility that a given RID resurects in case a replication session occurs before all cleanRUV are completed. > So we may have to do cleanRUV a second time. > > thanks > thierry > > On 05/27/2015 11:06 AM, Alexander Frolushkin wrote: >> For common information - we also have a "ghost" replica id: >> unable to decode: {replica 16} 548a8126000000100000 >> 548a8126000000100000 and trying to get it away with help of Red Hat support, but at this point - no luck... >> >> WBR, >> Alexander Frolushkin >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle >> Sent: Tuesday, May 26, 2015 8:56 PM >> To: thierry bordaz; Martin Kosek >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Haunted servers? >> >> On 5/26/15 7:04 AM, thierry bordaz wrote: >>> On 05/26/2015 08:47 AM, Martin Kosek wrote: >>>> On 05/26/2015 12:20 AM, Janelle wrote: >>>>> On 5/24/15 3:12 AM, Janelle wrote: >>>>>> And just like that, my haunted servers have all returned. >>>>>> I am going to just put a gun to my head and be done with it. :-( >>>>>> >>>>>> Why do things run perfectly and then suddenly ??? >>>>>> Logs show little to nothing, mostly because the servers are so >>>>>> busy, they have already rotated out. >>>>>> >>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>> 55356472000300100000 >>>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>>> 553eec64000400160000 >>>>>> unable to decode {replica 23} 5545d61f000200170000 >>>>>> 55543240000300170000 >>>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>>> 554d54a4000200180000 >>>>>> unable to decode {replica 25} 554d78bf000000190000 >>>>>> 555af302000400190000 >>>>>> unable to decode {replica 9} 55402c39000300090000 >>>>>> 55402c39000300090000 >>>>>> >>>>>> Don't know what to do anymore. At my wit's end.. >>>>>> >>>>>> ~J >>>>> So things are getting more interesting. Still trying to find the >>>>> "leaking server(s)". here is what I mean by that. As you see, I >>>>> continue to find these >>>>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>>>> data - it is blank? >>>> Hello Janelle, >>>> >>>> Thanks for update. So you worry that there might still be the "rogue >>>> IPA replica" that would be injecting the wrong replica data? >>>> >>>> In any case, I bet Ludwig and Thierry will follow up with your >>>> thread, there is just delay caused by the various public holidays >>>> and PTOs this week and we need to rest before digging into the fun >>>> with RUVs - as you already know yourself :-) >>>> >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>> 553eec64000400160000 >>>>> unable to decode {replica 24} 554d53d3000100180000 >>>>> 554d54a4000200180000 >>>>> unable to decode {replica 25} 554d78bf000200190000 >>>>> 555af302000400190000 >>>>> unable to decode {replica 9} >>>>> >>>>> Now, if I delete these from a server using the ldapmodify method - >>>>> they go away briefly, but then if I restart the server, they come >>>>> back. >>>>> >>>>> Let me try to explain -- given a number of servers, say 8, if I >>>>> user ldapmodify to delete from 1 of those, they seem to go away >>>>> from maybe 4 of them >>>>> -- but if >>>>> I wait a few minutes, it is almost as though "replication" is >>>>> re-adding these bad replicas from the servers that I have NOT >>>>> deleted them from. >>> On each replica (master/replica) there are one RUV in the database >>> and one RUV in the changelog. >>> When cleanallruv succeeds it clears both of them. All replica should >>> be reachable when you issue cleanallruv, so that it can clean the >>> RUVs on all the replicas in almost "single" >>> operation. If some replica are not reachable, they keep information >>> of about the cleaned RID and then can later propagate those "old" RID >>> to the rest of the replica. >>> >>> Ludwig managed to reproduce the issue with a quite complex test case >>> (3 replicas and multiple cleanallruv). >>> We have not yet identified the reason how a cleaned replicaId can get >>> resurrected. >>> In parallel we just reproduced it without a clear test case but in a >>> 2 replica topology. >>> >>> >>>>> So my question is simple - is there something in the logs I can >>>>> look for that would indicate the SOURCE of these bogus entries? Is >>>>> the replica 9 with NO extra data any indication of something I >>>>> could look for? >>> I guess that if I have the answer to your question we would have >>> understood the bug .. >>> >>> >> A little more information to go on: >> >> I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. >> I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. >> >> I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. >> >> Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? >> >> ~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 project >> >> ________________________________ >> >> ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. >> >> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. >> >> (c)20mf50 >> > > ________________________________ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. > > (c)20mf50 From linhai88 at stanford.edu Thu May 28 09:47:07 2015 From: linhai88 at stanford.edu (David Lin) Date: Thu, 28 May 2015 02:47:07 -0700 Subject: [Freeipa-users] question about password migration from ldap Message-ID: <5566E41B.4080301@stanford.edu> Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE Thanks, David From mkosek at redhat.com Thu May 28 10:13:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 12:13:49 +0200 Subject: [Freeipa-users] question about password migration from ldap In-Reply-To: <5566E41B.4080301@stanford.edu> References: <5566E41B.4080301@stanford.edu> Message-ID: <5566EA5D.5090604@redhat.com> On 05/28/2015 11:47 AM, David Lin wrote: > Hi, > I am try to migrate from openldap to freeipa. Everything seems to be working > except the password. I understand that when migrating from openldap, the hashed > form the the passwords are migrated, but a Kerberos hash is not generated until > the user logs in using sssd or through the ipa/migration web ui. However, the > users are not able to login in either form using their existing password, from > the directory server log, the only weird thing I see is > > [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES > [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND > dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" > method=128 version=3 > [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 > [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND > [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 > > What does err=48 mean? > > I do have > ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b "uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Martin From linhai88 at stanford.edu Thu May 28 10:19:05 2015 From: linhai88 at stanford.edu (David Lin) Date: Thu, 28 May 2015 03:19:05 -0700 Subject: [Freeipa-users] question about password migration from ldap In-Reply-To: <5566EA5D.5090604@redhat.com> References: <5566E41B.4080301@stanford.edu> <5566EA5D.5090604@redhat.com> Message-ID: <5566EB99.6050406@stanford.edu> hum, seems like the migrated users do not have userPassword attribute. Is there anyway to fix this? Thanks! David On 05/28/2015 03:13 AM, Martin Kosek wrote: > On 05/28/2015 11:47 AM, David Lin wrote: >> Hi, >> I am try to migrate from openldap to freeipa. Everything seems to be working >> except the password. I understand that when migrating from openldap, the hashed >> form the the passwords are migrated, but a Kerberos hash is not generated until >> the user logs in using sssd or through the ipa/migration web ui. However, the >> users are not able to login in either form using their existing password, from >> the directory server log, the only weird thing I see is >> >> [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 >> [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES >> [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND >> dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" >> method=128 version=3 >> [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 >> [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND >> [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 >> >> What does err=48 mean? >> >> I do have >> ipa config-mod --enable-migration=TRUE > 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: > http://www.zytrax.com/books/ldap/ch12/ > > Do the migrated users have the userPassword attribute? You can check on the > user with: > > # ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b > "uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: uid userPassword > # > > # admin, users, accounts, f21 > dn: uid=admin,cn=users,cn=accounts,dc=f21 > uid: admin > userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > Martin From abokovoy at redhat.com Thu May 28 10:31:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 28 May 2015 13:31:36 +0300 Subject: [Freeipa-users] question about password migration from ldap In-Reply-To: <5566EB99.6050406@stanford.edu> References: <5566E41B.4080301@stanford.edu> <5566EA5D.5090604@redhat.com> <5566EB99.6050406@stanford.edu> Message-ID: <20150528103136.GC19176@redhat.com> On Thu, 28 May 2015, David Lin wrote: >hum, seems like the migrated users do not have userPassword attribute. >Is there anyway to fix this? Did you actually have access to the userPasssword attribute in OpenLDAP when migrate-ds command was running? This all is described in the 'ipa migrate-ds --help' output. You cannot add userPassword attribute in hashed form after the object was created in IPA. It can only be set when new user record is created in the migration mode. > >Thanks! >David > >On 05/28/2015 03:13 AM, Martin Kosek wrote: >>On 05/28/2015 11:47 AM, David Lin wrote: >>>Hi, >>>I am try to migrate from openldap to freeipa. Everything seems to be working >>>except the password. I understand that when migrating from openldap, the hashed >>>form the the passwords are migrated, but a Kerberos hash is not generated until >>>the user logs in using sssd or through the ipa/migration web ui. However, the >>>users are not able to login in either form using their existing password, from >>>the directory server log, the only weird thing I see is >>> >>>[28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 >>>[28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES >>>[28/May/2015:02:40:04 -0700] conn=112 op=1 BIND >>>dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" >>>method=128 version=3 >>>[28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 >>>[28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND >>>[28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 >>> >>>What does err=48 mean? >>> >>>I do have >>>ipa config-mod --enable-migration=TRUE >>48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: >>http://www.zytrax.com/books/ldap/ch12/ >> >>Do the migrated users have the userPassword attribute? You can check on the >>user with: >> >># ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b >>"uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword >># extended LDIF >># >># LDAPv3 >># base with scope subtree >># filter: (objectclass=*) >># requesting: uid userPassword >># >> >># admin, users, accounts, f21 >>dn: uid=admin,cn=users,cn=accounts,dc=f21 >>uid: admin >>userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== >> >># search result >>search: 2 >>result: 0 Success >> >># numResponses: 2 >># numEntries: 1 >> >> >>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 -- / Alexander Bokovoy From Alexander.Frolushkin at megafon.ru Thu May 28 10:36:44 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Thu, 28 May 2015 10:36:44 +0000 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <5566C887.4050206@redhat.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> <5566C887.4050206@redhat.com> Message-ID: <2edca1d40b1942e99a98e075a50659af@sib-ums03.Megafon.ru> Thank you again, Red Hat support directed me to do exactly the same. This removed my "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" from the rest of servers. I will check again tomorrow all our servers for this :) Well, I'm not the only person have privileges on our IPA servers, so I cannot completely guarantee nobody run this command ('ipa-replica-manage del --force --clean'. (with the option --force and --clean)) but after interrogation no one made a confession, including myself. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 -----Original Message----- From: thierry bordaz [mailto:tbordaz at redhat.com] Sent: Thursday, May 28, 2015 1:49 PM To: Alexander Frolushkin (SIB) Cc: freeipa-users at redhat.com; 'Janelle' Subject: Re: [Freeipa-users] Haunted servers? On 05/28/2015 09:33 AM, Alexander Frolushkin wrote: > Hello! > Thank you for this info. > > Things seems to be complicated for now... > We have this: > "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" > on all of our 17 servers. > After launching cleanallruv we have it disappeared from 16 servers and > one server hangs (any requests addressed ldap just freezes, including "ipactl status"). After dirsrv restart (via "systemctl restart ipa") I found "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" > on this server (and only on it), run cleanallruv and get it from this > server, but right after that unable to decode: {replica 16} > 548a8126000000100000 548a8126000000100000 reappeared on three other servers. Hello, Yes this is exactly why cleanallruv is the first tool to use, it does the job on all replicas. When you restarted the hanging server, some (3) of them established a replication session with it and "learned" this old/invalid RUVelement. Janelle, Alexander, do you remember if you ran the command : 'ipa-replica-manage del --force --clean'. (with the option --force and --clean) ? thanks thierry > Now I'm waiting response from support, they requested dirsrv logs form hanged server and from servers where error appeared again. > > WBR, > Alexander Frolushkin > Cell +79232508764 > Work +79232507764 > > > -----Original Message----- > From: thierry bordaz [mailto:tbordaz at redhat.com] > Sent: Thursday, May 28, 2015 1:24 PM > To: Alexander Frolushkin (SIB) > Cc: freeipa-users at redhat.com; 'Janelle' > Subject: Re: [Freeipa-users] Haunted servers? > > Hello Alexander, > > Cleanallruv can hang to do the cleanup (depending on task options and if replica are reachable). > Did you try using CLEANRUV that is a more basic tool but that should not fail to do the cleanup. > > Before using cleanruv, you need to abort all cleanallruv pending tasks. > > Then for each RID that you want to clean, you have to log on each > replica and run > dn: cn=replica,cn=,cn=mapping tree,cn=config > changetype: modify > replace: nsds5task > nsds5task:CLEANRUV > > This task should succeeds but there is possibility that a given RID resurects in case a replication session occurs before all cleanRUV are completed. > So we may have to do cleanRUV a second time. > > thanks > thierry > > On 05/27/2015 11:06 AM, Alexander Frolushkin wrote: >> For common information - we also have a "ghost" replica id: >> unable to decode: {replica 16} 548a8126000000100000 >> 548a8126000000100000 and trying to get it away with help of Red Hat support, but at this point - no luck... >> >> WBR, >> Alexander Frolushkin >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle >> Sent: Tuesday, May 26, 2015 8:56 PM >> To: thierry bordaz; Martin Kosek >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Haunted servers? >> >> On 5/26/15 7:04 AM, thierry bordaz wrote: >>> On 05/26/2015 08:47 AM, Martin Kosek wrote: >>>> On 05/26/2015 12:20 AM, Janelle wrote: >>>>> On 5/24/15 3:12 AM, Janelle wrote: >>>>>> And just like that, my haunted servers have all returned. >>>>>> I am going to just put a gun to my head and be done with it. :-( >>>>>> >>>>>> Why do things run perfectly and then suddenly ??? >>>>>> Logs show little to nothing, mostly because the servers are so >>>>>> busy, they have already rotated out. >>>>>> >>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>> 55356472000300100000 >>>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>>> 553eec64000400160000 >>>>>> unable to decode {replica 23} 5545d61f000200170000 >>>>>> 55543240000300170000 >>>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>>> 554d54a4000200180000 >>>>>> unable to decode {replica 25} 554d78bf000000190000 >>>>>> 555af302000400190000 >>>>>> unable to decode {replica 9} 55402c39000300090000 >>>>>> 55402c39000300090000 >>>>>> >>>>>> Don't know what to do anymore. At my wit's end.. >>>>>> >>>>>> ~J >>>>> So things are getting more interesting. Still trying to find the >>>>> "leaking server(s)". here is what I mean by that. As you see, I >>>>> continue to find these >>>>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>>>> data - it is blank? >>>> Hello Janelle, >>>> >>>> Thanks for update. So you worry that there might still be the >>>> "rogue IPA replica" that would be injecting the wrong replica data? >>>> >>>> In any case, I bet Ludwig and Thierry will follow up with your >>>> thread, there is just delay caused by the various public holidays >>>> and PTOs this week and we need to rest before digging into the fun >>>> with RUVs - as you already know yourself :-) >>>> >>>>> unable to decode {replica 16} 55356472000300100000 >>>>> 55356472000300100000 >>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>> 553eec64000400160000 >>>>> unable to decode {replica 24} 554d53d3000100180000 >>>>> 554d54a4000200180000 >>>>> unable to decode {replica 25} 554d78bf000200190000 >>>>> 555af302000400190000 >>>>> unable to decode {replica 9} >>>>> >>>>> Now, if I delete these from a server using the ldapmodify method - >>>>> they go away briefly, but then if I restart the server, they come >>>>> back. >>>>> >>>>> Let me try to explain -- given a number of servers, say 8, if I >>>>> user ldapmodify to delete from 1 of those, they seem to go away >>>>> from maybe 4 of them >>>>> -- but if >>>>> I wait a few minutes, it is almost as though "replication" is >>>>> re-adding these bad replicas from the servers that I have NOT >>>>> deleted them from. >>> On each replica (master/replica) there are one RUV in the database >>> and one RUV in the changelog. >>> When cleanallruv succeeds it clears both of them. All replica should >>> be reachable when you issue cleanallruv, so that it can clean the >>> RUVs on all the replicas in almost "single" >>> operation. If some replica are not reachable, they keep information >>> of about the cleaned RID and then can later propagate those "old" >>> RID to the rest of the replica. >>> >>> Ludwig managed to reproduce the issue with a quite complex test case >>> (3 replicas and multiple cleanallruv). >>> We have not yet identified the reason how a cleaned replicaId can >>> get resurrected. >>> In parallel we just reproduced it without a clear test case but in a >>> 2 replica topology. >>> >>> >>>>> So my question is simple - is there something in the logs I can >>>>> look for that would indicate the SOURCE of these bogus entries? >>>>> Is the replica 9 with NO extra data any indication of something I >>>>> could look for? >>> I guess that if I have the answer to your question we would have >>> understood the bug .. >>> >>> >> A little more information to go on: >> >> I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. >> I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. >> >> I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. >> >> Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? >> >> ~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 project >> >> ________________________________ >> >> ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. >> >> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. >> >> (c)20mf50 >> > > ________________________________ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. > > (c)20mf50 ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 From linhai88 at stanford.edu Thu May 28 10:59:00 2015 From: linhai88 at stanford.edu (David Lin) Date: Thu, 28 May 2015 03:59:00 -0700 Subject: [Freeipa-users] question about password migration from ldap In-Reply-To: <20150528103136.GC19176@redhat.com> References: <5566E41B.4080301@stanford.edu> <5566EA5D.5090604@redhat.com> <5566EB99.6050406@stanford.edu> <20150528103136.GC19176@redhat.com> Message-ID: <5566F4F4.90503@stanford.edu> Thanks, that seemed to fix it. David On 05/28/2015 03:31 AM, Alexander Bokovoy wrote: > On Thu, 28 May 2015, David Lin wrote: >> hum, seems like the migrated users do not have userPassword >> attribute. Is there anyway to fix this? > Did you actually have access to the userPasssword attribute in OpenLDAP > when migrate-ds command was running? This all is described in the 'ipa > migrate-ds --help' output. > > You cannot add userPassword attribute in hashed form after the object > was created in IPA. It can only be set when new user record is created > in the migration mode. > >> >> Thanks! >> David >> >> On 05/28/2015 03:13 AM, Martin Kosek wrote: >>> On 05/28/2015 11:47 AM, David Lin wrote: >>>> Hi, >>>> I am try to migrate from openldap to freeipa. Everything seems to >>>> be working >>>> except the password. I understand that when migrating from >>>> openldap, the hashed >>>> form the the passwords are migrated, but a Kerberos hash is not >>>> generated until >>>> the user logs in using sssd or through the ipa/migration web ui. >>>> However, the >>>> users are not able to login in either form using their existing >>>> password, from >>>> the directory server log, the only weird thing I see is >>>> >>>> [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 >>>> nentries=0 etime=0 >>>> [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES >>>> [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND >>>> dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" >>>> >>>> method=128 version=3 >>>> [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 >>>> nentries=0 etime=0 >>>> [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND >>>> [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 >>>> >>>> What does err=48 mean? >>>> >>>> I do have >>>> ipa config-mod --enable-migration=TRUE >>> 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: >>> http://www.zytrax.com/books/ldap/ch12/ >>> >>> Do the migrated users have the userPassword attribute? You can check >>> on the >>> user with: >>> >>> # ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b >>> "uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree >>> # filter: (objectclass=*) >>> # requesting: uid userPassword >>> # >>> >>> # admin, users, accounts, f21 >>> dn: uid=admin,cn=users,cn=accounts,dc=f21 >>> uid: admin >>> userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 2 >>> # numEntries: 1 >>> >>> >>> 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 > From tbordaz at redhat.com Thu May 28 11:19:02 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 28 May 2015 13:19:02 +0200 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <2edca1d40b1942e99a98e075a50659af@sib-ums03.Megafon.ru> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> <5566C887.4050206@redhat.com> <2edca1d40b1942e99a98e075a50659af@sib-ums03.Megafon.ru> Message-ID: <5566F9A6.2080205@redhat.com> On 05/28/2015 12:36 PM, Alexander Frolushkin wrote: > Thank you again, Red Hat support directed me to do exactly the same. > > This removed my > "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" > from the rest of servers. I will check again tomorrow all our servers for this :) Alexander, this is good news. Hoping it will not resurect from a forgotten replica or changelog ;-) The problem is that we are still fighting to reproduce it as certainly there are some dynamics around that bug. cleanruv is just a not perfect workaround. thanks thierry > > Well, I'm not the only person have privileges on our IPA servers, so I cannot completely guarantee nobody run this command ('ipa-replica-manage del --force --clean'. (with the option --force and --clean)) > but after interrogation no one made a confession, including myself. Ok. thanks thierry > > > WBR, > Alexander Frolushkin > Cell +79232508764 > Work +79232507764 > > > -----Original Message----- > From: thierry bordaz [mailto:tbordaz at redhat.com] > Sent: Thursday, May 28, 2015 1:49 PM > To: Alexander Frolushkin (SIB) > Cc: freeipa-users at redhat.com; 'Janelle' > Subject: Re: [Freeipa-users] Haunted servers? > > On 05/28/2015 09:33 AM, Alexander Frolushkin wrote: >> Hello! >> Thank you for this info. >> >> Things seems to be complicated for now... >> We have this: >> "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" >> on all of our 17 servers. >> After launching cleanallruv we have it disappeared from 16 servers and >> one server hangs (any requests addressed ldap just freezes, including "ipactl status"). After dirsrv restart (via "systemctl restart ipa") I found "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" >> on this server (and only on it), run cleanallruv and get it from this >> server, but right after that unable to decode: {replica 16} >> 548a8126000000100000 548a8126000000100000 reappeared on three other servers. > Hello, > > Yes this is exactly why cleanallruv is the first tool to use, it does the job on all replicas. > When you restarted the hanging server, some (3) of them established a replication session with it and "learned" this old/invalid RUVelement. > > Janelle, Alexander, do you remember if you ran the command : > 'ipa-replica-manage del --force --clean'. (with the option --force and --clean) ? > > thanks > thierry >> Now I'm waiting response from support, they requested dirsrv logs form hanged server and from servers where error appeared again. >> >> WBR, >> Alexander Frolushkin >> Cell +79232508764 >> Work +79232507764 >> >> >> -----Original Message----- >> From: thierry bordaz [mailto:tbordaz at redhat.com] >> Sent: Thursday, May 28, 2015 1:24 PM >> To: Alexander Frolushkin (SIB) >> Cc: freeipa-users at redhat.com; 'Janelle' >> Subject: Re: [Freeipa-users] Haunted servers? >> >> Hello Alexander, >> >> Cleanallruv can hang to do the cleanup (depending on task options and if replica are reachable). >> Did you try using CLEANRUV that is a more basic tool but that should not fail to do the cleanup. >> >> Before using cleanruv, you need to abort all cleanallruv pending tasks. >> >> Then for each RID that you want to clean, you have to log on each >> replica and run >> dn: cn=replica,cn=,cn=mapping tree,cn=config >> changetype: modify >> replace: nsds5task >> nsds5task:CLEANRUV >> >> This task should succeeds but there is possibility that a given RID resurects in case a replication session occurs before all cleanRUV are completed. >> So we may have to do cleanRUV a second time. >> >> thanks >> thierry >> >> On 05/27/2015 11:06 AM, Alexander Frolushkin wrote: >>> For common information - we also have a "ghost" replica id: >>> unable to decode: {replica 16} 548a8126000000100000 >>> 548a8126000000100000 and trying to get it away with help of Red Hat support, but at this point - no luck... >>> >>> WBR, >>> Alexander Frolushkin >>> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle >>> Sent: Tuesday, May 26, 2015 8:56 PM >>> To: thierry bordaz; Martin Kosek >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Haunted servers? >>> >>> On 5/26/15 7:04 AM, thierry bordaz wrote: >>>> On 05/26/2015 08:47 AM, Martin Kosek wrote: >>>>> On 05/26/2015 12:20 AM, Janelle wrote: >>>>>> On 5/24/15 3:12 AM, Janelle wrote: >>>>>>> And just like that, my haunted servers have all returned. >>>>>>> I am going to just put a gun to my head and be done with it. :-( >>>>>>> >>>>>>> Why do things run perfectly and then suddenly ??? >>>>>>> Logs show little to nothing, mostly because the servers are so >>>>>>> busy, they have already rotated out. >>>>>>> >>>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>>> 55356472000300100000 >>>>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>>>> 553eec64000400160000 >>>>>>> unable to decode {replica 23} 5545d61f000200170000 >>>>>>> 55543240000300170000 >>>>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>>>> 554d54a4000200180000 >>>>>>> unable to decode {replica 25} 554d78bf000000190000 >>>>>>> 555af302000400190000 >>>>>>> unable to decode {replica 9} 55402c39000300090000 >>>>>>> 55402c39000300090000 >>>>>>> >>>>>>> Don't know what to do anymore. At my wit's end.. >>>>>>> >>>>>>> ~J >>>>>> So things are getting more interesting. Still trying to find the >>>>>> "leaking server(s)". here is what I mean by that. As you see, I >>>>>> continue to find these >>>>>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>>>>> data - it is blank? >>>>> Hello Janelle, >>>>> >>>>> Thanks for update. So you worry that there might still be the >>>>> "rogue IPA replica" that would be injecting the wrong replica data? >>>>> >>>>> In any case, I bet Ludwig and Thierry will follow up with your >>>>> thread, there is just delay caused by the various public holidays >>>>> and PTOs this week and we need to rest before digging into the fun >>>>> with RUVs - as you already know yourself :-) >>>>> >>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>> 55356472000300100000 >>>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>>> 553eec64000400160000 >>>>>> unable to decode {replica 24} 554d53d3000100180000 >>>>>> 554d54a4000200180000 >>>>>> unable to decode {replica 25} 554d78bf000200190000 >>>>>> 555af302000400190000 >>>>>> unable to decode {replica 9} >>>>>> >>>>>> Now, if I delete these from a server using the ldapmodify method - >>>>>> they go away briefly, but then if I restart the server, they come >>>>>> back. >>>>>> >>>>>> Let me try to explain -- given a number of servers, say 8, if I >>>>>> user ldapmodify to delete from 1 of those, they seem to go away >>>>>> from maybe 4 of them >>>>>> -- but if >>>>>> I wait a few minutes, it is almost as though "replication" is >>>>>> re-adding these bad replicas from the servers that I have NOT >>>>>> deleted them from. >>>> On each replica (master/replica) there are one RUV in the database >>>> and one RUV in the changelog. >>>> When cleanallruv succeeds it clears both of them. All replica should >>>> be reachable when you issue cleanallruv, so that it can clean the >>>> RUVs on all the replicas in almost "single" >>>> operation. If some replica are not reachable, they keep information >>>> of about the cleaned RID and then can later propagate those "old" >>>> RID to the rest of the replica. >>>> >>>> Ludwig managed to reproduce the issue with a quite complex test case >>>> (3 replicas and multiple cleanallruv). >>>> We have not yet identified the reason how a cleaned replicaId can >>>> get resurrected. >>>> In parallel we just reproduced it without a clear test case but in a >>>> 2 replica topology. >>>> >>>> >>>>>> So my question is simple - is there something in the logs I can >>>>>> look for that would indicate the SOURCE of these bogus entries? >>>>>> Is the replica 9 with NO extra data any indication of something I >>>>>> could look for? >>>> I guess that if I have the answer to your question we would have >>>> understood the bug .. >>>> >>>> >>> A little more information to go on: >>> >>> I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. >>> I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. >>> >>> I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. >>> >>> Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? >>> >>> ~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 project >>> >>> ________________________________ >>> >>> ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. >>> >>> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. >>> >>> (c)20mf50 >>> >> ________________________________ >> >> ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. >> >> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. >> >> (c)20mf50 > > ________________________________ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. > > (c)20mf50 From Alexander.Frolushkin at megafon.ru Thu May 28 11:23:26 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Thu, 28 May 2015 11:23:26 +0000 Subject: [Freeipa-users] Haunted servers? In-Reply-To: <5566F9A6.2080205@redhat.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> <5566C887.4050206@redhat.com> <2edca1d40b1942e99a98e075a50659af@sib-ums03.Megafon.ru> <5566F9A6.2080205@redhat.com> Message-ID: <952adf58d9014ddeab0c19fa79448000@sib-ums03.Megafon.ru> Unfortunately, after a couple of minutes, on two of three servers error comes back in little changed form: # ipa-replica-manage list-ruv unable to decode: {replica 16} .... Before cleanruv it looked like: # ipa-replica-manage list-ruv unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 .... And one server seems to be fixed completely. WBR, Alexander Frolushkin -----Original Message----- From: thierry bordaz [mailto:tbordaz at redhat.com] Sent: Thursday, May 28, 2015 5:19 PM To: Alexander Frolushkin (SIB) Cc: freeipa-users at redhat.com; 'Janelle' Subject: Re: [Freeipa-users] Haunted servers? On 05/28/2015 12:36 PM, Alexander Frolushkin wrote: > Thank you again, Red Hat support directed me to do exactly the same. > > This removed my > "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" > from the rest of servers. I will check again tomorrow all our servers > for this :) Alexander, this is good news. Hoping it will not resurect from a forgotten replica or changelog ;-) The problem is that we are still fighting to reproduce it as certainly there are some dynamics around that bug. cleanruv is just a not perfect workaround. thanks thierry > > Well, I'm not the only person have privileges on our IPA servers, so I > cannot completely guarantee nobody run this command ('ipa-replica-manage del --force --clean'. (with the option --force and --clean)) but after interrogation no one made a confession, including myself. Ok. thanks thierry > > > WBR, > Alexander Frolushkin > Cell +79232508764 > Work +79232507764 > > > -----Original Message----- > From: thierry bordaz [mailto:tbordaz at redhat.com] > Sent: Thursday, May 28, 2015 1:49 PM > To: Alexander Frolushkin (SIB) > Cc: freeipa-users at redhat.com; 'Janelle' > Subject: Re: [Freeipa-users] Haunted servers? > > On 05/28/2015 09:33 AM, Alexander Frolushkin wrote: >> Hello! >> Thank you for this info. >> >> Things seems to be complicated for now... >> We have this: >> "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" >> on all of our 17 servers. >> After launching cleanallruv we have it disappeared from 16 servers >> and one server hangs (any requests addressed ldap just freezes, including "ipactl status"). After dirsrv restart (via "systemctl restart ipa") I found "unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000" >> on this server (and only on it), run cleanallruv and get it from this >> server, but right after that unable to decode: {replica 16} >> 548a8126000000100000 548a8126000000100000 reappeared on three other servers. > Hello, > > Yes this is exactly why cleanallruv is the first tool to use, it does the job on all replicas. > When you restarted the hanging server, some (3) of them established a replication session with it and "learned" this old/invalid RUVelement. > > Janelle, Alexander, do you remember if you ran the command : > 'ipa-replica-manage del --force --clean'. (with the option --force and --clean) ? > > thanks > thierry >> Now I'm waiting response from support, they requested dirsrv logs form hanged server and from servers where error appeared again. >> >> WBR, >> Alexander Frolushkin >> Cell +79232508764 >> Work +79232507764 >> >> >> -----Original Message----- >> From: thierry bordaz [mailto:tbordaz at redhat.com] >> Sent: Thursday, May 28, 2015 1:24 PM >> To: Alexander Frolushkin (SIB) >> Cc: freeipa-users at redhat.com; 'Janelle' >> Subject: Re: [Freeipa-users] Haunted servers? >> >> Hello Alexander, >> >> Cleanallruv can hang to do the cleanup (depending on task options and if replica are reachable). >> Did you try using CLEANRUV that is a more basic tool but that should not fail to do the cleanup. >> >> Before using cleanruv, you need to abort all cleanallruv pending tasks. >> >> Then for each RID that you want to clean, you have to log on each >> replica and run >> dn: cn=replica,cn=,cn=mapping tree,cn=config >> changetype: modify >> replace: nsds5task >> nsds5task:CLEANRUV >> >> This task should succeeds but there is possibility that a given RID resurects in case a replication session occurs before all cleanRUV are completed. >> So we may have to do cleanRUV a second time. >> >> thanks >> thierry >> >> On 05/27/2015 11:06 AM, Alexander Frolushkin wrote: >>> For common information - we also have a "ghost" replica id: >>> unable to decode: {replica 16} 548a8126000000100000 >>> 548a8126000000100000 and trying to get it away with help of Red Hat support, but at this point - no luck... >>> >>> WBR, >>> Alexander Frolushkin >>> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle >>> Sent: Tuesday, May 26, 2015 8:56 PM >>> To: thierry bordaz; Martin Kosek >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Haunted servers? >>> >>> On 5/26/15 7:04 AM, thierry bordaz wrote: >>>> On 05/26/2015 08:47 AM, Martin Kosek wrote: >>>>> On 05/26/2015 12:20 AM, Janelle wrote: >>>>>> On 5/24/15 3:12 AM, Janelle wrote: >>>>>>> And just like that, my haunted servers have all returned. >>>>>>> I am going to just put a gun to my head and be done with it. :-( >>>>>>> >>>>>>> Why do things run perfectly and then suddenly ??? >>>>>>> Logs show little to nothing, mostly because the servers are so >>>>>>> busy, they have already rotated out. >>>>>>> >>>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>>> 55356472000300100000 >>>>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>>>> 553eec64000400160000 >>>>>>> unable to decode {replica 23} 5545d61f000200170000 >>>>>>> 55543240000300170000 >>>>>>> unable to decode {replica 24} 554d53d3000000180000 >>>>>>> 554d54a4000200180000 >>>>>>> unable to decode {replica 25} 554d78bf000000190000 >>>>>>> 555af302000400190000 >>>>>>> unable to decode {replica 9} 55402c39000300090000 >>>>>>> 55402c39000300090000 >>>>>>> >>>>>>> Don't know what to do anymore. At my wit's end.. >>>>>>> >>>>>>> ~J >>>>>> So things are getting more interesting. Still trying to find the >>>>>> "leaking server(s)". here is what I mean by that. As you see, I >>>>>> continue to find these >>>>>> -- BUT, notice a new symptom -- replica 9 does NOT show any other >>>>>> data - it is blank? >>>>> Hello Janelle, >>>>> >>>>> Thanks for update. So you worry that there might still be the >>>>> "rogue IPA replica" that would be injecting the wrong replica data? >>>>> >>>>> In any case, I bet Ludwig and Thierry will follow up with your >>>>> thread, there is just delay caused by the various public holidays >>>>> and PTOs this week and we need to rest before digging into the fun >>>>> with RUVs - as you already know yourself :-) >>>>> >>>>>> unable to decode {replica 16} 55356472000300100000 >>>>>> 55356472000300100000 >>>>>> unable to decode {replica 22} 55371e9e000000160000 >>>>>> 553eec64000400160000 >>>>>> unable to decode {replica 24} 554d53d3000100180000 >>>>>> 554d54a4000200180000 >>>>>> unable to decode {replica 25} 554d78bf000200190000 >>>>>> 555af302000400190000 >>>>>> unable to decode {replica 9} >>>>>> >>>>>> Now, if I delete these from a server using the ldapmodify method >>>>>> - they go away briefly, but then if I restart the server, they >>>>>> come back. >>>>>> >>>>>> Let me try to explain -- given a number of servers, say 8, if I >>>>>> user ldapmodify to delete from 1 of those, they seem to go away >>>>>> from maybe 4 of them >>>>>> -- but if >>>>>> I wait a few minutes, it is almost as though "replication" is >>>>>> re-adding these bad replicas from the servers that I have NOT >>>>>> deleted them from. >>>> On each replica (master/replica) there are one RUV in the database >>>> and one RUV in the changelog. >>>> When cleanallruv succeeds it clears both of them. All replica >>>> should be reachable when you issue cleanallruv, so that it can >>>> clean the RUVs on all the replicas in almost "single" >>>> operation. If some replica are not reachable, they keep information >>>> of about the cleaned RID and then can later propagate those "old" >>>> RID to the rest of the replica. >>>> >>>> Ludwig managed to reproduce the issue with a quite complex test >>>> case >>>> (3 replicas and multiple cleanallruv). >>>> We have not yet identified the reason how a cleaned replicaId can >>>> get resurrected. >>>> In parallel we just reproduced it without a clear test case but in >>>> a >>>> 2 replica topology. >>>> >>>> >>>>>> So my question is simple - is there something in the logs I can >>>>>> look for that would indicate the SOURCE of these bogus entries? >>>>>> Is the replica 9 with NO extra data any indication of something I >>>>>> could look for? >>>> I guess that if I have the answer to your question we would have >>>> understood the bug .. >>>> >>>> >>> A little more information to go on: >>> >>> I changed my password on a master (actually, the original master) and was able to login to each replica within a few seconds with the new password. This tells me replication is working across all the servers. >>> I also created a new account and it showed up on all the servers, again within 15-20 seconds. This tells me replication is working just fine. >>> >>> I don't understand why the cleanallruv does not process across all the servers the same way. Baffling indeed. >>> >>> Perhaps the most important question -- does these bogus entries actually cause a problem? I mean they don't seem to be. What if I just ignored them? >>> >>> ~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 project >>> >>> ________________________________ >>> >>> ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. >>> >>> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. >>> >>> (c)20mf50 >>> >> ________________________________ >> >> ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. >> >> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. >> >> (c)20mf50 > > ________________________________ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. > > (c)20mf50 ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 From preichl at redhat.com Thu May 28 11:52:30 2015 From: preichl at redhat.com (Pavel Reichl) Date: Thu, 28 May 2015 13:52:30 +0200 Subject: [Freeipa-users] Sensible defaults for a new major SSSD release Message-ID: <5567017E.9010209@redhat.com> Hello, as part of solution for https://fedorahosted.org/sssd/ticket/2583 ([RFE] Homedir is always overwritten with subdomain_homedir value in server mode) we came to the conclusion that it would be a good thing for SSSD in IPA server mode to change default value of subdomain_homedir from /home/%d/%u to /home/%o (where %o is original user home directory) and also set fallback_homedir to /home/%d/%u to handle cases when user doesn't have home directory attribute set. Do you have any opinions about this change? Thanks! From bob at jackland.demon.co.uk Thu May 28 13:08:53 2015 From: bob at jackland.demon.co.uk (Bob Hinton) Date: Thu, 28 May 2015 14:08:53 +0100 Subject: [Freeipa-users] client fails to install from ipa-server-install or ipa-replica-install Message-ID: <55671365.4050209@jackland.demon.co.uk> Hello, I'm using Puppet to try to install ipa masters and replicas. I can generally get this to work on Vagrant VMs, but on the target VMs the server part succeeds until it attempts to install the ipa client and then this fails (please see extracts of logs below). The /etc/ipa/nssdb directory is left empty. On a replica I can copy this from the master along with /etc/openldap/ldap.conf and the client works (apart from mkhomedir) when sssd is started. Should /etc/ipa/nssdb be populated on the master at this stage of the installation and, if so, then why isn't this happening? Selinux is enabled on the target VMs, but presumably this isn't an issue. Many thanks Bob Hinton trying https://ipa001.jackland.co.uk/ipa/json Forwarding 'ping' to json server 'https://ipa001.jackland.co.uk/ipa/json' Cannot connect to the server due to generic error: cannot connect to 'https://ipa001.jackland.co.uk/ipa/json': Internal Server Error Installation failed. As this is IPA server, changes will not be rolled back. 2015-05-28T11:41:25Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1292, in main sys.exit("Configuration of client side components failed!\nipa-client-install returned: " + str(e)) 2015-05-28T11:41:25Z DEBUG The ipa-server-install command failed, exception: SystemExit: Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'jackland.co.uk' '--server' 'ipa001.jackland.co.uk' '--realm' 'JACKLAND.CO.UK' '--hostname' 'ipa001.jackland.co.uk' '--mkhomedir'' returned non-zero exit status 1 [root at ipa001 log]# 3d:a7:7b:d1:a6:45:b5:9d:d0:00:3e:34:de:b4:7f:0c: 37:0d:fa:1b:bb:32:2c:4b:13:35:b3:98:df:d9:62:8a: 97:3b:54:df:fb:46:f0:29:ea:c1:3d:9d:cf:f8:f8:2d: c7:3d:c0:50:7d:6d:3f:71:ad:fb:0a:74:ef:e5:eb:c0: 12:7c:96:b3:b0:da:bb:65:f9:a6:33:9f:82:af:99:ee: 50:34:44:84:0f:0e:5f:2a:67:84:b3:cc:5f:95:8c:1a Fingerprint (MD5): c3:db:00:21:a0:57:a0:d3:a4:31:a8:80:e2:9b:cb:c1 Fingerprint (SHA1): 77:2f:9f:2a:74:3e:62:09:b9:37:70:a3:74:99:5a:a0: d5:4a:37:ed 2015-05-28T11:41:25Z DEBUG approved_usage = SSL Server intended_usage = SSL Server 2015-05-28T11:41:25Z DEBUG cert valid True for "CN=ipa001.jackland.co.uk,O=JACKLAND.CO.UK" 2015-05-28T11:41:25Z DEBUG handshake complete, peer = 10.220.4.250:443 2015-05-28T11:41:25Z DEBUG Protocol: TLS1.1 2015-05-28T11:41:25Z DEBUG Cipher: TLS_RSA_WITH_AES_128_CBC_SHA 2015-05-28T11:41:25Z ERROR Cannot connect to the server due to generic error: cannot connect to 'https://ipa001.jackland.co.uk/ipa/json': Internal Server Error 2015-05-28T11:41:25Z WARNING Installation failed. As this is IPA server, changes will not be rolled back. [root at ipa001 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful [root at ipa001 ~]# cd /tmp [root at ipa001 tmp]# wget https://ipa001.jackland.co.uk/ipa/json --2015-05-28 13:45:04-- https://ipa001.jackland.co.uk/ipa/json Resolving ipa001.jackland.co.uk (ipa001.jackland.co.uk)... 10.220.4.250 Connecting to ipa001.jackland.co.uk (ipa001.jackland.co.uk)|10.220.4.250|:443... connected. ERROR: cannot verify ipa001.jackland.co.uk's certificate, issued by ?/O=JACKLAND.CO.UK/CN=Certificate Authority?: Self-signed certificate encountered. To connect to ipa001.jackland.co.uk insecurely, use `--no-check-certificate'. [root at ipa001 tmp]# wget --no-check-certificate https://ipa001.jackland.co.uk/ipa/json --2015-05-28 13:45:26-- https://ipa001.jackland.co.uk/ipa/json Resolving ipa001.jackland.co.uk (ipa001.jackland.co.uk)... 10.220.4.250 Connecting to ipa001.jackland.co.uk (ipa001.jackland.co.uk)|10.220.4.250|:443... connected. WARNING: cannot verify ipa001.jackland.co.uk's certificate, issued by ?/O=JACKLAND.CO.UK/CN=Certificate Authority?: Self-signed certificate encountered. HTTP request sent, awaiting response... 401 Unauthorized Authorization failed. [root at ipa001 tmp]# ls -l /etc/ipa/nssdb/ total 0 [root at ipa001 tmp]# From rcritten at redhat.com Thu May 28 13:26:54 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 May 2015 09:26:54 -0400 Subject: [Freeipa-users] client fails to install from ipa-server-install or ipa-replica-install In-Reply-To: <55671365.4050209@jackland.demon.co.uk> References: <55671365.4050209@jackland.demon.co.uk> Message-ID: <5567179E.2050706@redhat.com> Bob Hinton wrote: > Hello, > > I'm using Puppet to try to install ipa masters and replicas. I can > generally get this to work on Vagrant VMs, but on the target VMs the > server part succeeds until it attempts to install the ipa client and > then this fails (please see extracts of logs below). > > The /etc/ipa/nssdb directory is left empty. On a replica I can copy this > from the master along with /etc/openldap/ldap.conf and the client works > (apart from mkhomedir) when sssd is started. Should /etc/ipa/nssdb be > populated on the master at this stage of the installation and, if so, > then why isn't this happening? Selinux is enabled on the target VMs, but > presumably this isn't an issue. > > Many thanks > > Bob Hinton > > > trying https://ipa001.jackland.co.uk/ipa/json > Forwarding 'ping' to json server 'https://ipa001.jackland.co.uk/ipa/json' > Cannot connect to the server due to generic error: cannot connect to > 'https://ipa001.jackland.co.uk/ipa/json': Internal Server Error > Installation failed. As this is IPA server, changes will not be rolled back. > > 2015-05-28T11:41:25Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 646, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1292, in main > sys.exit("Configuration of client side components > failed!\nipa-client-install returned: " + str(e)) > > 2015-05-28T11:41:25Z DEBUG The ipa-server-install command failed, > exception: SystemExit: Configuration of client side components failed! > ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' > '--on-master' '--unattended' '--domain' 'jackland.co.uk' '--server' > 'ipa001.jackland.co.uk' '--realm' 'JACKLAND.CO.UK' '--hostname' > 'ipa001.jackland.co.uk' '--mkhomedir'' returned non-zero exit status 1 > [root at ipa001 log]# > > 3d:a7:7b:d1:a6:45:b5:9d:d0:00:3e:34:de:b4:7f:0c: > 37:0d:fa:1b:bb:32:2c:4b:13:35:b3:98:df:d9:62:8a: > 97:3b:54:df:fb:46:f0:29:ea:c1:3d:9d:cf:f8:f8:2d: > c7:3d:c0:50:7d:6d:3f:71:ad:fb:0a:74:ef:e5:eb:c0: > 12:7c:96:b3:b0:da:bb:65:f9:a6:33:9f:82:af:99:ee: > 50:34:44:84:0f:0e:5f:2a:67:84:b3:cc:5f:95:8c:1a > Fingerprint (MD5): > c3:db:00:21:a0:57:a0:d3:a4:31:a8:80:e2:9b:cb:c1 > Fingerprint (SHA1): > 77:2f:9f:2a:74:3e:62:09:b9:37:70:a3:74:99:5a:a0: > d5:4a:37:ed > 2015-05-28T11:41:25Z DEBUG approved_usage = SSL Server intended_usage = > SSL Server > 2015-05-28T11:41:25Z DEBUG cert valid True for > "CN=ipa001.jackland.co.uk,O=JACKLAND.CO.UK" > 2015-05-28T11:41:25Z DEBUG handshake complete, peer = 10.220.4.250:443 > 2015-05-28T11:41:25Z DEBUG Protocol: TLS1.1 > 2015-05-28T11:41:25Z DEBUG Cipher: TLS_RSA_WITH_AES_128_CBC_SHA > 2015-05-28T11:41:25Z ERROR Cannot connect to the server due to generic > error: cannot connect to 'https://ipa001.jackland.co.uk/ipa/json': > Internal Server Error > 2015-05-28T11:41:25Z WARNING Installation failed. As this is IPA server, > changes will not be rolled back. You'd want to check httpd error logs on the server ipa001 to see what the error is about. rob From jhrozek at redhat.com Thu May 28 13:38:03 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 28 May 2015 15:38:03 +0200 Subject: [Freeipa-users] Sensible defaults for a new major SSSD release In-Reply-To: <5567017E.9010209@redhat.com> References: <5567017E.9010209@redhat.com> Message-ID: <20150528133803.GT788@hendrix.arn.redhat.com> On Thu, May 28, 2015 at 01:52:30PM +0200, Pavel Reichl wrote: > Hello, > > as part of solution for https://fedorahosted.org/sssd/ticket/2583 ([RFE] > Homedir is always overwritten with subdomain_homedir value in server mode) > we came to the conclusion that it would be a good thing for SSSD in IPA > server mode to change default value of subdomain_homedir from /home/%d/%u to > /home/%o (where %o is original user home directory) and also set > fallback_homedir to /home/%d/%u to handle cases when user doesn't have home > directory attribute set. btw we were considering the change on new installs only, where upgrades would use the previous value. But then Sumit raised a good point that even a clean install doesn't equal a green-field environment -- it can be a new replica in an existing environment.. So right now we're leaning towards keeping the same defaults (/home/%d/%u) and only enabling the user to select the new behaviour (/home/%o) From Kurt.Bendl at nrel.gov Thu May 28 14:53:58 2015 From: Kurt.Bendl at nrel.gov (Bendl, Kurt) Date: Thu, 28 May 2015 14:53:58 +0000 Subject: [Freeipa-users] OTP vs VPN In-Reply-To: <20150527183325.GU19176@redhat.com> References: <20150527183325.GU19176@redhat.com> Message-ID: "There is no way to define per-service target 2FA yet in FreeIPA." Oh, man... there you go using the "yet" word! ;-) Thanks to you and Ben for the ideas. I'll hack around to see what makes sense. Thanks, Kurt On 5/27/15, 12:33 PM, "Alexander Bokovoy" wrote: >On Wed, 27 May 2015, Bendl, Kurt wrote: >>Hi, >> >>I want to know if I can configure FreeIPA's native OTP solution to >>require an account to use OTP when authenticating from a specific app >>(OpenVPN or StrongSwan) but not require 2FA when logging into a >>system/server or the IPA app. >> >>My (not completely baked) thought is to provision the VPN solution by >>setting up a role or group in IPA that I'd add accounts into. The VPN >>would allow users of that group to auth, using userid and password+OTP >>to successfully. >> >>I've been reading through docs on the freeipa and red hat sites, e.g., >>https://www.freeipa.org/page/V4/OTP/Detail and >>http://www.freeipa.org/page/V4/OTP#Enabling_OTP_and_RADIUS, to >>determine if or how that might be doable. >> >>>From what I read, an alternate approach from FreeIPA's built-in OTP >>>might be to set up a stand-alone OTP solution and use radius and/or a >>>PAM module to handle the VPN auth. >> >>I've DL'd the source, but there's so much there it'll take me some time >>to figure out what's happening. >> >>Any pointers on what approach I should take or where to find some notes >>and examples on how this might be accomplished would be greatly >>appreciated. >There is no way to define per-service target 2FA yet in FreeIPA. > >Setting up OpenVPN against IPA is easy. Use HBAC rules to confine who >can access there. > >As for forcing 2FA for such access, my only suggestion right now is to >have separate user accounts for this purpose. Let's say, they would be >prefixed with vpn- (vpn-userfoo, for example), and then tokens can be >assigned to them. >-- >/ Alexander Bokovoy From lists at thetimmy.com Thu May 28 17:10:48 2015 From: lists at thetimmy.com (Timothy Worman) Date: Thu, 28 May 2015 10:10:48 -0700 Subject: [Freeipa-users] inserting users via java In-Reply-To: <55148354.9020405@redhat.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> <55145326.80600@redhat.com> <55148354.9020405@redhat.com> Message-ID: <57A332AB-964E-434A-B741-66CDBF4120F9@thetimmy.com> > On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: > > On 03/26/2015 03:19 PM, Timothy Worman wrote: >> On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: >>> On 03/26/2015 07:37 PM, Timothy Worman wrote: >>>> Thanks everyone for the input. >>>> >>>> I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. >>>> >>>> 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. >>>> >>>> This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. >>> There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: >>> >>> ~~~ >>> from ipalib import api >>> from ipalib import errors >>> >>> api.bootstrap(context='cli') >>> api.finalize() >>> api.Backend.rpcclient.connect() >>> api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') >>> ~~~ >>> >>> What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? >> Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. >> >>> I would be willing to test option 4 if that is where the future is headed. >>> >>> Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. >> This may not be a bad thing if you?re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. > > So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Tim > >> Tim >> >>>> Tim >>>> >>>>> On Mar 24, 2015, at 12:58 AM, Martin Kosek wrote: >>>>> >>>>> On 03/24/2015 01:29 AM, Dmitri Pal wrote: >>>>>> On 03/23/2015 05:56 PM, Timothy Worman wrote: >>>>>>> I have an existing web app built with java/WebObjects that currently handles >>>>>>> some user/groups tasks with our current directory server (Open Directory). We >>>>>>> are investigating a move to FreeIPA for our directory services. >>>>>>> >>>>>>> Just in mucking around, I?ve found that if I try to insert a new user >>>>>>> (inetOrgPerson) into into IPA?s implementation, the new user does not inherit >>>>>>> all the object classes it should. It only inherits the ones leading to >>>>>>> inetOrgPerson. This does result in a successful inetOrgPerson insertion, but >>>>>>> that user record does not show up in the Web GUI management tools. >>>>>>> >>>>>>> Usually, I have focused on inetOrgPerson because that is where the bulk of >>>>>>> the info about a user lives. >>>>>>> >>>>>>> We have a SQL database that contains people in our organization (used by >>>>>>> other services), so, we need to be able to leverage that and push users into >>>>>>> IPA when appropriate and we have an existing app to do this. >>>>>>> >>>>>>> Tim W >>>>>>> >>>>>> You have several options: >>>>>> 1) Call ipa CLI from your application - this is possible right now (but not >>>>>> quite nice) >>>>>> 2) Call ipa JSON API from your application - this is not supported but >>>>>> possible. We use python API. You can do it in Java but it will be a lot of work. >>>>>> 3) Use more elaborate LDAP add commands (with all the object classes needed for >>>>>> users). Hard, but doable. >>>>>> 4) Help us with testing the upcoming feature >>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow >>>>>> creating users via simple ldap command in a staging area and them moving them >>>>>> to normal users area with automatic creation of missing attributes by means of >>>>>> a cron job. >>>>>> >>>>>> I would vote for 1) as a temp solution and 4) as a longer term one. >>>>> I do not fully agree with preferring 1) over 2). Java has libraries for >>>>> JSON-RPC protocol, it should be pretty doable to write a call that calls the >>>>> "user_add" command. >>>>> >>>>> We are lacking proper documentation for the API, but what you can look in the >>>>> sources or in the Web UI with and see the JSONs sent to the server, if you are >>>>> interested in the real life examples. >>>>> >>>>> Advantage of 2) over 1) is that you get the native objects (strings, arrays, >>>>> numbers) and you do not need to parse it from CLI. >>>>> >>>>> Martin > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From carlosla1987 at gmail.com Thu May 28 19:02:48 2015 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Thu, 28 May 2015 15:02:48 -0400 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: <20150528042535.GY19176@redhat.com> References: <55641791.2020702@redhat.com> <556572B6.40705@redhat.com> <20150527080853.GJ19176@redhat.com> <5565829F.4090005@redhat.com> <20150527084648.GL19176@redhat.com> <20150528042535.GY19176@redhat.com> Message-ID: Thanks for the clarifications, one more question, does FreeIPA support partial or fractional replications? Regards 2015-05-28 0:25 GMT-04:00 Alexander Bokovoy : > On Wed, 27 May 2015, Carlos Ra?l Laguna wrote: > >> Hello Martin, Alexander >> >> Seem that the time shift is large between us, If i understand correctly, >> compat tree will allow me to see all users, regardless they location >> Windows or FreeIPA, however the kolab-specific attribute must come from >> FreeIPA and Windows AD where the users entries lays. This means creating >> custom object classes and attributes for AD schema them update compat >> plugin to see the custom attribute. >> >> The second part where kolab needs to update some value in any of this >> attribute, for example mailQuota it would be rejected and therefor it must >> be done from Windows AD or FreeIPA, is this correct? Thanks both of you >> for >> your time and input in this matter. Regards >> > Just to make you absolutely clear: using compat tree will not help you > at all. Nothing else in FreeIPA could help you in getting Kolab to work > with both IPA and AD users at the same time. > > It would be nice if kolab could grow a capability to connect to multiple > LDAP servers at the same time, with non-overlapping user and group > trees. I don't think it is there now and I don't see other possibilities > here. > > > >> 2015-05-27 4:46 GMT-04:00 Alexander Bokovoy : >> >> On Wed, 27 May 2015, Martin Kosek wrote: >>> >>> On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: >>>> >>>> On Wed, 27 May 2015, Martin Kosek wrote: >>>>> >>>>> On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: >>>>>> >>>>>> Hello Martin, >>>>>>> >>>>>>> The email deployment it is a groupware in this scenario Kolab, kolab >>>>>>> use >>>>>>> 389 ad as main backend and it require some kolab ldap specific >>>>>>> attribute to >>>>>>> work properly, this is not a problem in fact is quite easy to use >>>>>>> freeipa >>>>>>> as kolab backend, so far so good but the romance only get this far. >>>>>>> Since >>>>>>> we also use Windows Ad with forest-trust not all user are present in >>>>>>> the >>>>>>> FreeIPA directory and there it is where my problem lays. Since not >>>>>>> all >>>>>>> user >>>>>>> are in the same box it become difficult to implement one mail system >>>>>>> for >>>>>>> all users. Regards >>>>>>> >>>>>>> >>>>>> As I said, we have compat tree that allows LDAP BIND authentication >>>>>> and >>>>>> LDAP >>>>>> identity (not enumeration) for both IPA users and AD users when realm >>>>>> is in >>>>>> place. >>>>>> >>>>>> You can even update the configuration of the compat tree and add the >>>>>> kolab >>>>>> specific fields to be generated there too. There was very similar >>>>>> request on >>>>>> freeipa-users. It was for vSphere, but dealing with very similar use >>>>>> case and >>>>>> the final solution: >>>>>> >>>>>> http://www.freeipa.org/page/HowTo/vsphere5_integration >>>>>> >>>>>> Would that approach work for you? >>>>>> >>>>>> I don't think it will work. compat tree is run-time read-only view of >>>>> the data coming from somewhere else. You need to have Kolab-specific >>>>> data available somewhere to be able to inject it in the compat tree. >>>>> Where would that data be stored for Kolab for AD-specific entries? >>>>> >>>>> >>>> It would work as long as the attributes are in the "real" user entries >>>> in >>>> form >>>> of custom attributes and compat plugin can be updated to add those to >>>> compat view. >>>> >>>> What real user entries you are talking about for AD users? >>> >>> Additionally, Kolab wants to modify these custom attributes and compat >>> >>>> tree simply does not support modification, they all are refused. >>>>> >>>>> >>>> If Kolab requires modifications, then this approach would not work with >>>> current >>>> FreeIPA implementation, yes. >>>> >>>> No, we are not going into enabling modifications over compat tree, this >>> is simply impossible to achieve, sorry. >>> -- >>> / 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 >> > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu May 28 19:26:08 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 21:26:08 +0200 Subject: [Freeipa-users] inserting users via java In-Reply-To: <57A332AB-964E-434A-B741-66CDBF4120F9@thetimmy.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> <55145326.80600@redhat.com> <55148354.9020405@redhat.com> <57A332AB-964E-434A-B741-66CDBF4120F9@thetimmy.com> Message-ID: <55676BD0.4090208@redhat.com> On 05/28/2015 07:10 PM, Timothy Worman wrote: >> On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: >> >> On 03/26/2015 03:19 PM, Timothy Worman wrote: >>> On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: >>>> On 03/26/2015 07:37 PM, Timothy Worman wrote: >>>>> Thanks everyone for the input. >>>>> >>>>> I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. >>>>> >>>>> 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. >>>>> >>>>> This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. >>>> There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: >>>> >>>> ~~~ >>>> from ipalib import api >>>> from ipalib import errors >>>> >>>> api.bootstrap(context='cli') >>>> api.finalize() >>>> api.Backend.rpcclient.connect() >>>> api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') >>>> ~~~ >>>> >>>> What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? >>> Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. >>> >>>> I would be willing to test option 4 if that is where the future is headed. >>>> >>>> Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. >>> This may not be a bad thing if you?re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. >> >> So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? > > Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Hello Timothy, I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... HTH, Martin From orion at cora.nwra.com Thu May 28 20:44:21 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 May 2015 14:44:21 -0600 Subject: [Freeipa-users] ipa-replica-prepare error Message-ID: <55677E25.5020705@cora.nwra.com> We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12 --http_pin=XXXX --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12 --http_pin=XXXX Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From abokovoy at redhat.com Thu May 28 20:53:50 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 28 May 2015 23:53:50 +0300 Subject: [Freeipa-users] inserting users via java In-Reply-To: <55676BD0.4090208@redhat.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> <55145326.80600@redhat.com> <55148354.9020405@redhat.com> <57A332AB-964E-434A-B741-66CDBF4120F9@thetimmy.com> <55676BD0.4090208@redhat.com> Message-ID: <20150528205350.GH19176@redhat.com> On Thu, 28 May 2015, Martin Kosek wrote: >On 05/28/2015 07:10 PM, Timothy Worman wrote: >>>On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: >>> >>>On 03/26/2015 03:19 PM, Timothy Worman wrote: >>>>On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: >>>>>On 03/26/2015 07:37 PM, Timothy Worman wrote: >>>>>>Thanks everyone for the input. >>>>>> >>>>>>I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. >>>>>> >>>>>>2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. >>>>>> >>>>>>This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. >>>>>There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: >>>>> >>>>>~~~ >>>>>from ipalib import api >>>>>from ipalib import errors >>>>> >>>>>api.bootstrap(context='cli') >>>>>api.finalize() >>>>>api.Backend.rpcclient.connect() >>>>>api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') >>>>>~~~ >>>>> >>>>>What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? >>>>Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. >>>> >>>>>I would be willing to test option 4 if that is where the future is headed. >>>>> >>>>>Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. >>>>This may not be a bad thing if you?re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. >>> >>>So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? >> >>Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? > >Hello Timothy, > >I am sorry we did not update this thread, but in the end we decided >not to invest in the REST interface ourselves at this moment (read - >FreeIPA 4.2), but rather work on stabilizing and documenting current >JSON-RPC API we have as we believe the API is easily usable from major >languages even though it is not RESTy. To prove our point, we need >good documentation of it and examples for the major languages. > >This is the proposal of what shall be done in FreeIPA 4.2 that I sent >to freeipa-devel: >http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html > >I hope the way we go for the next release is acceptable for you. In >the mean time, if you have specific questions on calling JSON from >your programs, both freeipa-users and freeipa-devel may be suitable, >depending on how deep you want to go in the code... I just published a blog post how to use JSON-RPC API in FreeIPA: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ -- / Alexander Bokovoy From lists at thetimmy.com Thu May 28 21:00:41 2015 From: lists at thetimmy.com (Timothy Worman) Date: Thu, 28 May 2015 14:00:41 -0700 Subject: [Freeipa-users] inserting users via java In-Reply-To: <55676BD0.4090208@redhat.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> <55145326.80600@redhat.com> <55148354.9020405@redhat.com> <57A332AB-964E-434A-B741-66CDBF4120F9@thetimmy.com> <55676BD0.4090208@redhat.com> Message-ID: On May 28, 2015, at 12:26 PM, Martin Kosek wrote: > > On 05/28/2015 07:10 PM, Timothy Worman wrote: >>> On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: >>> >>> On 03/26/2015 03:19 PM, Timothy Worman wrote: >>>> On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: >>>>> On 03/26/2015 07:37 PM, Timothy Worman wrote: >>>>>> Thanks everyone for the input. >>>>>> >>>>>> I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. >>>>>> >>>>>> 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. >>>>>> >>>>>> This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. >>>>> There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: >>>>> >>>>> ~~~ >>>>> from ipalib import api >>>>> from ipalib import errors >>>>> >>>>> api.bootstrap(context='cli') >>>>> api.finalize() >>>>> api.Backend.rpcclient.connect() >>>>> api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') >>>>> ~~~ >>>>> >>>>> What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? >>>> Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. >>>> >>>>> I would be willing to test option 4 if that is where the future is headed. >>>>> >>>>> Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. >>>> This may not be a bad thing if you?re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. >>> >>> So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? >> >> Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? > > Hello Timothy, > > I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. > > This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: > http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html > > I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... > > HTH, > Martin Thanks Martin: OK, just to verify - The staging approach (Dmitri spoke about) of inserting records into a staged user schema and having them inserted via a cron job is now off for near releases. I am anxious to see that happen. But, I am working on a java http client (apache httpclient + jaas/Krb5LoginModule) that posts json to the ipaserver. However, I am having some difficulty with kerberos negotiation and I should probably start a separate thread on that - either here or on freeipa-devel. Tim Worman UCLA GSE&IS From rcritten at redhat.com Thu May 28 21:09:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 May 2015 17:09:33 -0400 Subject: [Freeipa-users] ipa-replica-prepare error In-Reply-To: <55677E25.5020705@cora.nwra.com> References: <55677E25.5020705@cora.nwra.com> Message-ID: <5567840D.2090701@redhat.com> Orion Poplawski wrote: > We did a CAless install: > > ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat > /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt > --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12 > --http_pin=XXXX --idstart=8000 > > But now when we try to setup a replica: > > # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 > --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12 --http_pin=XXXX > Directory Manager (existing master) password: > > The full certificate chain is not present in nwra.com.p12 > > > p12 file was created with: > > openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey > /etc/pki/tls/private/nwra.com.key -certfile > /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 > > ipa-server-4.1.0-18.sl7_1.3.x86_64 > > Any thoughts? > At a glance your creation steps look ok. Strangely, the same code that loads the PKCS#12 files are used both in the server install and replica prepare, the only difference it seems is that with the server install we get a copy of the CA separately too. Can you provide the output of: pk12util -l nwra.com.p12 Maybe we can work out what it thinks is missing. rob From orion at cora.nwra.com Thu May 28 22:24:17 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 May 2015 16:24:17 -0600 Subject: [Freeipa-users] ipa-replica-prepare error In-Reply-To: <5567840D.2090701@redhat.com> References: <55677E25.5020705@cora.nwra.com> <5567840D.2090701@redhat.com> Message-ID: <55679591.4000101@cora.nwra.com> On 05/28/2015 03:09 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> We did a CAless install: >> >> ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat >> /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt >> --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12 >> --http_pin=XXXX --idstart=8000 >> >> But now when we try to setup a replica: >> >> # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 >> --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12 --http_pin=XXXX >> Directory Manager (existing master) password: >> >> The full certificate chain is not present in nwra.com.p12 >> >> >> p12 file was created with: >> >> openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey >> /etc/pki/tls/private/nwra.com.key -certfile >> /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 >> >> ipa-server-4.1.0-18.sl7_1.3.x86_64 >> >> Any thoughts? >> > > At a glance your creation steps look ok. Strangely, the same code that loads > the PKCS#12 files are used both in the server install and replica prepare, the > only difference it seems is that with the server install we get a copy of the > CA separately too. > > Can you provide the output of: pk12util -l nwra.com.p12 > > Maybe we can work out what it thinks is missing. > > rob I think I need to redo our install with an updated (SHA-2?) certificate, but I wouldn't think that would affect this issue either. # pk12util -l nwra.com.p12 Enter password for PKCS12 file: Certificate(has private key): Data: Version: 3 (0x2) Serial Number: 45:22:20:8d:d6:04:19:2a:b1:e7:e5:4f:5e:e0:30:0e Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=PositiveSSL CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB" Validity: Not Before: Thu Oct 11 00:00:00 2012 Not After : Tue Oct 10 23:59:59 2017 Subject: "CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Val idated" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d8:08:80:96:8f:f0:80:86:cd:f0:e7:6a:11:7f:8e:fb: 4b:95:6a:42:93:c7:cf:c3:76:80:bd:a6:cc:6c:fd:e2: 89:1a:3f:97:c1:3d:2d:fe:e4:4a:90:c5:aa:33:97:b3: 54:cc:67:73:57:2d:cb:9f:d0:27:ea:f0:d8:9b:5d:24: 94:2f:f5:84:06:d4:04:e8:83:c5:b2:40:b1:59:2c:f8: 4f:73:9c:41:fc:8d:46:3d:be:46:e7:9f:15:5d:8c:a5: 47:23:de:e2:cf:b3:be:97:ed:0c:82:3e:00:29:b7:8b: a0:86:92:ec:07:00:8b:35:77:1c:27:ba:c8:a0:80:dc: 9a:69:dd:99:89:df:b4:70:f6:f6:8c:23:8b:f9:1d:bf: ba:07:32:36:17:bc:25:e7:fb:7a:b0:11:86:de:88:59: 51:ed:e5:de:5e:14:e5:c0:28:ce:d3:5b:92:38:de:fa: 4b:15:9d:62:13:69:31:5a:0d:21:6e:2e:a6:c6:ae:30: 94:95:ce:e6:6c:dc:22:71:b4:1a:3a:f9:ec:4b:72:e4: 9d:82:ba:6b:a5:46:b0:b7:5a:23:22:d3:92:57:5b:bf: 55:fd:70:df:36:13:9c:a9:df:50:6e:62:43:23:13:eb: f5:ef:ee:c7:15:e0:46:37:21:9b:3d:86:ea:2c:c7:01 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 99:e4:40:5f:6b:14:5e:3e:05:d9:dd:d3:63:54:fc:62: b8:f7:00:ac Name: Certificate Subject Key ID Data: e9:88:f0:50:0f:f6:09:89:5c:3d:53:70:38:ca:82:22: 42:7e:21:e3 Name: Certificate Key Usage Critical: True Usages: Digital Signature Key Encipherment Name: Certificate Basic Constraints Critical: True Data: Is not a CA. Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6449.1.2.2.7 Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: "http://www.positivessl.com/CPS" Policy Name: OID.2.23.140.1.2.1 Name: CRL Distribution Points Distribution point: URI: "http://crl.comodoca.com/PositiveSSLCA2.crl" Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: "http://crt.comodoca.com/PositiveSSLCA2.crt" Method: PKIX Online Certificate Status Protocol Location: URI: "http://ocsp.comodoca.com" Name: Certificate Subject Alt Name DNS name: "*.nwra.com" DNS name: "nwra.com" Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 91:48:95:7d:ce:fa:42:46:16:57:a4:4d:35:0d:6f:67: 1e:96:eb:4f:78:ba:8b:99:cf:85:49:08:27:43:22:3a: 6b:69:45:0a:06:57:2b:23:e1:0f:d5:ed:4b:2c:b0:a6: 24:92:2c:cb:92:e0:60:be:88:8c:76:89:f0:37:94:28: 68:b4:09:26:c0:b0:c7:3a:b8:cb:92:c9:0b:02:0f:90: 10:9a:94:2b:d0:50:e9:1e:57:8f:ee:f9:1a:9b:8d:14: 57:29:13:38:e9:a1:b3:c2:1d:a4:e7:25:64:de:83:16: 6d:80:d9:b4:94:a2:bf:e1:8d:c2:1b:49:93:4e:61:c3: 14:a0:5f:ab:7d:c9:9f:ec:e3:2c:d1:7b:fc:ba:84:77: 11:52:55:01:d6:68:48:79:dc:ad:3b:a4:9e:ed:95:58: 79:da:7d:12:32:20:7c:5b:25:b9:c0:09:df:f2:c6:55: f7:ad:75:75:ca:fc:dd:d4:6a:04:4c:89:92:89:3c:39: c9:f4:6b:a2:a6:b6:c2:cb:59:e2:ab:f8:6d:c1:a9:49: 94:bc:d6:e6:44:98:04:53:1a:58:79:df:9c:f1:06:74: 7c:97:68:ff:86:c3:82:48:a1:2d:62:d4:31:bf:2f:b5: f6:e1:bc:6f:52:2c:7c:3e:7a:5f:a7:9a:a4:6c:f5:72 Fingerprint (SHA-256): 0C:C8:5C:1F:CB:EF:A6:E8:CA:EE:4E:D1:2C:20:67:A0:A0:29:8E:28:37:53:BC:40:93:81:19:47:8B:D2:CC:F8 Fingerprint (SHA1): 1B:73:6C:D5:AD:77:16:EF:71:E9:CB:AD:9D:16:D1:72:96:35:10:E9 Certificate: Data: Version: 3 (0x2) Serial Number: 07:6f:12:46:81:45:9c:28:d5:48:d6:97:c4:0e:00:1b Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=AddTrust External CA Root,OU=AddTrust External TTP Networ k,O=AddTrust AB,C=SE" Validity: Not Before: Thu Feb 16 00:00:00 2012 Not After : Sat May 30 10:48:38 2020 Subject: "CN=PositiveSSL CA 2,O=COMODO CA Limited,L=Salford,ST=Greate r Manchester,C=GB" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: e8:ea:39:e3:22:a6:aa:b9:c4:00:d0:e7:aa:67:3b:43: 07:bd:4f:92:eb:bc:be:01:a3:40:ad:e0:ef:44:28:b5: d0:3a:be:80:54:17:85:7a:6b:84:6c:36:36:e5:a3:24: e2:fe:28:01:90:bc:d7:dd:0f:b9:2b:4e:48:77:05:69: af:de:57:30:b1:e8:fb:1a:03:f6:3c:5b:53:1e:a1:01: 49:68:72:73:d6:33:2b:43:a9:37:32:52:0f:ae:27:56: 31:30:60:ad:c9:bd:73:2c:39:ee:90:d8:75:b0:25:21: 60:7b:2a:7f:02:fd:82:85:1f:74:4f:92:34:73:5c:1d: 00:a0:b0:c0:ea:98:e2:be:01:14:58:17:28:22:8a:77: 5d:50:25:cd:9a:6c:a6:e5:0c:e5:ab:28:c3:b2:20:89: f0:07:24:1e:95:c2:2e:c0:e5:e9:ec:f6:3d:12:07:48: 3d:d2:c3:23:56:41:ec:d3:df:35:4b:c8:e7:f6:86:05: 52:10:43:9a:8c:17:7c:8b:aa:bc:78:e0:f0:45:3b:ac: 80:55:fe:28:93:e1:0a:11:68:f4:52:57:6f:fe:48:0b: 5b:5d:1a:6a:67:73:99:82:b4:9e:43:60:3e:c7:5b:2a: 12:6e:1a:ee:cb:39:ae:c3:35:9d:a8:bc:5d:b0:2f:c3 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: ad:bd:98:7a:34:b4:26:f7:fa:c4:26:54:ef:03:bd:e0: 24:cb:54:1a Name: Certificate Subject Key ID Data: 99:e4:40:5f:6b:14:5e:3e:05:d9:dd:d3:63:54:fc:62: b8:f7:00:ac Name: Certificate Key Usage Critical: True Usages: Certificate Signing CRL Signing Name: Certificate Basic Constraints Critical: True Data: Is a CA with a maximum path length of 0. # pk12util -l nwra.com.p12 Enter password for PKCS12 file: Certificate(has private key): Data: Version: 3 (0x2) Serial Number: 45:22:20:8d:d6:04:19:2a:b1:e7:e5:4f:5e:e0:30:0e Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=PositiveSSL CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB" Validity: Not Before: Thu Oct 11 00:00:00 2012 Not After : Tue Oct 10 23:59:59 2017 Subject: "CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Val idated" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d8:08:80:96:8f:f0:80:86:cd:f0:e7:6a:11:7f:8e:fb: 4b:95:6a:42:93:c7:cf:c3:76:80:bd:a6:cc:6c:fd:e2: 89:1a:3f:97:c1:3d:2d:fe:e4:4a:90:c5:aa:33:97:b3: 54:cc:67:73:57:2d:cb:9f:d0:27:ea:f0:d8:9b:5d:24: 94:2f:f5:84:06:d4:04:e8:83:c5:b2:40:b1:59:2c:f8: 4f:73:9c:41:fc:8d:46:3d:be:46:e7:9f:15:5d:8c:a5: 47:23:de:e2:cf:b3:be:97:ed:0c:82:3e:00:29:b7:8b: a0:86:92:ec:07:00:8b:35:77:1c:27:ba:c8:a0:80:dc: 9a:69:dd:99:89:df:b4:70:f6:f6:8c:23:8b:f9:1d:bf: ba:07:32:36:17:bc:25:e7:fb:7a:b0:11:86:de:88:59: 51:ed:e5:de:5e:14:e5:c0:28:ce:d3:5b:92:38:de:fa: 4b:15:9d:62:13:69:31:5a:0d:21:6e:2e:a6:c6:ae:30: 94:95:ce:e6:6c:dc:22:71:b4:1a:3a:f9:ec:4b:72:e4: 9d:82:ba:6b:a5:46:b0:b7:5a:23:22:d3:92:57:5b:bf: 55:fd:70:df:36:13:9c:a9:df:50:6e:62:43:23:13:eb: f5:ef:ee:c7:15:e0:46:37:21:9b:3d:86:ea:2c:c7:01 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 99:e4:40:5f:6b:14:5e:3e:05:d9:dd:d3:63:54:fc:62: b8:f7:00:ac Name: Certificate Subject Key ID Data: e9:88:f0:50:0f:f6:09:89:5c:3d:53:70:38:ca:82:22: 42:7e:21:e3 Name: Certificate Key Usage Critical: True Usages: Digital Signature Key Encipherment Name: Certificate Basic Constraints Critical: True Data: Is not a CA. Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6449.1.2.2.7 Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: "http://www.positivessl.com/CPS" Policy Name: OID.2.23.140.1.2.1 Name: CRL Distribution Points Distribution point: URI: "http://crl.comodoca.com/PositiveSSLCA2.crl" Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: "http://crt.comodoca.com/PositiveSSLCA2.crt" Method: PKIX Online Certificate Status Protocol Location: URI: "http://ocsp.comodoca.com" Name: Certificate Subject Alt Name DNS name: "*.nwra.com" DNS name: "nwra.com" Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 91:48:95:7d:ce:fa:42:46:16:57:a4:4d:35:0d:6f:67: 1e:96:eb:4f:78:ba:8b:99:cf:85:49:08:27:43:22:3a: 6b:69:45:0a:06:57:2b:23:e1:0f:d5:ed:4b:2c:b0:a6: 24:92:2c:cb:92:e0:60:be:88:8c:76:89:f0:37:94:28: 68:b4:09:26:c0:b0:c7:3a:b8:cb:92:c9:0b:02:0f:90: 10:9a:94:2b:d0:50:e9:1e:57:8f:ee:f9:1a:9b:8d:14: 57:29:13:38:e9:a1:b3:c2:1d:a4:e7:25:64:de:83:16: 6d:80:d9:b4:94:a2:bf:e1:8d:c2:1b:49:93:4e:61:c3: 14:a0:5f:ab:7d:c9:9f:ec:e3:2c:d1:7b:fc:ba:84:77: 11:52:55:01:d6:68:48:79:dc:ad:3b:a4:9e:ed:95:58: 79:da:7d:12:32:20:7c:5b:25:b9:c0:09:df:f2:c6:55: f7:ad:75:75:ca:fc:dd:d4:6a:04:4c:89:92:89:3c:39: c9:f4:6b:a2:a6:b6:c2:cb:59:e2:ab:f8:6d:c1:a9:49: 94:bc:d6:e6:44:98:04:53:1a:58:79:df:9c:f1:06:74: 7c:97:68:ff:86:c3:82:48:a1:2d:62:d4:31:bf:2f:b5: f6:e1:bc:6f:52:2c:7c:3e:7a:5f:a7:9a:a4:6c:f5:72 Fingerprint (SHA-256): 0C:C8:5C:1F:CB:EF:A6:E8:CA:EE:4E:D1:2C:20:67:A0:A0:29:8E:28:37:53:BC:40:93:81:19:47:8B:D2:CC:F8 Fingerprint (SHA1): 1B:73:6C:D5:AD:77:16:EF:71:E9:CB:AD:9D:16:D1:72:96:35:10:E9 Certificate: Data: Version: 3 (0x2) Serial Number: 07:6f:12:46:81:45:9c:28:d5:48:d6:97:c4:0e:00:1b Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=AddTrust External CA Root,OU=AddTrust External TTP Networ k,O=AddTrust AB,C=SE" Validity: Not Before: Thu Feb 16 00:00:00 2012 Not After : Sat May 30 10:48:38 2020 Subject: "CN=PositiveSSL CA 2,O=COMODO CA Limited,L=Salford,ST=Greate r Manchester,C=GB" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: e8:ea:39:e3:22:a6:aa:b9:c4:00:d0:e7:aa:67:3b:43: 07:bd:4f:92:eb:bc:be:01:a3:40:ad:e0:ef:44:28:b5: d0:3a:be:80:54:17:85:7a:6b:84:6c:36:36:e5:a3:24: e2:fe:28:01:90:bc:d7:dd:0f:b9:2b:4e:48:77:05:69: af:de:57:30:b1:e8:fb:1a:03:f6:3c:5b:53:1e:a1:01: 49:68:72:73:d6:33:2b:43:a9:37:32:52:0f:ae:27:56: 31:30:60:ad:c9:bd:73:2c:39:ee:90:d8:75:b0:25:21: 60:7b:2a:7f:02:fd:82:85:1f:74:4f:92:34:73:5c:1d: 00:a0:b0:c0:ea:98:e2:be:01:14:58:17:28:22:8a:77: 5d:50:25:cd:9a:6c:a6:e5:0c:e5:ab:28:c3:b2:20:89: f0:07:24:1e:95:c2:2e:c0:e5:e9:ec:f6:3d:12:07:48: 3d:d2:c3:23:56:41:ec:d3:df:35:4b:c8:e7:f6:86:05: 52:10:43:9a:8c:17:7c:8b:aa:bc:78:e0:f0:45:3b:ac: 80:55:fe:28:93:e1:0a:11:68:f4:52:57:6f:fe:48:0b: 5b:5d:1a:6a:67:73:99:82:b4:9e:43:60:3e:c7:5b:2a: 12:6e:1a:ee:cb:39:ae:c3:35:9d:a8:bc:5d:b0:2f:c3 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: ad:bd:98:7a:34:b4:26:f7:fa:c4:26:54:ef:03:bd:e0: 24:cb:54:1a Name: Certificate Subject Key ID Data: 99:e4:40:5f:6b:14:5e:3e:05:d9:dd:d3:63:54:fc:62: b8:f7:00:ac Name: Certificate Key Usage Critical: True Usages: Certificate Signing CRL Signing Name: Certificate Basic Constraints Critical: True Data: Is a CA with a maximum path length of 0. Name: Certificate Policies Data: Policy Name: Certificate Policies AnyPolicy Name: CRL Distribution Points Distribution point: URI: "http://crl.usertrust.com/AddTrustExternalCARoot.crl" Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: "http://crt.usertrust.com/AddTrustExternalCARoot.p7c" Method: PKIX CA issuers access method Location: URI: "http://crt.usertrust.com/AddTrustUTNSGCCA.crt" Method: PKIX Online Certificate Status Protocol Location: URI: "http://ocsp.usertrust.com" Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 9c:36:e3:4e:ae:f1:8a:bb:6c:97:8c:8f:4b:67:d0:9f: d8:84:aa:9f:21:5f:35:a1:5b:c4:2b:63:0d:e8:bc:77: 5d:a7:c4:37:fd:4b:2d:9e:e8:1d:69:a1:c0:84:cc:d1: 6d:8b:f3:81:cb:9f:4b:74:b0:49:2a:31:e8:37:40:eb: 1f:d9:97:a3:1a:11:d5:26:a7:6e:0f:ba:d5:be:2c:fd: b4:91:64:dc:be:3b:19:50:0d:7a:95:f3:04:13:a9:bb: 47:0f:8b:5c:d1:ac:c2:7b:77:21:50:dd:5b:ab:ee:f4: a6:d8:d4:4a:53:6b:4d:ad:b8:c8:e7:e6:52:58:4d:43: 4c:c2:a2:23:4f:0e:c0:20:39:af:df:4f:42:5b:1e:d3: 09:f4:18:09:59:2a:d9:e8:4a:18:bf:32:fb:fa:2d:64: 8b:87:ca:5b:2b:e8:b8:0b:7e:be:17:12:c7:03:82:29: af:58:af:85:84:5d:3d:0a:df:23:51:c3:cd:af:10:bf: 80:69:77:91:0a:4f:e5:ba:e1:ad:9b:ce:df:33:4e:30: 3b:e9:8f:66:7f:82:fa:6b:fa:db:a3:c0:73:00:e3:d6: 12:af:4d:f2:0f:5a:14:51:1f:6d:b8:86:81:62:07:ce: 5c:72:c2:4f:f3:57:2a:71:d9:d4:97:85:e6:18:53:b7 Fingerprint (SHA-256): 44:75:53:4D:BB:11:47:14:C6:28:D3:EE:F2:18:11:00:2D:6C:CE:CC:43:28:E4:15:87:73:22:51:E4:24:F8:A6 Fingerprint (SHA1): 94:80:7B:1C:78:8D:D2:FC:BE:19:C8:48:1C:E4:1C:FA:B8:A4:C1:7F Key(shrouded): Encryption algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC Parameters: Salt: f0:6c:0b:29:47:50:d8:b3 Iteration Count: 2048 (0x800) Name: Certificate Policies Data: Policy Name: Certificate Policies AnyPolicy Name: CRL Distribution Points Distribution point: URI: "http://crl.usertrust.com/AddTrustExternalCARoot.crl" Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: "http://crt.usertrust.com/AddTrustExternalCARoot.p7c" Method: PKIX CA issuers access method Location: URI: "http://crt.usertrust.com/AddTrustUTNSGCCA.crt" Method: PKIX Online Certificate Status Protocol Location: URI: "http://ocsp.usertrust.com" Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 9c:36:e3:4e:ae:f1:8a:bb:6c:97:8c:8f:4b:67:d0:9f: d8:84:aa:9f:21:5f:35:a1:5b:c4:2b:63:0d:e8:bc:77: 5d:a7:c4:37:fd:4b:2d:9e:e8:1d:69:a1:c0:84:cc:d1: 6d:8b:f3:81:cb:9f:4b:74:b0:49:2a:31:e8:37:40:eb: 1f:d9:97:a3:1a:11:d5:26:a7:6e:0f:ba:d5:be:2c:fd: b4:91:64:dc:be:3b:19:50:0d:7a:95:f3:04:13:a9:bb: 47:0f:8b:5c:d1:ac:c2:7b:77:21:50:dd:5b:ab:ee:f4: a6:d8:d4:4a:53:6b:4d:ad:b8:c8:e7:e6:52:58:4d:43: 4c:c2:a2:23:4f:0e:c0:20:39:af:df:4f:42:5b:1e:d3: 09:f4:18:09:59:2a:d9:e8:4a:18:bf:32:fb:fa:2d:64: 8b:87:ca:5b:2b:e8:b8:0b:7e:be:17:12:c7:03:82:29: af:58:af:85:84:5d:3d:0a:df:23:51:c3:cd:af:10:bf: 80:69:77:91:0a:4f:e5:ba:e1:ad:9b:ce:df:33:4e:30: 3b:e9:8f:66:7f:82:fa:6b:fa:db:a3:c0:73:00:e3:d6: 12:af:4d:f2:0f:5a:14:51:1f:6d:b8:86:81:62:07:ce: 5c:72:c2:4f:f3:57:2a:71:d9:d4:97:85:e6:18:53:b7 Fingerprint (SHA-256): 44:75:53:4D:BB:11:47:14:C6:28:D3:EE:F2:18:11:00:2D:6C:CE:CC:43:28:E4:15:87:73:22:51:E4:24:F8:A6 Fingerprint (SHA1): 94:80:7B:1C:78:8D:D2:FC:BE:19:C8:48:1C:E4:1C:FA:B8:A4:C1:7F Key(shrouded): Encryption algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC Parameters: Salt: f0:6c:0b:29:47:50:d8:b3 Iteration Count: 2048 (0x800) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From linhai88 at stanford.edu Thu May 28 23:27:08 2015 From: linhai88 at stanford.edu (David Lin) Date: Thu, 28 May 2015 16:27:08 -0700 Subject: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE Message-ID: Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. Thanks, David From christoph.kaminski at biotronik.com Fri May 29 05:48:25 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Fri, 29 May 2015 07:48:25 +0200 Subject: [Freeipa-users] dirsrv keytab revoked Message-ID: Hi I have had a defect entries in ldap for a replica and deleted them. But now the dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The replica starts but it cant connect other replicas (but other replicas can connect to it). I have tried: kinit -k -t /etc/dirsrv/ds.keytab ldap/ipa-1.mgmt.testsystem-homemonitoring.int and got: kinit: Clients credentials have been revoked while getting initial credentials It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab (on this replica) doesnt work. Or it is better to destroy it and do a new install? MfG Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.kaminski at biotronik.com Fri May 29 06:16:21 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Fri, 29 May 2015 08:16:21 +0200 Subject: [Freeipa-users] Antwort: Re: Haunted servers? In-Reply-To: <952adf58d9014ddeab0c19fa79448000@sib-ums03.Megafon.ru> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> <5566C887.4050206@redhat.com> <2edca1d40b1942e99a98e075a50659af@sib-ums03.Megafon.ru> <5566F9A6.2080205@redhat.com> <952adf58d9014ddeab0c19fa79448000@sib-ums03.Megafon.ru> Message-ID: freeipa-users-bounces at redhat.com schrieb am 28.05.2015 13:23:26: > Von: Alexander Frolushkin > An: "'thierry bordaz'" > Kopie: "freeipa-users at redhat.com" > Datum: 28.05.2015 13:24 > Betreff: Re: [Freeipa-users] Haunted servers? > Gesendet von: freeipa-users-bounces at redhat.com > > Unfortunately, after a couple of minutes, on two of three servers > error comes back in little changed form: > # ipa-replica-manage list-ruv > unable to decode: {replica 16} > .... > > Before cleanruv it looked like: > # ipa-replica-manage list-ruv > unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 > .... > > And one server seems to be fixed completely. > > WBR, > Alexander Frolushkin > > we had the same problem (and some more) and yesterday we have successfully cleaned the gohst rid's our fix: 1. stop all cleanallruv Tasks, if it works with ipa-replica-manage abort-clean-ruv. It hasnt worked here. We have done it manually on ALL replicas with: a) replica stop b) delete all nsds5ReplicaClean from /etc/dirsrv/slapd-HSO/dse.ldif c) replica start 2. prepare on EACH ipa a cleanruv ldif file with ALL ghost rids inside (really ALL from all ipa replicas, we has had some rids only on some replicas...) Example: dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config changetype: modify replace: nsds5task nsds5task:CLEANRUV11 dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config changetype: modify replace: nsds5task nsds5task:CLEANRUV22 dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config changetype: modify replace: nsds5task nsds5task:CLEANRUV37 ... 3. do a "ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -W -x -f $your-cleanruv-file.ldif" on all replicas AT THE SAME TIME :) we used terminator for it (https://launchpad.net/terminator). You can open multiple shell windows inside one window and send to all at the same time the same commands... 4. we have done a re-initialize of each IPA from our first master 5. restart of all replicas we are not sure about the point 3 and 4. Maybe they are not necessary, but we have done it. If something fails look at defect LDAP entries in whole ldap, we have had some entries with 'nsunique-$HASH' after the 'normal' name. We have deleted them. MfG Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri May 29 06:39:23 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 08:39:23 +0200 Subject: [Freeipa-users] inserting users via java In-Reply-To: References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> <55145326.80600@redhat.com> <55148354.9020405@redhat.com> <57A332AB-964E-434A-B741-66CDBF4120F9@thetimmy.com> <55676BD0.4090208@redhat.com> Message-ID: <5568099B.6060303@redhat.com> On 05/28/2015 11:00 PM, Timothy Worman wrote: > On May 28, 2015, at 12:26 PM, Martin Kosek wrote: >> >> On 05/28/2015 07:10 PM, Timothy Worman wrote: >>>> On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: >>>> >>>> On 03/26/2015 03:19 PM, Timothy Worman wrote: >>>>> On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: >>>>>> On 03/26/2015 07:37 PM, Timothy Worman wrote: >>>>>>> Thanks everyone for the input. >>>>>>> >>>>>>> I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. >>>>>>> >>>>>>> 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. >>>>>>> >>>>>>> This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. >>>>>> There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: >>>>>> >>>>>> ~~~ >>>>>> from ipalib import api >>>>>> from ipalib import errors >>>>>> >>>>>> api.bootstrap(context='cli') >>>>>> api.finalize() >>>>>> api.Backend.rpcclient.connect() >>>>>> api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') >>>>>> ~~~ >>>>>> >>>>>> What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? >>>>> Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. >>>>> >>>>>> I would be willing to test option 4 if that is where the future is headed. >>>>>> >>>>>> Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. >>>>> This may not be a bad thing if you?re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. >>>> >>>> So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? >>> >>> Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? >> >> Hello Timothy, >> >> I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. >> >> This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: >> http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html >> >> I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... >> >> HTH, >> Martin > > Thanks Martin: > > OK, just to verify - The staging approach (Dmitri spoke about) of inserting records into a staged user schema and having them inserted via a cron job is now off for near releases. I am anxious to see that happen. Ah, looks I misread the thread branches about what was actually promised. The FreeIPA User Life Cycle feature (staging users can be added via LDAP and later activated) *is* going to FreeIPA 4.2 and is actually mostly implemented, it will be part of FreeIPA 4.2 Alpha release, so you can try it out then. This is the upstream tracker: https://fedorahosted.org/freeipa/ticket/3813 > But, I am working on a java http client (apache httpclient + jaas/Krb5LoginModule) that posts json to the ipaserver. However, I am having some difficulty with kerberos negotiation and I should probably start a separate thread on that - either here or on freeipa-devel. Ok. Feel free to ask. I do not expect too big problems with JSON&Kerberos. AFAIK, you do not need to even need to use JSON calls and Kerberos at the same time. With FreeIPA, you can simply login to the API via HTTPS+SPNEGO, get a session code and use that for HTTPS JSON API calls (this helps if a JSON library cannot do Kerberos auth out of the box). Martin From tbordaz at redhat.com Fri May 29 07:41:28 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 29 May 2015 09:41:28 +0200 Subject: [Freeipa-users] Antwort: Re: Haunted servers? In-Reply-To: References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> <5566C887.4050206@redhat.com> <2edca1d40b1942e99a98e075a50659af@sib-ums03.Megafon.ru> <5566F9A6.2080205@redhat.com> <952adf58d9014ddeab0c19fa79448000@sib-ums03.Megafon.ru> Message-ID: <55681828.2060208@redhat.com> On 05/29/2015 08:16 AM, Christoph Kaminski wrote: > freeipa-users-bounces at redhat.com schrieb am 28.05.2015 13:23:26: > > > Von: Alexander Frolushkin > > An: "'thierry bordaz'" > > Kopie: "freeipa-users at redhat.com" > > Datum: 28.05.2015 13:24 > > Betreff: Re: [Freeipa-users] Haunted servers? > > Gesendet von: freeipa-users-bounces at redhat.com > > > > Unfortunately, after a couple of minutes, on two of three servers > > error comes back in little changed form: > > # ipa-replica-manage list-ruv > > unable to decode: {replica 16} > > .... > > > > Before cleanruv it looked like: > > # ipa-replica-manage list-ruv > > unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 > > .... > > > > And one server seems to be fixed completely. > > > > WBR, > > Alexander Frolushkin > > > > > > we had the same problem (and some more) and yesterday we have > successfully cleaned the gohst rid's > > our fix: Hi Christoph, THanks for sharing this procedure. This bug is difficult to workaround and that is a good idea to write it down. > > 1. stop all cleanallruv Tasks, if it works with ipa-replica-manage > abort-clean-ruv. It hasnt worked here. We have done it manually on ALL > replicas with: > a) replica stop > b) delete all nsds5ReplicaClean from > /etc/dirsrv/slapd-HSO/dse.ldif > c) replica start > Yes the ability to abort clean ruv hits the same retry issue that cleanallruv. It has been addressed with https://fedorahosted.org/389/ticket/48154 > 2. prepare on EACH ipa a cleanruv ldif file with ALL ghost rids inside > (really ALL from all ipa replicas, we has had some rids only on some > replicas...) > Example: > > dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config > changetype: modify > replace: nsds5task > nsds5task:CLEANRUV11 > > dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config > changetype: modify > replace: nsds5task > nsds5task:CLEANRUV22 > > dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config > changetype: modify > replace: nsds5task > nsds5task:CLEANRUV37 > ... It should work but I would prefer to do it in an other order. We need to clean a specific RID, on all replica, at the same time. We do not need to clean all RIDs at the same time. Having several CLEANRUV in parallel for differents RID should work but I do not know how much it has been tested that way. So I would recommend to clean, in parallel on all replicas, RID 11. Then when it is completed, RID 22. Then RID 37. > > 3. do a "ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -W -x -f > $your-cleanruv-file.ldif" on all replicas AT THE SAME TIME :) we used > terminator for it (https://launchpad.net/terminator). You can open > multiple shell windows inside one window and send to all at the same > time the same commands... same remark I would split your-cleanruv-file.ldif into three files cleanruv-11-file.ldif,... > > 4. we have done a re-initialize of each IPA from our first master Do you mean a total init ? I do not see a real need for that. If you are ready to reinit all replicas, there is a very simple way to get rid of all these ghost RIDs. * Select the "good" master that is having all the updates * do a ldif export without the replication data * do a ldif import of exported file * do online reinit of the full topology, cascading from the "good" master down to the "consumers" Most of the time we try to avoid asking a full reinit of the topology because DB are large. > > 5. restart of all replicas > > we are not sure about the point 3 and 4. Maybe they are not necessary, > but we have done it. > > If something fails look at defect LDAP entries in whole ldap, we have > had some entries with 'nsunique-$HASH' after the 'normal' name. We > have deleted them. do you mean entries with 'nsuniqueid' attribute in the RDN. This could be create during replication conflicts when updates are received in parallele on different replicas. thanks thierry > > MfG > Christoph Kaminski > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri May 29 07:59:52 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 09:59:52 +0200 Subject: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario. In-Reply-To: References: <55641791.2020702@redhat.com> <556572B6.40705@redhat.com> <20150527080853.GJ19176@redhat.com> <5565829F.4090005@redhat.com> <20150527084648.GL19176@redhat.com> <20150528042535.GY19176@redhat.com> Message-ID: <55681C78.3030301@redhat.com> Only a very basic "fractional replication" - you can remove selected attributes from replicating. It is possible even now and can be configured on each replication agreement: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/managing-fractional-repl.html In FreeIPA 4.2, it should be possible to set that centrally: https://fedorahosted.org/freeipa/ticket/4302 Martin On 05/28/2015 09:02 PM, Carlos Ra?l Laguna wrote: > Thanks for the clarifications, one more question, does FreeIPA support partial > or fractional replications? Regards > > 2015-05-28 0:25 GMT-04:00 Alexander Bokovoy >: > > On Wed, 27 May 2015, Carlos Ra?l Laguna wrote: > > Hello Martin, Alexander > > Seem that the time shift is large between us, If i understand correctly, > compat tree will allow me to see all users, regardless they location > Windows or FreeIPA, however the kolab-specific attribute must come from > FreeIPA and Windows AD where the users entries lays. This means creating > custom object classes and attributes for AD schema them update compat > plugin to see the custom attribute. > > The second part where kolab needs to update some value in any of this > attribute, for example mailQuota it would be rejected and therefor it must > be done from Windows AD or FreeIPA, is this correct? Thanks both of you for > your time and input in this matter. Regards > > Just to make you absolutely clear: using compat tree will not help you > at all. Nothing else in FreeIPA could help you in getting Kolab to work > with both IPA and AD users at the same time. > > It would be nice if kolab could grow a capability to connect to multiple > LDAP servers at the same time, with non-overlapping user and group > trees. I don't think it is there now and I don't see other possibilities > here. > > > > 2015-05-27 4:46 GMT-04:00 Alexander Bokovoy >: > > On Wed, 27 May 2015, Martin Kosek wrote: > > On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: > > On Wed, 27 May 2015, Martin Kosek wrote: > > On 05/26/2015 07:36 PM, Carlos Ra?l Laguna wrote: > > Hello Martin, > > The email deployment it is a groupware in this > scenario Kolab, kolab > use > 389 ad as main backend and it require some kolab > ldap specific > attribute to > work properly, this is not a problem in fact is > quite easy to use > freeipa > as kolab backend, so far so good but the romance > only get this far. > Since > we also use Windows Ad with forest-trust not all > user are present in > the > FreeIPA directory and there it is where my problem > lays. Since not all > user > are in the same box it become difficult to > implement one mail system > for > all users. Regards > > > As I said, we have compat tree that allows LDAP BIND > authentication and > LDAP > identity (not enumeration) for both IPA users and AD > users when realm > is in > place. > > You can even update the configuration of the compat > tree and add the > kolab > specific fields to be generated there too. There was > very similar > request on > freeipa-users. It was for vSphere, but dealing with > very similar use > case and > the final solution: > > http://www.freeipa.org/page/HowTo/vsphere5_integration > > Would that approach work for you? > > I don't think it will work. compat tree is run-time > read-only view of > the data coming from somewhere else. You need to have > Kolab-specific > data available somewhere to be able to inject it in the > compat tree. > Where would that data be stored for Kolab for AD-specific > entries? > > > It would work as long as the attributes are in the "real" user > entries in > form > of custom attributes and compat plugin can be updated to add > those to > compat view. > > What real user entries you are talking about for AD users? > > Additionally, Kolab wants to modify these custom attributes and > compat > > tree simply does not support modification, they all are > refused. > > > If Kolab requires modifications, then this approach would not > work with > current > FreeIPA implementation, yes. > > No, we are not going into enabling modifications over compat tree, this > is simply impossible to achieve, sorry. > -- > / 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 > > > > -- > / Alexander Bokovoy > > > > From mkosek at redhat.com Fri May 29 08:02:55 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 10:02:55 +0200 Subject: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE In-Reply-To: References: Message-ID: <55681D2F.6050900@redhat.com> On 05/29/2015 01:27 AM, David Lin wrote: > Hi, > When I try to add multiple hosts, on the web UI, when I go to the host tab, I get > Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. > > What does this mean? That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was somehow damaged? Although I doubt that, in that case Apache would not be able to serve https even. > On one of the hosts, I do notice that when i do > > ipa host-show > > there is no certificate listed. If you are using FreeIPA 4.1+, this is expected: https://fedorahosted.org/freeipa/ticket/4449 Martin From mkosek at redhat.com Fri May 29 08:06:45 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 10:06:45 +0200 Subject: [Freeipa-users] dirsrv keytab revoked In-Reply-To: References: Message-ID: <55681E15.7000603@redhat.com> On 05/29/2015 07:48 AM, Christoph Kaminski wrote: > Hi > > I have had a defect entries in ldap for a replica and deleted them. But now the > dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The > replica starts but it cant connect other replicas (but other replicas can > connect to it). > > I have tried: > kinit -k -t /etc/dirsrv/ds.keytab ldap/ipa-1.mgmt.testsystem-homemonitoring.int > > and got: > kinit: Clients credentials have been revoked while getting initial credentials > > It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab > (on this replica) doesnt work. Running ipa-getkeytab on this replica is tricky - as if replication is down and you do this, the old key is revoked and new one is generated - which is not known for the other master as replication is not working and you get in a strange situation. You can try to log to your active master, do ipa-getkeytab for the broken replica, copy the keytab there, restart DS and then run re-initialize to reload all the data from active master. It may work. > Or it is better to destroy it and do a new install? That may be even faster for the making that particular replica up and running again, if you do not want to dig too much in this issue. From pvoborni at redhat.com Fri May 29 08:35:43 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 May 2015 10:35:43 +0200 Subject: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE In-Reply-To: <55681D2F.6050900@redhat.com> References: <55681D2F.6050900@redhat.com> Message-ID: <556824DF.7070308@redhat.com> On 05/29/2015 10:02 AM, Martin Kosek wrote: > On 05/29/2015 01:27 AM, David Lin wrote: >> Hi, >> When I try to add multiple hosts, on the web UI, when I go to the host >> tab, This means that Web UI calls `ipa host-find` and couple of `ipa host-show` commands. Could you try it in CLI find out which command fails? So other web ui tabs work? Does service tab work(services has some common logic with hosts)? > I get >> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >> certificate/key database is in an old, unsupported format. >> >> What does this mean? NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database directory (for any reason, including non-existent directory) > > That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was > somehow damaged? Although I doubt that, in that case Apache would not be > able to serve https even. +1 > >> On one of the hosts, I do notice that when i do >> >> ipa host-show >> >> there is no certificate listed. > > If you are using FreeIPA 4.1+, this is expected: > > https://fedorahosted.org/freeipa/ticket/4449 > > Martin > -- Petr Vobornik From linhai88 at stanford.edu Fri May 29 08:45:12 2015 From: linhai88 at stanford.edu (David Lin) Date: Fri, 29 May 2015 01:45:12 -0700 Subject: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE In-Reply-To: <556824DF.7070308@redhat.com> References: <55681D2F.6050900@redhat.com> <556824DF.7070308@redhat.com> Message-ID: <02351C6D-BB0C-4D9C-A6F5-F79B4C6C4E70@stanford.edu> ipa host-find produces this ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. and ipa host-show on only one of the hosts show ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. all the other hosts are fine. Thanks! David > On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: > > On 05/29/2015 10:02 AM, Martin Kosek wrote: >> On 05/29/2015 01:27 AM, David Lin wrote: >>> Hi, >>> When I try to add multiple hosts, on the web UI, when I go to the host >>> tab, > > This means that Web UI calls `ipa host-find` and couple of `ipa host-show` commands. Could you try it in CLI find out which command fails? > > So other web ui tabs work? Does service tab work(services has some common logic with hosts)? > >> I get >>> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>> certificate/key database is in an old, unsupported format. >>> >>> What does this mean? > > NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database directory (for any reason, including non-existent directory) > >> >> That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was >> somehow damaged? Although I doubt that, in that case Apache would not be >> able to serve https even. > > +1 > >> >>> On one of the hosts, I do notice that when i do >>> >>> ipa host-show >>> >>> there is no certificate listed. >> >> If you are using FreeIPA 4.1+, this is expected: >> >> https://fedorahosted.org/freeipa/ticket/4449 >> >> Martin >> > > -- > Petr Vobornik From pspacek at redhat.com Fri May 29 08:58:01 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 29 May 2015 10:58:01 +0200 Subject: [Freeipa-users] dirsrv keytab revoked In-Reply-To: <55681E15.7000603@redhat.com> References: <55681E15.7000603@redhat.com> Message-ID: <55682A19.6020709@redhat.com> On 29.5.2015 10:06, Martin Kosek wrote: > On 05/29/2015 07:48 AM, Christoph Kaminski wrote: >> Hi >> >> I have had a defect entries in ldap for a replica and deleted them. But now the >> dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The >> replica starts but it cant connect other replicas (but other replicas can >> connect to it). >> >> I have tried: >> kinit -k -t /etc/dirsrv/ds.keytab ldap/ipa-1.mgmt.testsystem-homemonitoring.int >> >> and got: >> kinit: Clients credentials have been revoked while getting initial credentials >> >> It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab >> (on this replica) doesnt work. > > Running ipa-getkeytab on this replica is tricky - as if replication is down > and you do this, the old key is revoked and new one is generated - which is > not known for the other master as replication is not working and you get in a > strange situation. > > You can try to log to your active master, do ipa-getkeytab for the broken > replica, copy the keytab there, restart DS and then run re-initialize to > reload all the data from active master. It may work. > >> Or it is better to destroy it and do a new install? > > That may be even faster for the making that particular replica up and running > again, if you do not want to dig too much in this issue. It might happen that keytab is actually valid but the principal just is locked out. In that case following LDIF should fix the problem: dn: krbprincipalname=ldap/ipa-1.mgmt.testsystem-homemonitoring.int@,cn=services,cn=accounts, changetype: modify delete: krbLoginFailedCount - delete: krbLastFailedAuth - You need to run ldapmodify with Directory manager's credentials. I hope this helps. -- Petr^2 Spacek From pvoborni at redhat.com Fri May 29 09:05:48 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 May 2015 11:05:48 +0200 Subject: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE In-Reply-To: <02351C6D-BB0C-4D9C-A6F5-F79B4C6C4E70@stanford.edu> References: <55681D2F.6050900@redhat.com> <556824DF.7070308@redhat.com> <02351C6D-BB0C-4D9C-A6F5-F79B4C6C4E70@stanford.edu> Message-ID: <55682BEC.2070705@redhat.com> On 05/29/2015 10:45 AM, David Lin wrote: > ipa host-find produces this > ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. > > and ipa host-show on only one of the hosts show > ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. > > all the other hosts are fine. Does any other host have certificate set? I want to find out if it fails on a specific certificate and not on other(s) or if it fails for all hosts with certificate set. SEC_ERROR_LEGACY_DATABASE error suggests that it fails on initialization of NSS database which is not dependent on stored certificate. > > Thanks! > David > >> On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: >> >> On 05/29/2015 10:02 AM, Martin Kosek wrote: >>> On 05/29/2015 01:27 AM, David Lin wrote: >>>> Hi, >>>> When I try to add multiple hosts, on the web UI, when I go to the host >>>> tab, >> >> This means that Web UI calls `ipa host-find` and couple of `ipa host-show` commands. Could you try it in CLI find out which command fails? >> >> So other web ui tabs work? Does service tab work(services has some common logic with hosts)? >> >>> I get >>>> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>>> certificate/key database is in an old, unsupported format. >>>> >>>> What does this mean? >> >> NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database directory (for any reason, including non-existent directory) >> >>> >>> That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was >>> somehow damaged? Although I doubt that, in that case Apache would not be >>> able to serve https even. >> >> +1 >> >>> >>>> On one of the hosts, I do notice that when i do >>>> >>>> ipa host-show >>>> >>>> there is no certificate listed. >>> >>> If you are using FreeIPA 4.1+, this is expected: >>> >>> https://fedorahosted.org/freeipa/ticket/4449 >>> >>> Martin >>> >> >> -- >> Petr Vobornik > > -- Petr Vobornik From linhai88 at stanford.edu Fri May 29 09:18:15 2015 From: linhai88 at stanford.edu (David Lin) Date: Fri, 29 May 2015 02:18:15 -0700 Subject: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE In-Reply-To: <55682BEC.2070705@redhat.com> References: <55681D2F.6050900@redhat.com> <556824DF.7070308@redhat.com> <02351C6D-BB0C-4D9C-A6F5-F79B4C6C4E70@stanford.edu> <55682BEC.2070705@redhat.com> Message-ID: <55682ED7.4050607@stanford.edu> the other hosts do not have certificate set. Thanks, David On 05/29/2015 02:05 AM, Petr Vobornik wrote: > On 05/29/2015 10:45 AM, David Lin wrote: >> ipa host-find produces this >> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >> certificate/key database is in an old, unsupported format. >> >> and ipa host-show on only one of the hosts show >> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >> certificate/key database is in an old, unsupported format. >> >> all the other hosts are fine. > > Does any other host have certificate set? I want to find out if it > fails on a specific certificate and not on other(s) or if it fails for > all hosts with certificate set. > > SEC_ERROR_LEGACY_DATABASE error suggests that it fails on > initialization of NSS database which is not dependent on stored > certificate. > >> >> Thanks! >> David >> >>> On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: >>> >>> On 05/29/2015 10:02 AM, Martin Kosek wrote: >>>> On 05/29/2015 01:27 AM, David Lin wrote: >>>>> Hi, >>>>> When I try to add multiple hosts, on the web UI, when I go to the >>>>> host >>>>> tab, >>> >>> This means that Web UI calls `ipa host-find` and couple of `ipa >>> host-show` commands. Could you try it in CLI find out which command >>> fails? >>> >>> So other web ui tabs work? Does service tab work(services has some >>> common logic with hosts)? >>> >>>> I get >>>>> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>>>> certificate/key database is in an old, unsupported format. >>>>> >>>>> What does this mean? >>> >>> NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the >>> database directory (for any reason, including non-existent directory) >>> >>>> >>>> That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was >>>> somehow damaged? Although I doubt that, in that case Apache would >>>> not be >>>> able to serve https even. >>> >>> +1 >>> >>>> >>>>> On one of the hosts, I do notice that when i do >>>>> >>>>> ipa host-show >>>>> >>>>> there is no certificate listed. >>>> >>>> If you are using FreeIPA 4.1+, this is expected: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4449 >>>> >>>> Martin >>>> >>> >>> -- >>> Petr Vobornik >> >> > > From christoph.kaminski at biotronik.com Fri May 29 09:56:37 2015 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Fri, 29 May 2015 11:56:37 +0200 Subject: [Freeipa-users] Antwort: Re: dirsrv keytab revoked In-Reply-To: <55681E15.7000603@redhat.com> References: <55681E15.7000603@redhat.com> Message-ID: Martin Kosek schrieb am 29.05.2015 10:06:45: > > Running ipa-getkeytab on this replica is tricky - as if replication > is down and > you do this, the old key is revoked and new one is generated - which is not > known for the other master as replication is not working and you get in a > strange situation. > > You can try to log to your active master, do ipa-getkeytab for the broken > replica, copy the keytab there, restart DS and then run re- > initialize to reload > all the data from active master. It may work. > > > Or it is better to destroy it and do a new install? > > That may be even faster for the making that particular replica up and running > again, if you do not want to dig too much in this issue. yep done it on other replica and it works, thx! MfG Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri May 29 10:23:06 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 May 2015 12:23:06 +0200 Subject: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE In-Reply-To: <55682ED7.4050607@stanford.edu> References: <55681D2F.6050900@redhat.com> <556824DF.7070308@redhat.com> <02351C6D-BB0C-4D9C-A6F5-F79B4C6C4E70@stanford.edu> <55682BEC.2070705@redhat.com> <55682ED7.4050607@stanford.edu> Message-ID: <55683E0A.3070305@redhat.com> On 05/29/2015 11:18 AM, David Lin wrote: > the other hosts do not have certificate set. What IPA version is it? host-find/show should use /etc/httpd/alias dir, as Martin wrote. Could you check if there is anything wrong with this directory, e.g. missing files, missing dir, wrong SELinux context. Do you have selinux error? My default installation has: ls -l -a -Z /etc/httpd/alias/ drwxr-xr-x. root root system_u:object_r:cert_t:s0 . drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .. -r--r--r--. root root unconfined_u:object_r:cert_t:s0 cacert.asc -rw-rw----. root apache unconfined_u:object_r:cert_t:s0 cert8.db -rw-r-----. root apache system_u:object_r:cert_t:s0 cert8.db.orig -rw-------. root root system_u:object_r:cert_t:s0 install.log -rw-rw----. root apache unconfined_u:object_r:cert_t:s0 key3.db -rw-r-----. root apache system_u:object_r:cert_t:s0 key3.db.orig lrwxrwxrwx. root root system_u:object_r:cert_t:s0 libnssckbi.so -> ../../..//usr/lib64/libnssckbi.so -rw-rw----. root apache unconfined_u:object_r:cert_t:s0 pwdfile.txt -rw-rw----. root apache unconfined_u:object_r:cert_t:s0 secmod.db -rw-r-----. root apache system_u:object_r:cert_t:s0 secmod.db.orig ls -l -a -Z /etc/httpd/ drwxr-xr-x. root root system_u:object_r:cert_t:s0 alias Other way could to check if the initialization really uses the /etc/httpd/alias dir. This could be done by inserting print dbdir into def load_certificate function in /usr/lib/python2.7/site-packages/ipalib/x509.py, line ~ 112 ouput will be in /var/log/httpd/error_log > > Thanks, > David > > > On 05/29/2015 02:05 AM, Petr Vobornik wrote: >> On 05/29/2015 10:45 AM, David Lin wrote: >>> ipa host-find produces this >>> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>> certificate/key database is in an old, unsupported format. >>> >>> and ipa host-show on only one of the hosts show >>> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>> certificate/key database is in an old, unsupported format. >>> >>> all the other hosts are fine. >> >> Does any other host have certificate set? I want to find out if it >> fails on a specific certificate and not on other(s) or if it fails for >> all hosts with certificate set. >> >> SEC_ERROR_LEGACY_DATABASE error suggests that it fails on >> initialization of NSS database which is not dependent on stored >> certificate. >> >>> >>> Thanks! >>> David >>> >>>> On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: >>>> >>>> On 05/29/2015 10:02 AM, Martin Kosek wrote: >>>>> On 05/29/2015 01:27 AM, David Lin wrote: >>>>>> Hi, >>>>>> When I try to add multiple hosts, on the web UI, when I go to the >>>>>> host >>>>>> tab, >>>> >>>> This means that Web UI calls `ipa host-find` and couple of `ipa >>>> host-show` commands. Could you try it in CLI find out which command >>>> fails? >>>> >>>> So other web ui tabs work? Does service tab work(services has some >>>> common logic with hosts)? >>>> >>>>> I get >>>>>> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>>>>> certificate/key database is in an old, unsupported format. >>>>>> >>>>>> What does this mean? >>>> >>>> NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the >>>> database directory (for any reason, including non-existent directory) >>>> >>>>> >>>>> That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was >>>>> somehow damaged? Although I doubt that, in that case Apache would >>>>> not be >>>>> able to serve https even. >>>> >>>> +1 >>>> >>>>> >>>>>> On one of the hosts, I do notice that when i do >>>>>> >>>>>> ipa host-show >>>>>> >>>>>> there is no certificate listed. >>>>> >>>>> If you are using FreeIPA 4.1+, this is expected: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4449 >>>>> >>>>> Martin >>>>> >>>> >>>> -- >>>> Petr Vobornik >>> >>> >> >> > > -- Petr Vobornik From sam at zy.io Fri May 29 11:59:10 2015 From: sam at zy.io (sam at zy.io) Date: Fri, 29 May 2015 11:59:10 +0000 Subject: [Freeipa-users] vSphere and freeIPA Message-ID: <892b1cc5e31af711e60d22844fecb9cc@webmail.zy.io> Afternoon, I'm currently attempting to set up an existing vsphere environment to use freeipa 4.1.0 for authentication, following this guide: http://www.freeipa.org/page/HowTo/vsphere5_integration I've followed it all through, and for the purposes for testing, I've created a user called sam that's a member of a group called samtest: [root at ldap1 ~]# ldapsearch -x -D "uid=ldapauth,cn=users,cn=accounts,dc=example,dc=hostname,dc=co,dc=uk" -w passwordgoeshere -b "cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk" cn=samtest # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=samtest # requesting: ALL # # samtest, groups, compat, example.hostname.co.uk dn: cn=samtest,cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk objectClass: groupOfUniqueNames objectClass: top uniqueMember: uid=sam,cn=users,cn=compat,dc=example,dc=hostname,dc=co,dc= uk cn: samtest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 With only sam in the samtest group, the uniqueMember attribute that vsphere seems to depend on displays fine, and you can log into vsphere as the sam user if samtest has been given the correct permissions. The issue arises when a second user (chris) is added to the samtest group. [root at ldap1 ~]# ldapsearch -x -D "uid=ldapauth,cn=users,cn=accounts,dc=example,dc=hostname,dc=co,dc=uk" -w passwordgoeshere -b "cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk" cn=samtest # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=samtest # requesting: ALL # # samtest, groups, compat, example.hostname.co.uk dn: cn=samtest,cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk objectClass: groupOfUniqueNames objectClass: top cn: samtest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This causes the uniqueMember attribute to not display for either sam or chris, and neither user can access vsphere. However if sam is removed from samtest, then uniqueMember is once again shown: [root at ldap1 ~]# ldapsearch -x -D "uid=ldapauth,cn=users,cn=accounts,dc=example,dc=hostname,dc=co,dc=uk" -w passwordgoeshere -b "cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk" cn=samtest # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=samtest # requesting: ALL # # samtest, groups, compat, example.hostname.co.uk dn: cn=samtest,cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk objectClass: groupOfUniqueNames objectClass: top uniqueMember: uid=chris,cn=users,cn=compat,dc=example,dc=hostname,dc=co,d c=uk cn: samtest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 If anyone could shed any light on this behaviour, or point out any flaws in my logic/understanding, it would be greatly appreciated. Kind regards, Sam From janellenicole80 at gmail.com Fri May 29 12:59:47 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 29 May 2015 05:59:47 -0700 Subject: [Freeipa-users] Antwort: Re: Haunted servers? In-Reply-To: <55681828.2060208@redhat.com> References: <5561A40D.4010100@gmail.com> <5563A026.8060809@gmail.com> <556416F5.3030107@redhat.com> <55647D62.4090800@redhat.com> <55648990.2050001@gmail.com> <619939afd15e45618ca61cfd45346878@sib-ums03.Megafon.ru> <5566C287.7070708@redhat.com> <0458e2cfab8c41d5b415908b3705f751@sib-ums03.Megafon.ru> <5566C887.4050206@redhat.com> <2edca1d40b1942e99a98e075a50659af@sib-ums03.Megafon.ru> <5566F9A6.2080205@redhat.com> <952adf58d9014ddeab0c19fa79448000@sib-ums03.Megafon.ru> <55681828.2060208@redhat.com> Message-ID: <80CFEF5B-4848-41FD-928E-45499422B84A@gmail.com> > > On May 29, 2015, at 00:41, thierry bordaz wrote: > >> On 05/29/2015 08:16 AM, Christoph Kaminski wrote: >> freeipa-users-bounces at redhat.com schrieb am 28.05.2015 13:23:26: >> >> > Von: Alexander Frolushkin >> > An: "'thierry bordaz'" >> > Kopie: "freeipa-users at redhat.com" >> > Datum: 28.05.2015 13:24 >> > Betreff: Re: [Freeipa-users] Haunted servers? >> > Gesendet von: freeipa-users-bounces at redhat.com >> > >> > Unfortunately, after a couple of minutes, on two of three servers >> > error comes back in little changed form: >> > # ipa-replica-manage list-ruv >> > unable to decode: {replica 16} >> > .... >> > >> > Before cleanruv it looked like: >> > # ipa-replica-manage list-ruv >> > unable to decode: {replica 16} 548a8126000000100000 548a8126000000100000 >> > .... >> > >> > And one server seems to be fixed completely. >> > >> > WBR, >> > Alexander Frolushkin >> > >> > >> >> we had the same problem (and some more) and yesterday we have successfully cleaned the gohst rid's >> >> our fix: > > Hi Christoph, > > THanks for sharing this procedure. This bug is difficult to workaround and that is a good idea to write it down. > >> >> 1. stop all cleanallruv Tasks, if it works with ipa-replica-manage abort-clean-ruv. It hasnt worked here. We have done it manually on ALL replicas with: >> a) replica stop >> b) delete all nsds5ReplicaClean from /etc/dirsrv/slapd-HSO/dse.ldif >> c) replica start > Yes the ability to abort clean ruv hits the same retry issue that cleanallruv. It has been addressed with https://fedorahosted.org/389/ticket/48154 >> 2. prepare on EACH ipa a cleanruv ldif file with ALL ghost rids inside (really ALL from all ipa replicas, we has had some rids only on some replicas...) >> Example: >> >> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config >> changetype: modify >> replace: nsds5task >> nsds5task:CLEANRUV11 >> >> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config >> changetype: modify >> replace: nsds5task >> nsds5task:CLEANRUV22 >> >> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config >> changetype: modify >> replace: nsds5task >> nsds5task:CLEANRUV37 >> ... > > It should work but I would prefer to do it in an other order. > We need to clean a specific RID, on all replica, at the same time. We do not need to clean all RIDs at the same time. > Having several CLEANRUV in parallel for differents RID should work but I do not know how much it has been tested that way. > > So I would recommend to clean, in parallel on all replicas, RID 11. Then when it is completed, RID 22. Then RID 37. > >> >> 3. do a "ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -W -x -f $your-cleanruv-file.ldif" on all replicas AT THE SAME TIME :) we used terminator for it (https://launchpad.net/terminator). You can open multiple shell windows inside one window and send to all at the same time the same commands... > > same remark I would split your-cleanruv-file.ldif into three files cleanruv-11-file.ldif,... >> >> 4. we have done a re-initialize of each IPA from our first master > > Do you mean a total init ? I do not see a real need for that. > If you are ready to reinit all replicas, there is a very simple way to get rid of all these ghost RIDs. > Select the "good" master that is having all the updates > do a ldif export without the replication data > do a ldif import of exported file > do online reinit of the full topology, cascading from the "good" master down to the "consumers" > Most of the time we try to avoid asking a full reinit of the topology because DB are large. >> >> 5. restart of all replicas >> >> we are not sure about the point 3 and 4. Maybe they are not necessary, but we have done it. >> >> If something fails look at defect LDAP entries in whole ldap, we have had some entries with 'nsunique-$HASH' after the 'normal' name. We have deleted them. > do you mean entries with 'nsuniqueid' attribute in the RDN. This could be create during replication conflicts when updates are received in parallele on different replicas. > > > thanks > thierry >> >> MfG >> Christoph Kaminski > > -- > 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 Looks like I'll be giving this a try. So glad someone else is seeing exactly the same issues. Hopefully soon we can find the cause. ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri May 29 13:12:22 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 May 2015 09:12:22 -0400 Subject: [Freeipa-users] dirsrv keytab revoked In-Reply-To: <55681E15.7000603@redhat.com> References: <55681E15.7000603@redhat.com> Message-ID: <1432905142.19096.215.camel@willson.usersys.redhat.com> On Fri, 2015-05-29 at 10:06 +0200, Martin Kosek wrote: > On 05/29/2015 07:48 AM, Christoph Kaminski wrote: > > Hi > > > > I have had a defect entries in ldap for a replica and deleted them. But now the > > dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The > > replica starts but it cant connect other replicas (but other replicas can > > connect to it). > > > > I have tried: > > kinit -k -t /etc/dirsrv/ds.keytab ldap/ipa-1.mgmt.testsystem-homemonitoring.int > > > > and got: > > kinit: Clients credentials have been revoked while getting initial credentials > > > > It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab > > (on this replica) doesnt work. > > Running ipa-getkeytab on this replica is tricky - as if replication is down and > you do this, the old key is revoked and new one is generated - which is not > known for the other master as replication is not working and you get in a > strange situation. > > You can try to log to your active master, do ipa-getkeytab for the broken > replica, copy the keytab there, restart DS and then run re-initialize to reload > all the data from active master. It may work. No need to login and copy stuff, just point ipa-getkeytab at the other master with the -s switch. Once you've done that, restart the replica, however there are chances it will then try to get a TGT to replicate against the local KDC and it will fail because the local KDC has the old key. One way to help this is to temporarily change krb5.conf to explicitly point to a "good" replica so that KDC operations will be handled by that other replica, restart all IPA components and make sure a round of replication happens. Then restore the krb5.conf file and restart all. > > Or it is better to destroy it and do a new install? > > That may be even faster for the making that particular replica up and running > again, if you do not want to dig too much in this issue. If the play above doesn't help, it will be simpler to reinstall the replica indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York From christopher.lamb at ch.ibm.com Fri May 29 15:40:43 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Fri, 29 May 2015 17:40:43 +0200 Subject: [Freeipa-users] ssh problem with migrated FreeIPA client on EL7.1 Message-ID: Hi All Some weeks ago I setup a new FreeIPA 4.1.0 on an OEL 7.1 server to replace the existing FreeIPA 3.0.0 running on OEL 6.5, and successfully migrated across the users. We have 50 odd Servers that are FreeIPA clients. Today I started migrating these one-by-one from the old FreeIPA 3.x server to the new FreeIPA 4 server by doing an ipa-client-install --uninstall from the old, and ipa-client-install to register with the new 4.1.0 server. Most of the FreeIPA clients are running OEL 6.5, and for these the migration process above worked perfectly. After migrating the server, I could ssh in with my FreeIPA user. Then I migrated an OEL 7.1 server. The migration itself seemed to work, and getent passwd was successful for my FreeIPA user. However when I try and ssh in, my FreeIPA user / password is not accepted. Before the migration I could ssh into the problem server (though evidently it was using my FreeIPA user from the old FreeIPA server). I can ssh in with a local (non ldap) user, so ssh is running and working. >From user root I can successfully su to my FreeIPA user. Further investigation showed that version of ipa-client installed was 3.3.3, so I yum updated this to 4.1.0. However I still cannot ssh into the OEL 7.1 box with my FreeIPA user. The same user continues to work for the 6.5 boxes. A colleague tried to ssh in with his FreeIPA user, and was also rejected, so the problem is not my user, but is probably for all FreeIPA users. A failed ssh login attempt causes the following error in /var/log/messages [sssd[krb5_child[5393]]]: Decrypt integrity check failed Any ideas? Cheers Chris From abokovoy at redhat.com Fri May 29 16:04:17 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 May 2015 19:04:17 +0300 Subject: [Freeipa-users] ssh problem with migrated FreeIPA client on EL7.1 In-Reply-To: References: Message-ID: <20150529160417.GL19176@redhat.com> On Fri, 29 May 2015, Christopher Lamb wrote: > >Hi All > >Some weeks ago I setup a new FreeIPA 4.1.0 on an OEL 7.1 server to replace >the existing FreeIPA 3.0.0 running on OEL 6.5, and successfully migrated >across the users. > >We have 50 odd Servers that are FreeIPA clients. Today I started migrating >these one-by-one from the old FreeIPA 3.x server to the new FreeIPA 4 >server by doing an ipa-client-install --uninstall from the old, and >ipa-client-install to register with the new 4.1.0 server. > >Most of the FreeIPA clients are running OEL 6.5, and for these the >migration process above worked perfectly. After migrating the server, I >could ssh in with my FreeIPA user. > >Then I migrated an OEL 7.1 server. The migration itself seemed to work, and >getent passwd was successful for my FreeIPA user. However when I try and >ssh in, my FreeIPA user / password is not accepted. > >Before the migration I could ssh into the problem server (though evidently >it was using my FreeIPA user from the old FreeIPA server). > >I can ssh in with a local (non ldap) user, so ssh is running and working. > >>From user root I can successfully su to my FreeIPA user. > >Further investigation showed that version of ipa-client installed was >3.3.3, so I yum updated this to 4.1.0. > >However I still cannot ssh into the OEL 7.1 box with my FreeIPA user. The >same user continues to work for the 6.5 boxes. > >A colleague tried to ssh in with his FreeIPA user, and was also rejected, >so the problem is not my user, but is probably for all FreeIPA users. > >A failed ssh login attempt causes the following error in /var/log/messages > >[sssd[krb5_child[5393]]]: Decrypt integrity check failed It means /etc/krb5.keytab contains keys from older system and SSSD picks them up. Can you show output of 'klist -kKet'? -- / Alexander Bokovoy From bahanw042014 at gmail.com Fri May 29 16:25:24 2015 From: bahanw042014 at gmail.com (bahan w) Date: Fri, 29 May 2015 18:25:24 +0200 Subject: [Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4 Message-ID: Hello everyone. I send you this mail because I have a problem with the installation of FreeIPA Server 3.0 on a VM running on RHEL 6.4. First, when I performed the yum install ipa-server, I got an error but the installation finished finally with a complete. Here it is : ############################ =========================================================================================================================================================================================================== Install 4 Package(s) Total download size: 1.4 M Installed size: 4.6 M Is this ok [y/N]: y Downloading Packages: (1/4): ipa-admintools-3.0.0-42.el6.x86_64.rpm | 67 kB 00:00 (2/4): ipa-client-3.0.0-42.el6.x86_64.rpm | 145 kB 00:00 (3/4): ipa-server-3.0.0-42.el6.x86_64.rpm | 1.1 MB 00:00 (4/4): ipa-server-selinux-3.0.0-42.el6.x86_64.rpm | 66 kB 00:00 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 7.3 MB/s | 1.4 MB 00:00 Total 7.3 MB/s | 1.4 MB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : ipa-client-3.0.0-42.el6.x86_64 1/4 Installing : ipa-admintools-3.0.0-42.el6.x86_64 2/4 Installing : ipa-server-3.0.0-42.el6.x86_64 3/4 Installing : ipa-server-selinux-3.0.0-42.el6.x86_64 4/4 libsepol.print_missing_requirements: ipa_dogtag's global requirements were not met: type/attribute pki_ca_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! Verifying : ipa-server-3.0.0-42.el6.x86_64 1/4 Verifying : ipa-server-selinux-3.0.0-42.el6.x86_64 2/4 Verifying : ipa-client-3.0.0-42.el6.x86_64 3/4 Verifying : ipa-admintools-3.0.0-42.el6.x86_64 Installed: ipa-server.x86_64 0:3.0.0-42.el6 Dependency Installed: ipa-admintools.x86_64 0:3.0.0-42.el6 ipa-client.x86_64 0:3.0.0-42.el6 ipa-server-selinux.x86_64 0:3.0.0-42.el6 Complete! ############################ Are these two errors blocking in order to use FreeIPA Server ? Or is it fine ? libsepol.print_missing_requirements: ipa_dogtag's global requirements were not met: type/attribute pki_ca_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! Furthermore, when I try a ipa-server-install, I got also an error message during step ############################ Configuring directory server (dirsrv): Estimated time 1 minute [1/38]: creating directory server user [2/38]: creating directory server instance ipa : CRITICAL failed to create ds instance Command '/usr/sbin/ setup-ds.pl --silent --logfile - -f /tmp/tmpPamNs8' returned non-zero exit status 1 ############################ And when I checked in the log, here is what I see Here is the message I see : ############################ 2015-05-29T15:56:49Z DEBUG calling setup-ds.pl 4944 2015-05-29T15:56:49Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpkCAtzh 4945 2015-05-29T15:56:49Z DEBUG stdout=[15/05/29:17:56:49] - [Setup] Info Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 32256. Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission denied 4946 4947 Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 32256. Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission denied 4948 4949 [15/05/29:17:56:49] - [Setup] Fatal Error: Could not create directory server instance 'MyRealm'. 4950 Error: Could not create directory server instance 'MyRealm'. 4951 [15/05/29:17:56:49] - [Setup] Fatal Exiting . . . ############################ When I check the perm on the folders, everything is fine : ############################ ls -ld /var/lib/dirsrv/ drwxrwxr-x 5 root dirsrv 4096 May 29 18:19 /var/lib/dirsrv/ ls -l /var/lib/dirsrv/ drwxrwx--- 2 dirsrv dirsrv 4096 May 29 18:19 scripts-MYREALM drwxrwx--- 5 dirsrv dirsrv 4096 May 29 18:19 slapd-MYREALM drwxrwx--- 5 pkisrv dirsrv 4096 May 29 18:18 slapd-PKI-IPA ls -l /var/lib/dirsrv/scripts-MYREALM/ -r-xr-x--- 1 dirsrv dirsrv 1212 May 29 18:19 bak2db -r-xr-x--- 1 dirsrv dirsrv 5661 May 29 18:19 bak2db.pl -r-xr-x--- 1 dirsrv dirsrv 6018 May 29 18:19 cleanallruv.pl -r-xr-x--- 1 dirsrv dirsrv 1134 May 29 18:19 db2bak -r-xr-x--- 1 dirsrv dirsrv 5397 May 29 18:19 db2bak.pl -r-xr-x--- 1 dirsrv dirsrv 759 May 29 18:19 db2index -r-xr-x--- 1 dirsrv dirsrv 8129 May 29 18:19 db2index.pl -r-xr-x--- 1 dirsrv dirsrv 2053 May 29 18:19 db2ldif -r-xr-x--- 1 dirsrv dirsrv 10093 May 29 18:19 db2ldif.pl -r-xr-x--- 1 dirsrv dirsrv 932 May 29 18:19 dbverify -r-xr-x--- 1 dirsrv dirsrv 499 May 29 18:19 dn2rdn -r-xr-x--- 1 dirsrv dirsrv 5560 May 29 18:19 fixup-linkedattrs.pl -r-xr-x--- 1 dirsrv dirsrv 5896 May 29 18:19 fixup-memberof.pl -r-xr-x--- 1 dirsrv dirsrv 729 May 29 18:19 ldif2db -r-xr-x--- 1 dirsrv dirsrv 8826 May 29 18:19 ldif2db.pl -r-xr-x--- 1 dirsrv dirsrv 412 May 29 18:19 ldif2ldap -r-xr-x--- 1 dirsrv dirsrv 426 May 29 18:19 monitor -r-xr-x--- 1 dirsrv dirsrv 21524 May 29 18:19 ns-accountstatus.pl -r-xr-x--- 1 dirsrv dirsrv 21524 May 29 18:19 ns-activate.pl -r-xr-x--- 1 dirsrv dirsrv 21524 May 29 18:19 ns-inactivate.pl -r-xr-x--- 1 dirsrv dirsrv 10237 May 29 18:19 ns-newpwpolicy.pl -r-xr-x--- 1 dirsrv dirsrv 318 May 29 18:19 restart-slapd -r-xr-x--- 1 dirsrv dirsrv 650 May 29 18:19 restoreconfig -r-xr-x--- 1 dirsrv dirsrv 654 May 29 18:19 saveconfig -r-xr-x--- 1 dirsrv dirsrv 5405 May 29 18:19 schema-reload.pl -r-xr-x--- 1 dirsrv dirsrv 269 May 29 18:19 start-slapd -r-xr-x--- 1 dirsrv dirsrv 248 May 29 18:19 stop-slapd -r-xr-x--- 1 dirsrv dirsrv 489 May 29 18:19 suffix2instance -r-xr-x--- 1 dirsrv dirsrv 5905 May 29 18:19 syntax-validate.pl -r-xr-x--- 1 dirsrv dirsrv 1497 May 29 18:19 upgradednformat -r-xr-x--- 1 dirsrv dirsrv 6143 May 29 18:19 usn-tombstone-cleanup.pl -r-xr-x--- 1 dirsrv dirsrv 7588 May 29 18:19 verify-db.pl -r-xr-x--- 1 dirsrv dirsrv 588 May 29 18:19 vlvindex ############################### I don't really understand from where the problem is coming. Any help please ? Best regards. Bahan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri May 29 16:29:25 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 May 2015 18:29:25 +0200 Subject: [Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4 In-Reply-To: References: Message-ID: <20150529162925.GF788@hendrix.arn.redhat.com> On Fri, May 29, 2015 at 06:25:24PM +0200, bahan w wrote: > Hello everyone. > > I send you this mail because I have a problem with the installation of > FreeIPA Server 3.0 on a VM running on RHEL 6.4. This is really old, please upgrade if you can, ideally to RHEL-7. From bahanw042014 at gmail.com Fri May 29 16:56:10 2015 From: bahanw042014 at gmail.com (bahan w) Date: Fri, 29 May 2015 18:56:10 +0200 Subject: [Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4 In-Reply-To: References: Message-ID: Hm. @Jakub : I cannot upgrade, because I am not the hosting provider managing this VM unfortunately. I need to make it work with RHEL 6.4. @Sam : Selinux is deactivated : cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX=disabled # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted Best regards. Bahan On Fri, May 29, 2015 at 6:39 PM, wrote: > Seem to be a fair few things implicating selinux there. > > Have you got it set to enforcing mode? If so, have you set any particular > policy that may be angered by this? > > Sam > > > May 29 2015 5:37 PM, "bahan w" <%22bahan%20w%22%20%3Cbahanw042014 at gmail.com%3E>> wrote: > > Hello everyone. > > I send you this mail because I have a problem with the installation of > FreeIPA Server 3.0 on a VM running on RHEL 6.4. > > First, when I performed the yum install ipa-server, I got an error but the > installation finished finally with a complete. > Here it is : > > ############################ > > =========================================================================================================================================================================================================== > Install 4 Package(s) > > Total download size: 1.4 M > Installed size: 4.6 M > Is this ok [y/N]: y > Downloading Packages: > (1/4): ipa-admintools-3.0.0-42.el6.x86_64.rpm | 67 kB 00:00 > (2/4): ipa-client-3.0.0-42.el6.x86_64.rpm | 145 kB 00:00 > (3/4): ipa-server-3.0.0-42.el6.x86_64.rpm | 1.1 MB 00:00 > (4/4): ipa-server-selinux-3.0.0-42.el6.x86_64.rpm | 66 kB 00:00 > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Total 7.3 MB/s | 1.4 MB 00:00 > Total 7.3 MB/s | 1.4 MB 00:00 > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Installing : ipa-client-3.0.0-42.el6.x86_64 1/4 > Installing : ipa-admintools-3.0.0-42.el6.x86_64 2/4 > Installing : ipa-server-3.0.0-42.el6.x86_64 3/4 > Installing : ipa-server-selinux-3.0.0-42.el6.x86_64 4/4 > libsepol.print_missing_requirements: ipa_dogtag's global requirements were > not met: type/attribute pki_ca_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > Verifying : ipa-server-3.0.0-42.el6.x86_64 1/4 > Verifying : ipa-server-selinux-3.0.0-42.el6.x86_64 2/4 > Verifying : ipa-client-3.0.0-42.el6.x86_64 3/4 > Verifying : ipa-admintools-3.0.0-42.el6.x86_64 > > Installed: > ipa-server.x86_64 0:3.0.0-42.el6 > > Dependency Installed: > ipa-admintools.x86_64 0:3.0.0-42.el6 ipa-client.x86_64 0:3.0.0-42.el6 > ipa-server-selinux.x86_64 0:3.0.0-42.el6 > > Complete! > ############################ > Are these two errors blocking in order to use FreeIPA Server ? Or is it > fine ? > libsepol.print_missing_requirements: ipa_dogtag's global requirements were > not met: type/attribute pki_ca_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > > Furthermore, when I try a ipa-server-install, I got also an error message > during step > > ############################ > Configuring directory server (dirsrv): Estimated time 1 minute > [1/38]: creating directory server user > [2/38]: creating directory server instance > ipa : CRITICAL failed to create ds instance Command '/usr/sbin/ > setup-ds.pl --silent --logfile - -f /tmp/tmpPamNs8' returned non-zero > exit status 1 > ############################ > > And when I checked in the log, here is what I see > > Here is the message I see : > ############################ > 2015-05-29T15:56:49Z DEBUG calling setup-ds.pl > 4944 2015-05-29T15:56:49Z DEBUG args=/usr/sbin/setup-ds.pl --silent > --logfile - -f /tmp/tmpkCAtzh > 4945 2015-05-29T15:56:49Z DEBUG stdout=[15/05/29:17:56:49] - [Setup] Info > Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 32256. > Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission > denied > 4946 > 4947 Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: > 32256. Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission > denied > 4948 > 4949 [15/05/29:17:56:49] - [Setup] Fatal Error: Could not create directory > server instance 'MyRealm'. > 4950 Error: Could not create directory server instance 'MyRealm'. > 4951 [15/05/29:17:56:49] - [Setup] Fatal Exiting . . . > ############################ > > When I check the perm on the folders, everything is fine : > > ############################ > ls -ld /var/lib/dirsrv/ > drwxrwxr-x 5 root dirsrv 4096 May 29 18:19 /var/lib/dirsrv/ > > ls -l /var/lib/dirsrv/ > drwxrwx--- 2 dirsrv dirsrv 4096 May 29 18:19 scripts-MYREALM > drwxrwx--- 5 dirsrv dirsrv 4096 May 29 18:19 slapd-MYREALM > drwxrwx--- 5 pkisrv dirsrv 4096 May 29 18:18 slapd-PKI-IPA > > ls -l /var/lib/dirsrv/scripts-MYREALM/ > -r-xr-x--- 1 dirsrv dirsrv 1212 May 29 18:19 bak2db > -r-xr-x--- 1 dirsrv dirsrv 5661 May 29 18:19 bak2db.pl > -r-xr-x--- 1 dirsrv dirsrv 6018 May 29 18:19 cleanallruv.pl > -r-xr-x--- 1 dirsrv dirsrv 1134 May 29 18:19 db2bak > -r-xr-x--- 1 dirsrv dirsrv 5397 May 29 18:19 db2bak.pl > -r-xr-x--- 1 dirsrv dirsrv 759 May 29 18:19 db2index > -r-xr-x--- 1 dirsrv dirsrv 8129 May 29 18:19 db2index.pl > -r-xr-x--- 1 dirsrv dirsrv 2053 May 29 18:19 db2ldif > -r-xr-x--- 1 dirsrv dirsrv 10093 May 29 18:19 db2ldif.pl > -r-xr-x--- 1 dirsrv dirsrv 932 May 29 18:19 dbverify > -r-xr-x--- 1 dirsrv dirsrv 499 May 29 18:19 dn2rdn > -r-xr-x--- 1 dirsrv dirsrv 5560 May 29 18:19 fixup-linkedattrs.pl > -r-xr-x--- 1 dirsrv dirsrv 5896 May 29 18:19 fixup-memberof.pl > -r-xr-x--- 1 dirsrv dirsrv 729 May 29 18:19 ldif2db > -r-xr-x--- 1 dirsrv dirsrv 8826 May 29 18:19 ldif2db.pl > -r-xr-x--- 1 dirsrv dirsrv 412 May 29 18:19 ldif2ldap > -r-xr-x--- 1 dirsrv dirsrv 426 May 29 18:19 monitor > -r-xr-x--- 1 dirsrv dirsrv 21524 May 29 18:19 ns-accountstatus.pl > -r-xr-x--- 1 dirsrv dirsrv 21524 May 29 18:19 ns-activate.pl > -r-xr-x--- 1 dirsrv dirsrv 21524 May 29 18:19 ns-inactivate.pl > -r-xr-x--- 1 dirsrv dirsrv 10237 May 29 18:19 ns-newpwpolicy.pl > -r-xr-x--- 1 dirsrv dirsrv 318 May 29 18:19 restart-slapd > -r-xr-x--- 1 dirsrv dirsrv 650 May 29 18:19 restoreconfig > -r-xr-x--- 1 dirsrv dirsrv 654 May 29 18:19 saveconfig > -r-xr-x--- 1 dirsrv dirsrv 5405 May 29 18:19 schema-reload.pl > -r-xr-x--- 1 dirsrv dirsrv 269 May 29 18:19 start-slapd > -r-xr-x--- 1 dirsrv dirsrv 248 May 29 18:19 stop-slapd > -r-xr-x--- 1 dirsrv dirsrv 489 May 29 18:19 suffix2instance > -r-xr-x--- 1 dirsrv dirsrv 5905 May 29 18:19 syntax-validate.pl > -r-xr-x--- 1 dirsrv dirsrv 1497 May 29 18:19 upgradednformat > -r-xr-x--- 1 dirsrv dirsrv 6143 May 29 18:19 usn-tombstone-cleanup.pl > -r-xr-x--- 1 dirsrv dirsrv 7588 May 29 18:19 verify-db.pl > -r-xr-x--- 1 dirsrv dirsrv 588 May 29 18:19 vlvindex > ############################### > > I don't really understand from where the problem is coming. > Any help please ? > > Best regards. > > Bahan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.sailer at alumni.ethz.ch Fri May 29 16:57:33 2015 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Fri, 29 May 2015 18:57:33 +0200 Subject: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches Message-ID: <55689A7D.30707@alumni.ethz.ch> Hello everyone. I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). - ipa-ldap-updater stumbles over two problems: - Pre schema upgrade failed - when trying to modify cn=encryption,cn=config, it stumbles over allowWeakCipher not allowed Does anyone know how to fix this? Is the pre schema upgrade failure spurious? what bits am I missing about the allowWeakCipher issue? Thomas 2015-05-28T13:04:55Z DEBUG [4/10]: starting directory server 2015-05-28T13:04:55Z DEBUG Starting external process 2015-05-28T13:04:55Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at XXXXX-COM.service' 2015-05-28T13:04:55Z DEBUG Process finished, return code=0 2015-05-28T13:04:55Z DEBUG stdout= 2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:04:55Z DEBUG duration: 0 seconds 2015-05-28T13:04:55Z DEBUG [5/10]: preparing server upgrade 2015-05-28T13:05:36Z ERROR Pre schema upgrade failed with [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ self.create_connection() File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG duration: 40 seconds 2015-05-28T13:05:36Z DEBUG [6/10]: updating schema 2015-05-28T13:05:46Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 112, in update_schema fqdn=installutils.get_fqdn()) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [error] error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [cleanup]: stopping directory server 2015-05-28T13:05:46Z DEBUG Starting external process 2015-05-28T13:05:46Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv at XXXXX-COM.service' 2015-05-28T13:05:46Z DEBUG Process finished, return code=0 2015-05-28T13:05:46Z DEBUG stdout= 2015-05-28T13:05:46Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG [cleanup]: restoring configuration 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 144, in run upgrade.create_instance() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 93, in create_instance show_service_name=False) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 112, in update_schema fqdn=installutils.get_fqdn()) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1183, in wait_for_open_socket raise e 2015-05-28T13:05:46Z DEBUG The ipa-ldap-updater command failed, exception: error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z ERROR [Errno 2] No such file or directory 2015-05-28T13:05:47Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} 2015-05-28T13:05:47Z DEBUG IPA version 4.1.4-2.fc22 2015-05-28T13:05:47Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2015-05-28T13:05:47Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' 2015-05-28T13:05:47Z DEBUG Starting external process 2015-05-28T13:05:47Z DEBUG args='klist' '-V' 2015-05-28T13:05:47Z DEBUG Process finished, return code=0 2015-05-28T13:05:47Z DEBUG stdout=Kerberos 5 version 1.13.1 2015-05-28T13:05:47Z DEBUG stderr= 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' 2015-05-28T13:05:47Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' 2015-05-28T17:11:53Z INFO Updating existing entry: cn=encryption,cn=config 2015-05-28T17:11:53Z DEBUG --------------------------------------------- 2015-05-28T17:11:53Z DEBUG Initial value 2015-05-28T17:11:53Z DEBUG dn: cn=encryption,cn=config 2015-05-28T17:11:53Z DEBUG nsSSL3: 2015-05-28T17:11:53Z DEBUG off 2015-05-28T17:11:53Z DEBUG nsSSL2: 2015-05-28T17:11:53Z DEBUG off 2015-05-28T17:11:53Z DEBUG cn: 2015-05-28T17:11:53Z DEBUG encryption 2015-05-28T17:11:53Z DEBUG objectClass: 2015-05-28T17:11:53Z DEBUG top 2015-05-28T17:11:53Z DEBUG nsEncryptionConfig 2015-05-28T17:11:53Z DEBUG sslVersionMax: 2015-05-28T17:11:53Z DEBUG TLS1.2 2015-05-28T17:11:53Z DEBUG nsSSLSessionTimeout: 2015-05-28T17:11:53Z DEBUG 0 2015-05-28T17:11:53Z DEBUG sslVersionMin: 2015-05-28T17:11:53Z DEBUG TLS1.0 2015-05-28T17:11:53Z DEBUG nsSSLSupportedCiphers: 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5::RC2::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_NULL_SHA256::NULL::SHA256::0 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_NULL_MD5::NULL::MD5::0 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT1024_WITH_RC4_56_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_CK_DES_192_EDE3_CBC_WITH_MD5::3DES::MD5::192 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_CK_RC2_128_CBC_WITH_MD5::RC2::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_CK_RC4_128_WITH_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG SSL_CK_DES_64_CBC_WITH_MD5::DES::MD5::64 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT_WITH_RC4_40_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256 2015-05-28T17:11:53Z DEBUG SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5::RC2::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_SEED_CBC_SHA::SEED::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_RC4_128_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG SSL_CK_RC4_128_EXPORT40_WITH_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG nsSSLClientAuth: 2015-05-28T17:11:53Z DEBUG allowed 2015-05-28T17:11:53Z DEBUG nssslenabledciphers: 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_RC4_128_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG nsTLS1: 2015-05-28T17:11:53Z DEBUG on 2015-05-28T17:11:53Z DEBUG nsSSL3Ciphers: 2015-05-28T17:11:53Z DEBUG -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha 2015-05-28T17:11:53Z DEBUG only: set nsSSL3Ciphers to '+all', current value ['-rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha'] 2015-05-28T17:11:53Z DEBUG only: updated value ['+all'] 2015-05-28T17:11:53Z DEBUG addifnew: 'off' to allowWeakCipher, current value [] 2015-05-28T17:11:53Z DEBUG addifnew: set allowWeakCipher to ['off'] 2015-05-28T17:11:53Z DEBUG --------------------------------------------- 2015-05-28T17:11:53Z DEBUG Final value after applying updates 2015-05-28T17:11:53Z DEBUG dn: cn=encryption,cn=config 2015-05-28T17:11:53Z DEBUG nsSSL3: 2015-05-28T17:11:53Z DEBUG off 2015-05-28T17:11:53Z DEBUG nsSSL2: 2015-05-28T17:11:53Z DEBUG off 2015-05-28T17:11:53Z DEBUG cn: 2015-05-28T17:11:53Z DEBUG encryption 2015-05-28T17:11:53Z DEBUG objectClass: 2015-05-28T17:11:53Z DEBUG top 2015-05-28T17:11:53Z DEBUG nsEncryptionConfig 2015-05-28T17:11:53Z DEBUG sslVersionMax: 2015-05-28T17:11:53Z DEBUG TLS1.2 2015-05-28T17:11:53Z DEBUG nsSSLSessionTimeout: 2015-05-28T17:11:53Z DEBUG 0 2015-05-28T17:11:53Z DEBUG sslVersionMin: 2015-05-28T17:11:53Z DEBUG TLS1.0 2015-05-28T17:11:53Z DEBUG nsSSLSupportedCiphers: 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5::RC2::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG TLS_ECDH_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_NULL_SHA256::NULL::SHA256::0 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_NULL_MD5::NULL::MD5::0 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT1024_WITH_RC4_56_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_CK_DES_192_EDE3_CBC_WITH_MD5::3DES::MD5::192 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_CK_RC2_128_CBC_WITH_MD5::RC2::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_CK_RC4_128_WITH_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_ECDH_ECDSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG SSL_CK_DES_64_CBC_WITH_MD5::DES::MD5::64 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_EXPORT_WITH_RC4_40_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256 2015-05-28T17:11:53Z DEBUG SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5::RC2::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 2015-05-28T17:11:53Z DEBUG TLS_DHE_DSS_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_SEED_CBC_SHA::SEED::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_RC4_128_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_ECDSA_WITH_NULL_SHA::NULL::SHA1::0 2015-05-28T17:11:53Z DEBUG SSL_CK_RC4_128_EXPORT40_WITH_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG TLS_ECDHE_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 2015-05-28T17:11:53Z DEBUG nsSSLClientAuth: 2015-05-28T17:11:53Z DEBUG allowed 2015-05-28T17:11:53Z DEBUG nssslenabledciphers: 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 2015-05-28T17:11:53Z DEBUG TLS_RSA_WITH_RC4_128_MD5::RC4::MD5::128 2015-05-28T17:11:53Z DEBUG SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 2015-05-28T17:11:53Z DEBUG nsTLS1: 2015-05-28T17:11:53Z DEBUG on 2015-05-28T17:11:53Z DEBUG allowWeakCipher: 2015-05-28T17:11:53Z DEBUG off 2015-05-28T17:11:53Z DEBUG nsSSL3Ciphers: 2015-05-28T17:11:53Z DEBUG +all 2015-05-28T17:11:53Z DEBUG [(2, u'allowWeakCipher', ['off']), (0, u'nsSSL3Ciphers', ['+all']), (1, u'nsSSL3Ciphers', ['-rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha'])] 2015-05-28T17:11:53Z DEBUG Live 1, updated 1 2015-05-28T17:11:53Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 213, in run modified = ld.update(self.files, ordered=True) or modified File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 854, in update self._run_updates(all_updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 799, in _run_updates self._update_record(update) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 720, in _update_record self.conn.update_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1628, in update_entry self.conn.modify_s(entry.dn, modlist) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1191, in error_handler raise errors.ObjectclassViolation(info=info) 2015-05-28T17:11:53Z DEBUG The ipa-ldap-updater command failed, exception: ObjectclassViolation: attribute "allowWeakCipher" not allowed 2015-05-28T17:11:53Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: ObjectclassViolation: attribute "allowWeakCipher" not allowed 2015-05-29T12:46:04Z DEBUG Logging to /var/log/ipaupgrade.log From lslebodn at redhat.com Sat May 30 12:10:22 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 30 May 2015 14:10:22 +0200 Subject: [Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4 In-Reply-To: References: Message-ID: <20150530121021.GA11243@mail.corp.redhat.com> On (29/05/15 18:56), bahan w wrote: >Hm. > >@Jakub : >I cannot upgrade, because I am not the hosting provider managing this VM >unfortunately. >I need to make it work with RHEL 6.4. > >@Sam : >Selinux is deactivated : > >cat /etc/selinux/config ># This file controls the state of SELinux on the system. ># SELINUX=disabled ># enforcing - SELinux security policy is enforced. ># permissive - SELinux prints warnings instead of enforcing. ># disabled - SELinux is fully disabled. >SELINUX=disabled We do not test with disabled SELinux. Could you try with "permissive" ? LS From sam at zy.io Sat May 30 12:26:02 2015 From: sam at zy.io (Sam) Date: Sat, 30 May 2015 13:26:02 +0100 Subject: [Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4 In-Reply-To: <20150530121021.GA11243@mail.corp.redhat.com> Message-ID: <24b13f8e-c7a7-4fdb-a81c-e0ef33e0f4d9@email.android.com> @bahan Could you also send the output of getenforce as well, just to make sure that selinux is permissive and persisting beyond reboots. Cheers Sam On 30 May 2015 1:10 pm, Lukas Slebodnik wrote: > > On (29/05/15 18:56), bahan w wrote: > >Hm. > > > >@Jakub : > >I cannot upgrade, because I am not the hosting provider managing this VM > >unfortunately. > >I need to make it work with RHEL 6.4. > > > >@Sam : > >Selinux is deactivated : > > > >cat /etc/selinux/config > ># This file controls the state of SELinux on the system. > ># SELINUX=disabled > >#?????? enforcing - SELinux security policy is enforced. > >#?????? permissive - SELinux prints warnings instead of enforcing. > >#?????? disabled - SELinux is fully disabled. > >SELINUX=disabled > We do not test with disabled SELinux. > Could you try with "permissive" ? > > LS > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From christopher.lamb at ch.ibm.com Sat May 30 16:50:45 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Sat, 30 May 2015 18:50:45 +0200 Subject: [Freeipa-users] ssh problem with migrated FreeIPA client on EL7.1 --> Solved In-Reply-To: <20150529160417.GL19176@redhat.com> References: <20150529160417.GL19176@redhat.com> Message-ID: Hi All It gives me pleasure to report the problem is solved - a minute ago I was able to login via ssh with my FreeIPA user to the problem server, while sitting on my terrace with a glass of wine! Thanks to Alexander for his helpful advice - we had some mail exchange outside the user list as I did not wish to broadcast content of keys, config files etc. Regardless of what I did with commands like klist, kvno everything seemed "ok", but I still could not ssh in. Even a ipa-getkeytab did not help. Therefore I decided to opt for brute force and (partial) ignorance. I completely uninstalled the FreeIPA client, and then reinstalled, configured - ?t voil? I could ssh in! This leaves the enigma: what caused the problem? I suspect the following: The host is an EL 7.1, but the first FreeIPA client installed was version 3.3.3 (installed as set of standard packages that we bung on all our servers). This worked fine to authenticate against our "old" 3.x FreeIPA server, but did not work against the "new" 4.1 FreeIPA Server. When I realised I could not ssh in, one of the first things I did was to yum update the FreeIPA client from 3.3.3 to 4.1 - but that did not help. The solution was to yum remove the FreeIPA client, then yum install the 4.1 client. I have some more EL 7.1 servers with the FreeIPA 3.3.3 client installed, so it will be interesting to see it the problem can be reproduced. Keep up the good work, Chris From: Alexander Bokovoy To: Christopher Lamb/Switzerland/IBM at IBMCH Cc: freeipa-users at redhat.com Date: 29.05.2015 18:04 Subject: Re: [Freeipa-users] ssh problem with migrated FreeIPA client on EL7.1 On Fri, 29 May 2015, Christopher Lamb wrote: > >Hi All > >Some weeks ago I setup a new FreeIPA 4.1.0 on an OEL 7.1 server to replace >the existing FreeIPA 3.0.0 running on OEL 6.5, and successfully migrated >across the users. > >We have 50 odd Servers that are FreeIPA clients. Today I started migrating >these one-by-one from the old FreeIPA 3.x server to the new FreeIPA 4 >server by doing an ipa-client-install --uninstall from the old, and >ipa-client-install to register with the new 4.1.0 server. > >Most of the FreeIPA clients are running OEL 6.5, and for these the >migration process above worked perfectly. After migrating the server, I >could ssh in with my FreeIPA user. > >Then I migrated an OEL 7.1 server. The migration itself seemed to work, and >getent passwd was successful for my FreeIPA user. However when I try and >ssh in, my FreeIPA user / password is not accepted. > >Before the migration I could ssh into the problem server (though evidently >it was using my FreeIPA user from the old FreeIPA server). > >I can ssh in with a local (non ldap) user, so ssh is running and working. > >>From user root I can successfully su to my FreeIPA user. > >Further investigation showed that version of ipa-client installed was >3.3.3, so I yum updated this to 4.1.0. > >However I still cannot ssh into the OEL 7.1 box with my FreeIPA user. The >same user continues to work for the 6.5 boxes. > >A colleague tried to ssh in with his FreeIPA user, and was also rejected, >so the problem is not my user, but is probably for all FreeIPA users. > >A failed ssh login attempt causes the following error in /var/log/messages > >[sssd[krb5_child[5393]]]: Decrypt integrity check failed It means /etc/krb5.keytab contains keys from older system and SSSD picks them up. Can you show output of 'klist -kKet'? -- / Alexander Bokovoy From bob at jackland.demon.co.uk Sun May 31 10:21:45 2015 From: bob at jackland.demon.co.uk (Bob Hinton) Date: Sun, 31 May 2015 11:21:45 +0100 Subject: [Freeipa-users] problem with keytab for ipa user-add Message-ID: <556AE0B9.8010704@jackland.demon.co.uk> Hello, I've written a Ruby script to add IPA users from CSV files. This works fine when specifying a username and password. However, using a keytab produces an error (see below). This seems to happen whatever I put in the keytab file. Any suggestions ? The VM in question has had its database restored using ipa-restore a number of times, so I don't know if this is a factor. Thanks Bob -sh-4.2$ ./ipa-import-users -h Usage ipa-import-users [options] file1.csv ... -u, --user USER Kerberos principal that can add users -p, --password PASSWORD Password for the above -k, --keytab KEYTAB Login with the specified keytab instead of user and pass -v, --verbose enable verbose mode -d, --debug enable debug mode -c, --check check input files without applying them -sh-4.2$ ./ipa-import-users -vd -k ipa004.keytab example_users_file.csv Importing file example_users_file.csv... header line ["Username", " First Name", " Last Name", " Email Address", " Password"] Line 2 is ["auser", "Another", "User", "auser at test.com", "pass"] username auser already defined Line 3 is ["james23", "James", "Jones", "jamesjones at somewhere.com", "secrets2"] echo "secrets2" | ipa user-add james23 --first="James" --last="Jones" --email="jamesjones at somewhere.com" --password 2>&1 Problem with file example_users_file.csv ipa error on james23 - ipa: ERROR: Insufficient access: Could not read UPG Definition originfilter. Check your permissions. -sh-4.2$ klist -kt ipa004.keytab Keytab name: FILE:ipa004.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 18/05/15 14:23:24 host/ipa004.jackland.uk at TEST.JACKLAND.UK 2 18/05/15 14:23:24 host/ipa004.jackland.uk at TEST.JACKLAND.UK 2 18/05/15 14:23:24 host/ipa004.jackland.uk at TEST.JACKLAND.UK 2 18/05/15 14:23:24 host/ipa004.jackland.uk at TEST.JACKLAND.UK 4 31/05/15 10:55:37 useradder at TEST.JACKLAND.UK 4 31/05/15 10:55:37 useradder at TEST.JACKLAND.UK 4 31/05/15 10:55:37 useradder at TEST.JACKLAND.UK 4 31/05/15 10:55:37 useradder at TEST.JACKLAND.UK -sh-4.2$ Installed Packages Name : ipa-server Arch : x86_64 Version : 4.1.0 Release : 18.el7_1.3 Size : 4.2 M Repo : installed >From repo : rhel-7-server-rpms Summary : The IPA authentication server URL : http://www.freeipa.org/ Licence : GPLv3+ Description : IPA is an integrated solution to provide centrally managed Identity (machine, : user, virtual machines, groups, authentication credentials), Policy : (configuration settings, access control information) and Audit (events, : logs, analysis thereof). If you are installing an IPA server you need : to install this package (in other words, most people should NOT install : this package).