From jhrozek at redhat.com Wed Feb 1 07:55:26 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 1 Feb 2017 08:55:26 +0100 Subject: [Freeipa-users] caching of lookups / performance problem In-Reply-To: References: <4DA19EAC-6287-4EDA-BCE7-A5A22172BBCA@bsd.uchicago.edu> Message-ID: <20170201075526.vtietqlvgh3t6snv@hendrix> On Tue, Jan 31, 2017 at 08:05:18PM +0000, Sullivan, Daniel [CRI] wrote: > Hi, > > I figured out what was going on with this issue. Basically cache timeouts were causing a large number of uid numbers in an arbitrarily-timed directory listing to have expired cache records, which causes those records to be looked up again by the data provider (and thus blocking ?ls -l?). To work around this issue now we currently setting the entry_cache_timeout to something arbitrarily high, i.e. 999999, I?m questioning whether or not this is the best approach. I?d like to use something like refresh_expired_interval, although based on my testing it appears that this does not update records for a trusted AD domain. I?ve also tried using enumeration, and that doesn?t seem to work either. > > I suppose my question is this; is there a preferred method to keep cache records up-to-date for a trusted AD domain? Right now I am thinking about cron-tabbing an ?ls -l? of /home and allowing entry_cache_nowait_percentage to fill this function, although that seems hacky to me. > > Any advisement that could be provided would be greatly appreciated. Hi, If the entries are requested reasonably often (typically at least once per cache lifetime), then maybe just lowering the 'entry_cache_nowait_percentage' value so that the background check is performed more often might help. From michael at stroeder.com Wed Feb 1 08:04:57 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 1 Feb 2017 09:04:57 +0100 Subject: [Freeipa-users] Identification with openLDAP and authorization with FreeIPA In-Reply-To: <20170131225257.ghk4inzly3jsi3my@redhat.com> References: <9ecb2e8b-f0df-dbad-cf87-0c1cf2cd5a86@gmail.com> <20170131152327.4edj2n6g66qriif5@redhat.com> <204e9da7-ff30-9a36-e8d4-97c87c4069ea@gmail.com> <20170131154235.5ktjbxqo3nskgaab@redhat.com> <528ce81a-96de-353f-e5a7-30e2079fd29d@gmail.com> <20170131225257.ghk4inzly3jsi3my@redhat.com> Message-ID: Alexander Bokovoy wrote: > On ti, 31 tammi 2017, Rich Megginson wrote: >> On 01/31/2017 04:46 PM, Micha?l Van de Borne wrote: >>> That was the feared, but somehow expected, answer. >>> >>> Any entry point/documentation about how to start such a script? >> >> Do FreeIPA and OpenLDAP still support the syncrepl protocol? > > a standard syncrepl provider/consumer pair expects to have the very same > LDAP schema on both sides. This is not the case with OpenLDAP and > FreeIPA. Yes. Another option would be to implement a custom syncrepl client which is of course a lot of work to get it right. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From th at casalogic.dk Wed Feb 1 08:53:15 2017 From: th at casalogic.dk (Troels Hansen) Date: Wed, 1 Feb 2017 09:53:15 +0100 (CET) Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> Message-ID: <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> Hmm, suspect its happening on the server...... thous I haven't been able to pinpoint a log entry that confirms my suspecting. I have pinpointed the timeout to happen after 58 seconds after completely removing the SSSD cache and restaring SSSD, which leads me to think my issue is related to ldap_enumaration_search_timeout which defaults to 60. rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja However, I'm unable to crank it up on the server as it seems to be adjusted Down to 60 Again? Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option ldap_enumeration_search_timeout has value 120 (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60 (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60 LDAP seems speedy enough, not timeouts while querying it manually while a client is doing a user lookup. ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: > > If the timeout is occurring on the server, I would start by increasing one or > both of these values: > > ldap_opt_timeout > ldap_search_timeout > > If that doesn?t work I?d take look to see if the 389 server is under high load > when you are performing this operation. The easiest way I have found to do > this is to just execute an LDAP query directly against the IPA server when you > are performing an id lookup, for example: > > ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" > "(objectclass=*)? > > If the LDAP server is not responsive you probably need to increase the number of > worker threads for 389ds. Also, you might want to disable referrals, check out > the man pages for this; > > ldap_referrals = false > > Also, FWIW, if you crank up debug logging on the sssd client, you should be able > to see the amount of seconds of timeout assigned to the operation, and witness > the fact that the operation is actually timing out by inspecting the logs > themselves. The logs can get a little verbose but the data is there. > From deepak.dimri2016 at gmail.com Wed Feb 1 09:22:45 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Wed, 1 Feb 2017 14:52:45 +0530 Subject: [Freeipa-users] Gateway_timeout Error Message-ID: Hi All, I have two IPA servers - primary and secondary running. the secondary ipa server is installed using ipa replica image of primary. While doing the testing i realised that when i manually shut down my primary ipa server making my secondary server to serve the UI. And now when i try to access user or hosts details using my secondary server then i am getting below error in the UI. I am able to login fine though; it is just that when i double click on host objects then i get the error. An error has occurred (GATEWAY_TIMEOUT) I am still trying to troubleshoot as why i am getting timeout error but thought of asking the group here to see if some one can share some pointers Many Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Wed Feb 1 09:33:57 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 1 Feb 2017 10:33:57 +0100 Subject: [Freeipa-users] Gateway_timeout Error In-Reply-To: References: Message-ID: On 02/01/2017 10:22 AM, deepak dimri wrote: > Hi All, > > I have two IPA servers - primary and secondary running. the secondary > ipa server is installed using ipa replica image of primary. While doing > the testing i realised that when i manually shut down my primary ipa > server making my secondary server to serve the UI. And now when i try to > access user or hosts details using my secondary server then i am getting > below error in the UI. I am able to login fine though; it is just that > when i double click on host objects then i get the error. > > > An error has occurred (GATEWAY_TIMEOUT) > > > I am still trying to troubleshoot as why i am getting timeout error but > thought of asking the group here to see if some one can share some pointers > > Many Thanks, > Deepak > > Hi Deepak, please check /etc/ipa/default.conf on the secondary server and check the value of 'xmlrpc_uri'. Maybe it points to the URL of primary server and that's why you get timeouts when it is down. Re-setting it to the secondary server itself should fix it. -- Martin^3 Babinsky From th at casalogic.dk Wed Feb 1 10:32:15 2017 From: th at casalogic.dk (Troels Hansen) Date: Wed, 1 Feb 2017 11:32:15 +0100 (CET) Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> Message-ID: <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> >From looking af at TCP dump, I can see that if a client requests a AD user from IPA, IPA does a full user lookup in AD, even though the IPA server have the user in local cache? It looks like a single group generates a LOT of traffic to AD like: client -> IPA IPA -> client IPA -> AD AD -> IPA IPA -> AD IPA -> Second AD Second AD -> IPA IPA -> Second AD IPA -> AD AD -> IPA IPA -> AD IPA -> client client -> IPA IPA -> Client Something similar continues for every group the user has. Soo, I guess the question that I haven't been able to find documented anywhere. Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd client requests a user? ----- On Feb 1, 2017, at 9:53 AM, Troels Hansen th at casalogic.dk wrote: > Hmm, suspect its happening on the server...... thous I haven't been able to > pinpoint a log entry that confirms my suspecting. > > I have pinpointed the timeout to happen after 58 seconds after completely > removing the SSSD cache and restaring SSSD, which leads me to think my issue is > related to ldap_enumaration_search_timeout which defaults to 60. > > rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja > > However, I'm unable to crank it up on the server as it seems to be adjusted Down > to 60 Again? > > Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option > ldap_enumeration_search_timeout has value 120 > (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): > Option ldap_enumeration_search_timeout has value 60 > (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): > Option ldap_enumeration_search_timeout has value 60 > > LDAP seems speedy enough, not timeouts while querying it manually while a client > is doing a user lookup. > > ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] > dsullivan2 at bsd.uchicago.edu wrote: > >> >> If the timeout is occurring on the server, I would start by increasing one or >> both of these values: >> >> ldap_opt_timeout >> ldap_search_timeout >> >> If that doesn?t work I?d take look to see if the 389 server is under high load >> when you are performing this operation. The easiest way I have found to do >> this is to just execute an LDAP query directly against the IPA server when you >> are performing an id lookup, for example: >> >> ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" >> "(objectclass=*)? >> >> If the LDAP server is not responsive you probably need to increase the number of >> worker threads for 389ds. Also, you might want to disable referrals, check out >> the man pages for this; >> >> ldap_referrals = false >> >> Also, FWIW, if you crank up debug logging on the sssd client, you should be able >> to see the amount of seconds of timeout assigned to the operation, and witness >> the fact that the operation is actually timing out by inspecting the logs >> themselves. The logs can get a little verbose but the data is there. >> > > -- > 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From christophe.trefois at uni.lu Wed Feb 1 13:06:23 2017 From: christophe.trefois at uni.lu (Christophe TREFOIS) Date: Wed, 1 Feb 2017 13:06:23 +0000 Subject: [Freeipa-users] Replica FQDN / Domain question Message-ID: <1646193A-C60C-4D85-9306-881D5F2ED56C@uni.lu> Hi all, Small question which might be naive. We have an existing setup with 4 replicas, all with FQDNs like replica1.example.com and REALM example.com. We want to add another replica, replica5, whose FQDN would have a different domain, so say replica5.example.org. The DNS would be resolvable as it would be managed by the same DNS server (outside of our control). We don?t think this should have any impact. Is this a fair assumption? We just want to make sure. Kind regards, Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Wed Feb 1 13:15:39 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 1 Feb 2017 14:15:39 +0100 Subject: [Freeipa-users] Gateway_timeout Error In-Reply-To: References: Message-ID: <215e3abb-4137-d311-ea8c-dca541664178@redhat.com> On 02/01/2017 11:17 AM, deepak dimri wrote: > Hello Martin, Thank you so much for your reply. > > I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary server and > its pointing to its own hostname and not to primary server hostname :( > > any other clue, Martin? > > I have tried without proxy and again to luck either its throwing same > gateway_error > > Regards, > Deepak > > On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky > wrote: > > On 02/01/2017 10:22 AM, deepak dimri wrote: > > Hi All, > > I have two IPA servers - primary and secondary running. the > secondary > ipa server is installed using ipa replica image of primary. > While doing > the testing i realised that when i manually shut down my primary ipa > server making my secondary server to serve the UI. And now when > i try to > access user or hosts details using my secondary server then i am > getting > below error in the UI. I am able to login fine though; it is > just that > when i double click on host objects then i get the error. > > > An error has occurred (GATEWAY_TIMEOUT) > > > I am still trying to troubleshoot as why i am getting timeout > error but > thought of asking the group here to see if some one can share > some pointers > > Many Thanks, > Deepak > > > Hi Deepak, > > please check /etc/ipa/default.conf on the secondary server and check > the value of 'xmlrpc_uri'. Maybe it points to the URL of primary > server and that's why you get timeouts when it is down. > > Re-setting it to the secondary server itself should fix it. > > -- > Martin^3 Babinsky > > -- > 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 > > Adding freeipa-users back to loop. That is strange, how did you stand up the replica? You can also inspect /var/log/http/error_log on the replica to see whether the commands from the WebUI reach the local HTTP server at all. -- Martin^3 Babinsky From dsullivan2 at bsd.uchicago.edu Wed Feb 1 13:15:44 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Wed, 1 Feb 2017 13:15:44 +0000 Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> Message-ID: The ldap_enumeration_search_timeout is for enumeration, this is for looking up all users, try using the ldap_opt_timeout and or ldap_opt_timeout for a single user lookup. If a lookup is timing out you will definitely see it in your domain logs, it?s hard to miss. I would take the time to familiarize yourself at a minimum with the following two articles: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ Also, this is very good document to familiarize yourself with, it has a lot of very detailed and use information. https://fedorahosted.org/sssd/wiki/InternalsDocs My personal opinion based on experience is that if you are going to be leveraging sssd in a trusted AD setup, you should be prepared to take on performance tuning considerations and become intimately familiar with the internals of sssd, specifically how a lookup works, and how to tune sssd as well as 389ds. You should know the difference between the mapped memory cache, the sysdb, how to use ldbsearch to inspect the cache, etc. The learning curve is a little steep but once you get over it it?s not that bad. Dan > On Feb 1, 2017, at 2:53 AM, Troels Hansen wrote: > > Hmm, suspect its happening on the server...... thous I haven't been able to pinpoint a log entry that confirms my suspecting. > > I have pinpointed the timeout to happen after 58 seconds after completely removing the SSSD cache and restaring SSSD, which leads me to think my issue is related to ldap_enumaration_search_timeout which defaults to 60. > > rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja > > However, I'm unable to crank it up on the server as it seems to be adjusted Down to 60 Again? > > Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option ldap_enumeration_search_timeout has value 120 > (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60 > (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60 > > LDAP seems speedy enough, not timeouts while querying it manually while a client is doing a user lookup. > > ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: > >> >> If the timeout is occurring on the server, I would start by increasing one or >> both of these values: >> >> ldap_opt_timeout >> ldap_search_timeout >> >> If that doesn?t work I?d take look to see if the 389 server is under high load >> when you are performing this operation. The easiest way I have found to do >> this is to just execute an LDAP query directly against the IPA server when you >> are performing an id lookup, for example: >> >> ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" >> "(objectclass=*)? >> >> If the LDAP server is not responsive you probably need to increase the number of >> worker threads for 389ds. Also, you might want to disable referrals, check out >> the man pages for this; >> >> ldap_referrals = false >> >> Also, FWIW, if you crank up debug logging on the sssd client, you should be able >> to see the amount of seconds of timeout assigned to the operation, and witness >> the fact that the operation is actually timing out by inspecting the logs >> themselves. The logs can get a little verbose but the data is there. >> From mbasti at redhat.com Wed Feb 1 13:18:17 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 1 Feb 2017 14:18:17 +0100 Subject: [Freeipa-users] Replica FQDN / Domain question In-Reply-To: <1646193A-C60C-4D85-9306-881D5F2ED56C@uni.lu> References: <1646193A-C60C-4D85-9306-881D5F2ED56C@uni.lu> Message-ID: On 01.02.2017 14:06, Christophe TREFOIS wrote: > Hi all, > > Small question which might be naive. > > We have an existing setup with 4 replicas, all with FQDNs like > replica1.example.com and REALM > example.com . > > We want to add another replica, replica5, whose FQDN would have a > different domain, so say replica5.example.org > . > The DNS would be resolvable as it would be managed by the same DNS > server (outside of our control). > > We don?t think this should have any impact. > > Is this a fair assumption? We just want to make sure. > > Kind regards, > Christophe > > It should work, but keep on mind that replica5 will be still part of realm EXAMPLE.COM Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsullivan2 at bsd.uchicago.edu Wed Feb 1 13:27:19 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Wed, 1 Feb 2017 13:27:19 +0000 Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> Message-ID: <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> Have you checked to see if the user is expired in the cache, or if it is impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry timeout is only 90 minutes and entry_cache_nowait_percentage default is 50. ldbsearch -H /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb > ~/timestamps.txt ldbsearch -H /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt Might be able to provide more info. Again, I?d really familiarize yourself with the anatomy of an sssd lookup, if you get to know the diagram and steps 1-7 here it will be a big help to your question(s). https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ Dan > On Feb 1, 2017, at 4:32 AM, Troels Hansen wrote: > >> From looking af at TCP dump, I can see that if a client requests a AD user from IPA, IPA does a full user lookup in AD, even though the IPA server have the user in local cache? > > It looks like a single group generates a LOT of traffic to AD like: > client -> IPA > IPA -> client > IPA -> AD > AD -> IPA > IPA -> AD > IPA -> Second AD > Second AD -> IPA > IPA -> Second AD > IPA -> AD > AD -> IPA > IPA -> AD > IPA -> client > client -> IPA > IPA -> Client > > Something similar continues for every group the user has. > > Soo, I guess the question that I haven't been able to find documented anywhere. > Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd client requests a user? > > > > ----- On Feb 1, 2017, at 9:53 AM, Troels Hansen th at casalogic.dk wrote: > >> Hmm, suspect its happening on the server...... thous I haven't been able to >> pinpoint a log entry that confirms my suspecting. >> >> I have pinpointed the timeout to happen after 58 seconds after completely >> removing the SSSD cache and restaring SSSD, which leads me to think my issue is >> related to ldap_enumaration_search_timeout which defaults to 60. >> >> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja >> >> However, I'm unable to crank it up on the server as it seems to be adjusted Down >> to 60 Again? >> >> Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option >> ldap_enumeration_search_timeout has value 120 >> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >> Option ldap_enumeration_search_timeout has value 60 >> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >> Option ldap_enumeration_search_timeout has value 60 >> >> LDAP seems speedy enough, not timeouts while querying it manually while a client >> is doing a user lookup. >> >> ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] >> dsullivan2 at bsd.uchicago.edu wrote: >> >>> >>> If the timeout is occurring on the server, I would start by increasing one or >>> both of these values: >>> >>> ldap_opt_timeout >>> ldap_search_timeout >>> >>> If that doesn?t work I?d take look to see if the 389 server is under high load >>> when you are performing this operation. The easiest way I have found to do >>> this is to just execute an LDAP query directly against the IPA server when you >>> are performing an id lookup, for example: >>> >>> ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" >>> "(objectclass=*)? >>> >>> If the LDAP server is not responsive you probably need to increase the number of >>> worker threads for 389ds. Also, you might want to disable referrals, check out >>> the man pages for this; >>> >>> ldap_referrals = false >>> >>> Also, FWIW, if you crank up debug logging on the sssd client, you should be able >>> to see the amount of seconds of timeout assigned to the operation, and witness >>> the fact that the operation is actually timing out by inspecting the logs >>> themselves. The logs can get a little verbose but the data is there. >>> >> >> -- >> 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 > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. > > -- > 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 dsullivan2 at bsd.uchicago.edu Wed Feb 1 14:35:00 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Wed, 1 Feb 2017 14:35:00 +0000 Subject: [Freeipa-users] caching of lookups / performance problem In-Reply-To: <20170201075526.vtietqlvgh3t6snv@hendrix> References: <4DA19EAC-6287-4EDA-BCE7-A5A22172BBCA@bsd.uchicago.edu> <20170201075526.vtietqlvgh3t6snv@hendrix> Message-ID: Jakub, Thank you for getting back to me. Yeah, I agree with what you are saying. The problem that I?m really trying to solve is the how to get them requested reasonably often part. A good use case for my problem is basically; 1) Somebody starts an interactive job on a compute node (this is somewhat unusual in it of itself). There?s a decent chance that nobody has done this for weeks or months months in the first place. Since a large number of our 1000 or so users aren?t compute users theres a high probablity that we have a substantial number of expired cached entries, possibly 500 or more for users in /home. 2) They are navigating around on the filesystem and cd into /home and type ?ls -l? This command will actually take upwards of an hour to execute (although it will complete eventually). If an ?ls -l? on a Linux system takes more than a few seconds people will think there?s a problem with the system. Based on my experience even ?nowait percentage? has a difficult time with a large number of records past the nowait threshold. For example, if there are 500 records past the expiration percentage threshold, the data provider will get ?busy? which seems to effectively appears to block the nss responder, instead of returning all 500 of those records from the cache and then queueing 500 data provider requests in the background to refresh the cache. Right now the only ways I can seem to get around this is to do a regular ?ls -l? to refresh the cache on our nodes, or just defer the problem by setting a really high entry cache timeout. The cron approach is a little bit challenging because we need to randomize invocation times because bulk cache refreshes across the environment are going to cause high load on our domain controllers (I know this because a single cache refresh causes ns-slapd to hit 100% and sustain CPU utilization for the duration of the enumeration). Is there anything crazy about setting the entry cache timeout on the client to something arbitrarily high, like 5 years (other than knowing the cache is not accurate)? Based on my knowledge a user?s groups are evaluated at login so this should be a non-issue from a security standpoint. Dan > On Feb 1, 2017, at 1:55 AM, Jakub Hrozek wrote: > > On Tue, Jan 31, 2017 at 08:05:18PM +0000, Sullivan, Daniel [CRI] wrote: >> Hi, >> >> I figured out what was going on with this issue. Basically cache timeouts were causing a large number of uid numbers in an arbitrarily-timed directory listing to have expired cache records, which causes those records to be looked up again by the data provider (and thus blocking ?ls -l?). To work around this issue now we currently setting the entry_cache_timeout to something arbitrarily high, i.e. 999999, I?m questioning whether or not this is the best approach. I?d like to use something like refresh_expired_interval, although based on my testing it appears that this does not update records for a trusted AD domain. I?ve also tried using enumeration, and that doesn?t seem to work either. >> >> I suppose my question is this; is there a preferred method to keep cache records up-to-date for a trusted AD domain? Right now I am thinking about cron-tabbing an ?ls -l? of /home and allowing entry_cache_nowait_percentage to fill this function, although that seems hacky to me. >> >> Any advisement that could be provided would be greatly appreciated. > > Hi, > > If the entries are requested reasonably often (typically at least once > per cache lifetime), then maybe just lowering the > 'entry_cache_nowait_percentage' value so that the background check is > performed more often might help. > > -- > 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 michael.van.de.borne at gmail.com Wed Feb 1 14:48:35 2017 From: michael.van.de.borne at gmail.com (=?UTF-8?Q?Micha=c3=abl_Van_de_Borne?=) Date: Wed, 1 Feb 2017 15:48:35 +0100 Subject: [Freeipa-users] Identification with openLDAP and authorization with FreeIPA In-Reply-To: References: <9ecb2e8b-f0df-dbad-cf87-0c1cf2cd5a86@gmail.com> <20170131152327.4edj2n6g66qriif5@redhat.com> <204e9da7-ff30-9a36-e8d4-97c87c4069ea@gmail.com> <20170131154235.5ktjbxqo3nskgaab@redhat.com> <528ce81a-96de-353f-e5a7-30e2079fd29d@gmail.com> <20170131225257.ghk4inzly3jsi3my@redhat.com> Message-ID: Ok, thank you very much guys for your ideas. That's why I definitely love open source... :) Cheers, m. Le 01-02-17 ? 09:04, Michael Str?der a ?crit : > Alexander Bokovoy wrote: >> On ti, 31 tammi 2017, Rich Megginson wrote: >>> On 01/31/2017 04:46 PM, Micha?l Van de Borne wrote: >>>> That was the feared, but somehow expected, answer. >>>> >>>> Any entry point/documentation about how to start such a script? >>> Do FreeIPA and OpenLDAP still support the syncrepl protocol? >> a standard syncrepl provider/consumer pair expects to have the very same >> LDAP schema on both sides. This is not the case with OpenLDAP and >> FreeIPA. > Yes. > > Another option would be to implement a custom syncrepl client which is of course a lot of > work to get it right. > > Ciao, Michael. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Feb 1 15:08:47 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 1 Feb 2017 16:08:47 +0100 Subject: [Freeipa-users] caching of lookups / performance problem In-Reply-To: References: <4DA19EAC-6287-4EDA-BCE7-A5A22172BBCA@bsd.uchicago.edu> <20170201075526.vtietqlvgh3t6snv@hendrix> Message-ID: <20170201150847.6njxsvbdiuienckf@hendrix> On Wed, Feb 01, 2017 at 02:35:00PM +0000, Sullivan, Daniel [CRI] wrote: > Jakub, > > Thank you for getting back to me. Yeah, I agree with what you are saying. The problem that I?m really trying to solve is the how to get them requested reasonably often part. A good use case for my problem is basically; > > 1) Somebody starts an interactive job on a compute node (this is somewhat unusual in it of itself). There?s a decent chance that nobody has done this for weeks or months months in the first place. Since a large number of our 1000 or so users aren?t compute users theres a high probablity that we have a substantial number of expired cached entries, possibly 500 or more for users in /home. > 2) They are navigating around on the filesystem and cd into /home and type ?ls -l? > > This command will actually take upwards of an hour to execute (although it will complete eventually). If an ?ls -l? on a Linux system takes more than a few seconds people will think there?s a problem with the system. > > Based on my experience even ?nowait percentage? has a difficult time with a large number of records past the nowait threshold. For example, if there are 500 records past the expiration percentage threshold, the data provider will get ?busy? which seems to effectively appears to block the nss responder, instead of returning all 500 of those records from the cache and then queueing 500 data provider requests in the background to refresh the cache. Yes, when the cache is totally expired, the request would block. > > Right now the only ways I can seem to get around this is to do a regular ?ls -l? to refresh the cache on our nodes, or just defer the problem by setting a really high entry cache timeout. The cron approach is a little bit challenging because we need to randomize invocation times because bulk cache refreshes across the environment are going to cause high load on our domain controllers (I know this because a single cache refresh causes ns-slapd to hit 100% and sustain CPU utilization for the duration of the enumeration). > > Is there anything crazy about setting the entry cache timeout on the client to something arbitrarily high, like 5 years (other than knowing the cache is not accurate)? Based on my knowledge a user?s groups are evaluated at login so this should be a non-issue from a security standpoint. I think a long expiration together with the nowait percentage might be a way to go. From dsullivan2 at bsd.uchicago.edu Wed Feb 1 15:12:20 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Wed, 1 Feb 2017 15:12:20 +0000 Subject: [Freeipa-users] caching of lookups / performance problem In-Reply-To: <20170201150847.6njxsvbdiuienckf@hendrix> References: <4DA19EAC-6287-4EDA-BCE7-A5A22172BBCA@bsd.uchicago.edu> <20170201075526.vtietqlvgh3t6snv@hendrix> <20170201150847.6njxsvbdiuienckf@hendrix> Message-ID: <52D9362D-6BF8-4867-949A-DFEA2753B92E@bsd.uchicago.edu> Alright cool, thank you for getting back to me. I appreciate your input and expertise. Dan > On Feb 1, 2017, at 9:08 AM, Jakub Hrozek wrote: > > On Wed, Feb 01, 2017 at 02:35:00PM +0000, Sullivan, Daniel [CRI] wrote: >> Jakub, >> >> Thank you for getting back to me. Yeah, I agree with what you are saying. The problem that I?m really trying to solve is the how to get them requested reasonably often part. A good use case for my problem is basically; >> >> 1) Somebody starts an interactive job on a compute node (this is somewhat unusual in it of itself). There?s a decent chance that nobody has done this for weeks or months months in the first place. Since a large number of our 1000 or so users aren?t compute users theres a high probablity that we have a substantial number of expired cached entries, possibly 500 or more for users in /home. >> 2) They are navigating around on the filesystem and cd into /home and type ?ls -l? >> >> This command will actually take upwards of an hour to execute (although it will complete eventually). If an ?ls -l? on a Linux system takes more than a few seconds people will think there?s a problem with the system. >> >> Based on my experience even ?nowait percentage? has a difficult time with a large number of records past the nowait threshold. For example, if there are 500 records past the expiration percentage threshold, the data provider will get ?busy? which seems to effectively appears to block the nss responder, instead of returning all 500 of those records from the cache and then queueing 500 data provider requests in the background to refresh the cache. > > Yes, when the cache is totally expired, the request would block. > >> >> Right now the only ways I can seem to get around this is to do a regular ?ls -l? to refresh the cache on our nodes, or just defer the problem by setting a really high entry cache timeout. The cron approach is a little bit challenging because we need to randomize invocation times because bulk cache refreshes across the environment are going to cause high load on our domain controllers (I know this because a single cache refresh causes ns-slapd to hit 100% and sustain CPU utilization for the duration of the enumeration). >> >> Is there anything crazy about setting the entry cache timeout on the client to something arbitrarily high, like 5 years (other than knowing the cache is not accurate)? Based on my knowledge a user?s groups are evaluated at login so this should be a non-issue from a security standpoint. > > I think a long expiration together with the nowait percentage might be > a way to go. From mbabinsk at redhat.com Wed Feb 1 15:51:30 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 1 Feb 2017 16:51:30 +0100 Subject: [Freeipa-users] Gateway_timeout Error In-Reply-To: References: <215e3abb-4137-d311-ea8c-dca541664178@redhat.com> Message-ID: On 02/01/2017 04:26 PM, deepak dimri wrote: > Yes, Martin - i do see requests hitting > replica.. /var/log/httpd/error_log shows: > > [Wed Feb 01 15:16:47.469766 2017] [:error] [pid 2464] ipa: INFO: > admin at XXX.XYZ.COM : batch: > host_show(u'xxx.abx.xyz ', rights=True, all=True): > SUCCESS > > I used ansible playbook to build the replica server. ran > ipa-replica-prepare on the primary: > ipa-replica-prepare {{ replica_dns }} --password={{ipa_password}} > --no-wait-for-dns > > copied the replica file over to replica server: > scp -oStrictHostKeyChecking=no -i ~/.ssh/{{ssh_keyname}}.pem > /var/lib/ipa/replica-info-{{ replica_dns }}.gpg root@{{ > replica_dns }}:/var/lib/ipa/ > > ran the replica install on the replica server: > ipa-replica-install /var/lib/ipa/replica-info-{{ replica_dns }}.gpg > --password={{ipa_password}} --admin-password={{ipa_password}} > > I have notices that if i directly use the replica (bypassing proxy) URL > then the objects shows after waiting for over a minute or so. When i use > proxy pass then it just times out after few seconds. > > No clue why its behaving like this > > Many Thanks, > Deepak > > On Wed, Feb 1, 2017 at 6:45 PM, Martin Babinsky > wrote: > > On 02/01/2017 11:17 AM, deepak dimri wrote: > > Hello Martin, Thank you so much for your reply. > > I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary > server and > its pointing to its own hostname and not to primary server > hostname :( > > any other clue, Martin? > > I have tried without proxy and again to luck either its throwing > same > gateway_error > > Regards, > Deepak > > On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky > > >> wrote: > > On 02/01/2017 10:22 AM, deepak dimri wrote: > > Hi All, > > I have two IPA servers - primary and secondary running. the > secondary > ipa server is installed using ipa replica image of primary. > While doing > the testing i realised that when i manually shut down my > primary ipa > server making my secondary server to serve the UI. And > now when > i try to > access user or hosts details using my secondary server > then i am > getting > below error in the UI. I am able to login fine though; it is > just that > when i double click on host objects then i get the error. > > > An error has occurred (GATEWAY_TIMEOUT) > > > I am still trying to troubleshoot as why i am getting > timeout > error but > thought of asking the group here to see if some one can > share > some pointers > > Many Thanks, > Deepak > > > Hi Deepak, > > please check /etc/ipa/default.conf on the secondary server > and check > the value of 'xmlrpc_uri'. Maybe it points to the URL of primary > server and that's why you get timeouts when it is down. > > Re-setting it to the secondary server itself should fix it. > > -- > Martin^3 Babinsky > > -- > 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 > > > > Adding freeipa-users back to loop. > > That is strange, how did you stand up the replica? > > You can also inspect /var/log/http/error_log on the replica to see > whether the commands from the WebUI reach the local HTTP server at all. > > -- > Martin^3 Babinsky > > Deepak, please keep replying to freeipa-users mailing list, otherwise other members do not get updates on your problem. As for the issues with replica, I did not notice before that you are connecting to WebUI through a proxy, what kind of proxy is that and how is it configured? Nevertheless waiting for over a minute to display entries does not sound right. I would investigate the root cause of this performance regression by checking DS access and error logs on the replica (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}). Does the master also take so long time to respond? What are the IPA versions of master/replica? -- Martin^3 Babinsky From huston at astro.princeton.edu Wed Feb 1 16:47:50 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Wed, 1 Feb 2017 11:47:50 -0500 Subject: [Freeipa-users] Backend & UI plugin update for 4.4.x In-Reply-To: References: <20170119161635.56vlybbhvnfn44tc@redhat.com> <20170119181440.x77gboawdyjep7pp@redhat.com> <2e45b170-d467-7bd9-f9fe-efd4fcd4ded8@redhat.com> Message-ID: Would it be better to file this as a new bug, or reopen 4291? On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston wrote: > Seems like this is to blame: https://fedorahosted.org/freeipa/ticket/4291 > > The checkin says, "Installation in pure IPv6 environment failed > because pki-tomcat tried to use > IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4 > fixes this issue." However it would seem that in a pure IPv4 > environment, this is causing tomcat to fail to load. > > On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston > wrote: >> What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml? >> >> >> >> > address="::1" /> >> >> Doesn't work so well on a host without IPv6 turned on... >> >> Jan 31 14:26:59 ipa server: PKIListener: >> org.apache.catalina.core.StandardServer[before_init] >> Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point >> associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"] >> Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family >> unavailable >> >> On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston >> wrote: >>> Stranger, I did an install on a different VM with the CentOS 7 minimal >>> ISO, then installed ipa-server and enough things to get X11 and >>> Firefox, ran ipa-server-install and it worked fine. I tested with >>> Firefox (and Safari) against my failing installation and it still >>> fails. So there's something else different that's causing it to >>> break. Will continue investigating, but if someone knows why the UI >>> would break this way it would be helpful to know where to look! >>> >>> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston >>> wrote: >>>> Just did it again with the same result. Reinstalled the machine, then >>>> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in >>>> version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the >>>> ipa-server-install as I used before, only without --mkhomedir this >>>> time. After entering the passwords for directory administrator and >>>> the admin user, I then logged in to the web interface, immediately >>>> clicked "add" and added a user 'foobar'. When I clicked "add and >>>> edit" and was brought to the user information page, it looks like this >>>> at the bottom: >>>> >>>> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 >>>> >>>> I then entered an employee number of '0001' just to give something to >>>> save, and clicked save. The screen now shows this (I've clicked the >>>> drop-down on the manager field so the choices are visible): >>>> >>>> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 >>>> >>>> Holding shift and clicking reload, the page now looks like this (the >>>> employee number field is also blank again): >>>> >>>> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 >>>> >>>> Since we do run a repackaged distribution here (Springdale Linux), I >>>> just unpacked ipa-server-common from our repository with the above >>>> version, and http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, >>>> and 'diff' found zero differences between them. Unlikely, but I >>>> wanted to rule out a packaging error causing the problem. >>>> >>>> On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston >>>> wrote: >>>>> No, that should be all of the major changes; the puppet module that >>>>> installs things only puts the two plugin files in their respective >>>>> places. The client part of the IPA module makes changes to have the >>>>> machine join the domain and whatnot, but those shouldn't affect the >>>>> webui. >>>>> >>>>> I do modify the schema by adding some attribute types for Puppet, >>>>> namely puppetClass, parentNode, environment, puppetVar, and the object >>>>> class puppetClient. That's basically right from one of the Puppet >>>>> webpages and also worked in the past - and is one of the things the >>>>> python plugin does, add the appropriate objectclass to host entries if >>>>> puppetVar is added to a host entry. >>>>> >>>>> My steps to install: >>>>> * ipa-server-install --realm= --domain= --mkhomedir >>>>> --hostname= --no-host-dns >>>>> * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W >>>>> < paste puppet schema changes> >>>>> < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a >>>>> service account used by puppet for adding hosts to IPA > >>>>> * login to web UI >>>>> * * Change home directory base, default shell, default SELinux user >>>>> * * Add SELinux user map for staff/sysadmin users >>>>> * * Add "user adder" permission/privilege/role for users who will be >>>>> able to create stageusers >>>>> >>>>> That's about as far as I got before I realized some of the plugin >>>>> pieces weren't working, and then fixed the python plugin followed by >>>>> working on the UI plugin and finding this problem. I'll go wipe and >>>>> reinstall the system again and walk through the steps, but test the UI >>>>> first and in between to see if I can find which of the steps might be >>>>> causing things to hiccup. >>>>> >>>>> On Wed, Jan 25, 2017 at 1:42 PM, Pavel Vomacka wrote: >>>>>> Hello Steve, >>>>>> >>>>>> I tried to reproduce what you described on the very same version of >>>>>> ipa-server and I was not successful. Actually I was not used your back-end >>>>>> plugin. I tried it with no plugin and then with your UI plugin and both >>>>>> worked correctly. Did you do any other changes somewhere in your >>>>>> installation? >>>>>> >>>>>> I will try it again also with your Python plugin and we'll see. >>>>>> >>>>>> >>>>>> On 01/24/2017 08:59 PM, Steve Huston wrote: >>>>>>> >>>>>>> And now I'm convinced this has nothing to do with my plugin and >>>>>>> instead is a bug somewhere in FreeIPA. >>>>>>> >>>>>>> I removed the entirety of the "astrocustom" plugin that I wrote, >>>>>>> restarted httpd, and force reloaded the page in chrome. I clicked to >>>>>>> add a new user, gave the basic information, and clicked "add and >>>>>>> edit". The bottom of the page shows the "Employee information" on the >>>>>>> left side bottom, and the manager drop-down is empty. I entered '1' >>>>>>> in the "employee type" field and clicked save, and now "Employee >>>>>>> Information" is on the right side directly under "Contact settings", >>>>>>> and the manager drop-down is populated with the list of UIDs on the >>>>>>> system. >>>>>>> >>>>>>> When the UI is in the failed state, the "email address" field is also >>>>>>> blank, but when things switch to how they should be (after submitting >>>>>>> a change) it is populated with the email address in the record. I >>>>>>> just tested by adding a telephone number to the record, and that also >>>>>>> made the contact information and employee information facets refresh >>>>>>> with the proper data. Pressing shift-reload again makes all the >>>>>>> information disappear (including the telephone number I just entered). >>>>>>> >>>>>>> This is with ipa-server-4.4.0-14.el7_3.4 >>>>>>> >>>>>>> >>>>>>> On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston >>>>>>> wrote: >>>>>>>> >>>>>>>> Just tested again, and this is still baffling: >>>>>>>> >>>>>>>> * Create a stage user with the right data, works fine, can be edited. >>>>>>>> * Enable that user, and now the two fields ('manager' and >>>>>>>> 'employeeType') appear to have bogus data in the UI, and I cannot save >>>>>>>> the page without changing them to something else. >>>>>>>> * Once that user is saved, the "Employee Information" facet moves to >>>>>>>> the right side of the page, and now shows not only the current data in >>>>>>>> the manager drop down but also the other choices (uids). Change the >>>>>>>> value of manager and employeetype back to what they were previously >>>>>>>> and it saves. >>>>>>>> * An ldapsearch run when the user is first created (as the directory >>>>>>>> manager), and after having two edits (one to change the values to >>>>>>>> something else to let the webui save them, and one to change them back >>>>>>>> to what they should be and were the first time) produce completely >>>>>>>> identical results. >>>>>>>> * The output of "ipa user-show --all --raw" is also identical at >>>>>>>> those same steps. >>>>>>>> >>>>>>>> So something, somewhere, is being saved in a way that prevents the >>>>>>>> webui from displaying them properly, that gets fixed when those values >>>>>>>> are manually changed via the webui. >>>>>>>> >>>>>>>> On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Even more interesting... >>>>>>>>> >>>>>>>>> I tried to modify one of the records that was not displaying properly >>>>>>>>> in the "active users" group, and sure enough the webui complained that >>>>>>>>> the "Requested By" (relabeled "manager") field was not filled in since >>>>>>>>> it was blank. It also, however, complained that the "User tier" >>>>>>>>> (relabeled "employeetype") was incorrect, even though it showed the >>>>>>>>> label associated with the value 1. I clicked the search drop-down for >>>>>>>>> manager, typed in my own uid, and even though everything had been >>>>>>>>> blank in the drop down before now my uid showed up. I clicked on it, >>>>>>>>> and my uid was now in the manager field. I then clicked the drop down >>>>>>>>> for employeetype, and chose one of the other options. I was now able >>>>>>>>> to save the changes to the record. >>>>>>>>> >>>>>>>>> Upon reloading the page, the "Employee Information" facet now shoed up >>>>>>>>> on the right side bottom, instead of the left side bottom where it was >>>>>>>>> appearing. I was also now able to change the drop-down fields for >>>>>>>>> manager and employeetype to another value, and save them, and they >>>>>>>>> worked fine even filling in all the data that should have been there. >>>>>>>>> This almost seemed like the data being returned by the server was >>>>>>>>> flawed somehow, and confusing the webui, but once it was forced to >>>>>>>>> have the right data and re-saved it worked fine subsequently. >>>>>>>>> >>>>>>>>> I looked at the output of "ipa user-show --all --raw" both >>>>>>>>> before and after making such changes on a user, and can detect no >>>>>>>>> difference between them. >>>>>>>>> >>>>>>>>> On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On to, 19 tammi 2017, Steve Huston wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> In short, FreeIPA 4.2 -> 4.4 change was by splitting server and >>>>>>>>>>>> client >>>>>>>>>>>> side plugins into different paths (ipaserver/plugins and >>>>>>>>>>>> ipaclient/plugins instead of being common in ipalib/plugins). The >>>>>>>>>>>> client >>>>>>>>>>>> code was also changed to always read metadata about API from the >>>>>>>>>>>> server >>>>>>>>>>>> side. This means the client can adopt to any server version that >>>>>>>>>>>> supports API metadata. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Right, and I think that the most of the plugin I had belongs >>>>>>>>>>> server-side; in fact, that's where I migrated it to, and things work >>>>>>>>>>> fine. I haven't tested if I can change those values with the cli, but >>>>>>>>>>> I'm less concerned about that at the moment. >>>>>>>>>>> >>>>>>>>>>>> In my sample external plugin you referenced above you can see that I >>>>>>>>>>>> have client-side change that replaces an input string by a file >>>>>>>>>>>> reference so that a file can supplied instead of typing the content >>>>>>>>>>>> of >>>>>>>>>>>> the file on the command line. This is one of most used patterns for >>>>>>>>>>>> client side plugins. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In this case, my biggest problem is with the web UI. The 'manager' >>>>>>>>>>> drop down (which I have renamed through the UI plugins to "Requested >>>>>>>>>>> By" to show what user requested and is responsible for this account) >>>>>>>>>>> works fine in the 'add/modify stageuser' context, but not at all in >>>>>>>>>>> the adduser/moduser context, and I can't seem to find out why. >>>>>>>>>> >>>>>>>>>> I'll defer answer for this to our web UI wizards but they would need to >>>>>>>>>> see your code to help, I'd guess. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> / Alexander Bokovoy >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Pavel^3 Vomacka >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>> >>>> >>>> >>>> -- >>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>> >>> >>> >>> -- >>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>> Princeton University | ICBM Address: 40.346344 -74.652242 >>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >> >> >> >> -- >> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >> Princeton University | ICBM Address: 40.346344 -74.652242 >> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' > > > > -- > Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci > Princeton University | ICBM Address: 40.346344 -74.652242 > 345 Lewis Library |"On my ship, the Rocinante, wheeling through > Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, > (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From flo at redhat.com Wed Feb 1 17:05:48 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 1 Feb 2017 18:05:48 +0100 Subject: [Freeipa-users] Backend & UI plugin update for 4.4.x In-Reply-To: References: <20170119161635.56vlybbhvnfn44tc@redhat.com> <20170119181440.x77gboawdyjep7pp@redhat.com> <2e45b170-d467-7bd9-f9fe-efd4fcd4ded8@redhat.com> Message-ID: <2da3b8cd-e1fd-700a-b5b6-0bf5f7586629@redhat.com> On 02/01/2017 05:47 PM, Steve Huston wrote: > Would it be better to file this as a new bug, or reopen 4291? > Hi, we are already aware of the problem and working on a fix (please see https://bugzilla.redhat.com/show_bug.cgi?id=1398600 and https://fedorahosted.org/freeipa/ticket/6575). HTH, Flo. > On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston > wrote: >> Seems like this is to blame: https://fedorahosted.org/freeipa/ticket/4291 >> >> The checkin says, "Installation in pure IPv6 environment failed >> because pki-tomcat tried to use >> IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4 >> fixes this issue." However it would seem that in a pure IPv4 >> environment, this is causing tomcat to fail to load. >> >> On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston >> wrote: >>> What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml? >>> >>> >>> >>> >> address="::1" /> >>> >>> Doesn't work so well on a host without IPv6 turned on... >>> >>> Jan 31 14:26:59 ipa server: PKIListener: >>> org.apache.catalina.core.StandardServer[before_init] >>> Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point >>> associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"] >>> Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family >>> unavailable >>> >>> On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston >>> wrote: >>>> Stranger, I did an install on a different VM with the CentOS 7 minimal >>>> ISO, then installed ipa-server and enough things to get X11 and >>>> Firefox, ran ipa-server-install and it worked fine. I tested with >>>> Firefox (and Safari) against my failing installation and it still >>>> fails. So there's something else different that's causing it to >>>> break. Will continue investigating, but if someone knows why the UI >>>> would break this way it would be helpful to know where to look! >>>> >>>> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston >>>> wrote: >>>>> Just did it again with the same result. Reinstalled the machine, then >>>>> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in >>>>> version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the >>>>> ipa-server-install as I used before, only without --mkhomedir this >>>>> time. After entering the passwords for directory administrator and >>>>> the admin user, I then logged in to the web interface, immediately >>>>> clicked "add" and added a user 'foobar'. When I clicked "add and >>>>> edit" and was brought to the user information page, it looks like this >>>>> at the bottom: >>>>> >>>>> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 >>>>> >>>>> I then entered an employee number of '0001' just to give something to >>>>> save, and clicked save. The screen now shows this (I've clicked the >>>>> drop-down on the manager field so the choices are visible): >>>>> >>>>> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 >>>>> >>>>> Holding shift and clicking reload, the page now looks like this (the >>>>> employee number field is also blank again): >>>>> >>>>> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 >>>>> >>>>> Since we do run a repackaged distribution here (Springdale Linux), I >>>>> just unpacked ipa-server-common from our repository with the above >>>>> version, and http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, >>>>> and 'diff' found zero differences between them. Unlikely, but I >>>>> wanted to rule out a packaging error causing the problem. >>>>> >>>>> On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston >>>>> wrote: >>>>>> No, that should be all of the major changes; the puppet module that >>>>>> installs things only puts the two plugin files in their respective >>>>>> places. The client part of the IPA module makes changes to have the >>>>>> machine join the domain and whatnot, but those shouldn't affect the >>>>>> webui. >>>>>> >>>>>> I do modify the schema by adding some attribute types for Puppet, >>>>>> namely puppetClass, parentNode, environment, puppetVar, and the object >>>>>> class puppetClient. That's basically right from one of the Puppet >>>>>> webpages and also worked in the past - and is one of the things the >>>>>> python plugin does, add the appropriate objectclass to host entries if >>>>>> puppetVar is added to a host entry. >>>>>> >>>>>> My steps to install: >>>>>> * ipa-server-install --realm= --domain= --mkhomedir >>>>>> --hostname= --no-host-dns >>>>>> * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W >>>>>> < paste puppet schema changes> >>>>>> < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a >>>>>> service account used by puppet for adding hosts to IPA > >>>>>> * login to web UI >>>>>> * * Change home directory base, default shell, default SELinux user >>>>>> * * Add SELinux user map for staff/sysadmin users >>>>>> * * Add "user adder" permission/privilege/role for users who will be >>>>>> able to create stageusers >>>>>> >>>>>> That's about as far as I got before I realized some of the plugin >>>>>> pieces weren't working, and then fixed the python plugin followed by >>>>>> working on the UI plugin and finding this problem. I'll go wipe and >>>>>> reinstall the system again and walk through the steps, but test the UI >>>>>> first and in between to see if I can find which of the steps might be >>>>>> causing things to hiccup. >>>>>> >>>>>> On Wed, Jan 25, 2017 at 1:42 PM, Pavel Vomacka wrote: >>>>>>> Hello Steve, >>>>>>> >>>>>>> I tried to reproduce what you described on the very same version of >>>>>>> ipa-server and I was not successful. Actually I was not used your back-end >>>>>>> plugin. I tried it with no plugin and then with your UI plugin and both >>>>>>> worked correctly. Did you do any other changes somewhere in your >>>>>>> installation? >>>>>>> >>>>>>> I will try it again also with your Python plugin and we'll see. >>>>>>> >>>>>>> >>>>>>> On 01/24/2017 08:59 PM, Steve Huston wrote: >>>>>>>> >>>>>>>> And now I'm convinced this has nothing to do with my plugin and >>>>>>>> instead is a bug somewhere in FreeIPA. >>>>>>>> >>>>>>>> I removed the entirety of the "astrocustom" plugin that I wrote, >>>>>>>> restarted httpd, and force reloaded the page in chrome. I clicked to >>>>>>>> add a new user, gave the basic information, and clicked "add and >>>>>>>> edit". The bottom of the page shows the "Employee information" on the >>>>>>>> left side bottom, and the manager drop-down is empty. I entered '1' >>>>>>>> in the "employee type" field and clicked save, and now "Employee >>>>>>>> Information" is on the right side directly under "Contact settings", >>>>>>>> and the manager drop-down is populated with the list of UIDs on the >>>>>>>> system. >>>>>>>> >>>>>>>> When the UI is in the failed state, the "email address" field is also >>>>>>>> blank, but when things switch to how they should be (after submitting >>>>>>>> a change) it is populated with the email address in the record. I >>>>>>>> just tested by adding a telephone number to the record, and that also >>>>>>>> made the contact information and employee information facets refresh >>>>>>>> with the proper data. Pressing shift-reload again makes all the >>>>>>>> information disappear (including the telephone number I just entered). >>>>>>>> >>>>>>>> This is with ipa-server-4.4.0-14.el7_3.4 >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Just tested again, and this is still baffling: >>>>>>>>> >>>>>>>>> * Create a stage user with the right data, works fine, can be edited. >>>>>>>>> * Enable that user, and now the two fields ('manager' and >>>>>>>>> 'employeeType') appear to have bogus data in the UI, and I cannot save >>>>>>>>> the page without changing them to something else. >>>>>>>>> * Once that user is saved, the "Employee Information" facet moves to >>>>>>>>> the right side of the page, and now shows not only the current data in >>>>>>>>> the manager drop down but also the other choices (uids). Change the >>>>>>>>> value of manager and employeetype back to what they were previously >>>>>>>>> and it saves. >>>>>>>>> * An ldapsearch run when the user is first created (as the directory >>>>>>>>> manager), and after having two edits (one to change the values to >>>>>>>>> something else to let the webui save them, and one to change them back >>>>>>>>> to what they should be and were the first time) produce completely >>>>>>>>> identical results. >>>>>>>>> * The output of "ipa user-show --all --raw" is also identical at >>>>>>>>> those same steps. >>>>>>>>> >>>>>>>>> So something, somewhere, is being saved in a way that prevents the >>>>>>>>> webui from displaying them properly, that gets fixed when those values >>>>>>>>> are manually changed via the webui. >>>>>>>>> >>>>>>>>> On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Even more interesting... >>>>>>>>>> >>>>>>>>>> I tried to modify one of the records that was not displaying properly >>>>>>>>>> in the "active users" group, and sure enough the webui complained that >>>>>>>>>> the "Requested By" (relabeled "manager") field was not filled in since >>>>>>>>>> it was blank. It also, however, complained that the "User tier" >>>>>>>>>> (relabeled "employeetype") was incorrect, even though it showed the >>>>>>>>>> label associated with the value 1. I clicked the search drop-down for >>>>>>>>>> manager, typed in my own uid, and even though everything had been >>>>>>>>>> blank in the drop down before now my uid showed up. I clicked on it, >>>>>>>>>> and my uid was now in the manager field. I then clicked the drop down >>>>>>>>>> for employeetype, and chose one of the other options. I was now able >>>>>>>>>> to save the changes to the record. >>>>>>>>>> >>>>>>>>>> Upon reloading the page, the "Employee Information" facet now shoed up >>>>>>>>>> on the right side bottom, instead of the left side bottom where it was >>>>>>>>>> appearing. I was also now able to change the drop-down fields for >>>>>>>>>> manager and employeetype to another value, and save them, and they >>>>>>>>>> worked fine even filling in all the data that should have been there. >>>>>>>>>> This almost seemed like the data being returned by the server was >>>>>>>>>> flawed somehow, and confusing the webui, but once it was forced to >>>>>>>>>> have the right data and re-saved it worked fine subsequently. >>>>>>>>>> >>>>>>>>>> I looked at the output of "ipa user-show --all --raw" both >>>>>>>>>> before and after making such changes on a user, and can detect no >>>>>>>>>> difference between them. >>>>>>>>>> >>>>>>>>>> On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On to, 19 tammi 2017, Steve Huston wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> In short, FreeIPA 4.2 -> 4.4 change was by splitting server and >>>>>>>>>>>>> client >>>>>>>>>>>>> side plugins into different paths (ipaserver/plugins and >>>>>>>>>>>>> ipaclient/plugins instead of being common in ipalib/plugins). The >>>>>>>>>>>>> client >>>>>>>>>>>>> code was also changed to always read metadata about API from the >>>>>>>>>>>>> server >>>>>>>>>>>>> side. This means the client can adopt to any server version that >>>>>>>>>>>>> supports API metadata. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Right, and I think that the most of the plugin I had belongs >>>>>>>>>>>> server-side; in fact, that's where I migrated it to, and things work >>>>>>>>>>>> fine. I haven't tested if I can change those values with the cli, but >>>>>>>>>>>> I'm less concerned about that at the moment. >>>>>>>>>>>> >>>>>>>>>>>>> In my sample external plugin you referenced above you can see that I >>>>>>>>>>>>> have client-side change that replaces an input string by a file >>>>>>>>>>>>> reference so that a file can supplied instead of typing the content >>>>>>>>>>>>> of >>>>>>>>>>>>> the file on the command line. This is one of most used patterns for >>>>>>>>>>>>> client side plugins. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In this case, my biggest problem is with the web UI. The 'manager' >>>>>>>>>>>> drop down (which I have renamed through the UI plugins to "Requested >>>>>>>>>>>> By" to show what user requested and is responsible for this account) >>>>>>>>>>>> works fine in the 'add/modify stageuser' context, but not at all in >>>>>>>>>>>> the adduser/moduser context, and I can't seem to find out why. >>>>>>>>>>> >>>>>>>>>>> I'll defer answer for this to our web UI wizards but they would need to >>>>>>>>>>> see your code to help, I'd guess. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>>>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>>>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>>>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Pavel^3 Vomacka >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>>> >>>>> >>>>> >>>>> -- >>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>> >>>> >>>> >>>> -- >>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>> >>> >>> >>> -- >>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>> Princeton University | ICBM Address: 40.346344 -74.652242 >>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >> >> >> >> -- >> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >> Princeton University | ICBM Address: 40.346344 -74.652242 >> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' > > > From huston at astro.princeton.edu Wed Feb 1 17:10:26 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Wed, 1 Feb 2017 12:10:26 -0500 Subject: [Freeipa-users] Backend & UI plugin update for 4.4.x In-Reply-To: <2da3b8cd-e1fd-700a-b5b6-0bf5f7586629@redhat.com> References: <20170119161635.56vlybbhvnfn44tc@redhat.com> <20170119181440.x77gboawdyjep7pp@redhat.com> <2e45b170-d467-7bd9-f9fe-efd4fcd4ded8@redhat.com> <2da3b8cd-e1fd-700a-b5b6-0bf5f7586629@redhat.com> Message-ID: Awesome! Thank you. On Wed, Feb 1, 2017 at 12:05 PM, Florence Blanc-Renaud wrote: > On 02/01/2017 05:47 PM, Steve Huston wrote: >> >> Would it be better to file this as a new bug, or reopen 4291? >> > Hi, > > we are already aware of the problem and working on a fix (please see > https://bugzilla.redhat.com/show_bug.cgi?id=1398600 and > https://fedorahosted.org/freeipa/ticket/6575). > > HTH, > Flo. > > >> On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston >> wrote: >>> >>> Seems like this is to blame: >>> https://fedorahosted.org/freeipa/ticket/4291 >>> >>> The checkin says, "Installation in pure IPv6 environment failed >>> because pki-tomcat tried to use >>> IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4 >>> fixes this issue." However it would seem that in a pure IPv4 >>> environment, this is causing tomcat to fail to load. >>> >>> On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston >>> wrote: >>>> >>>> What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml? >>>> >>>> >>>> >>>> >>> address="::1" /> >>>> >>>> Doesn't work so well on a host without IPv6 turned on... >>>> >>>> Jan 31 14:26:59 ipa server: PKIListener: >>>> org.apache.catalina.core.StandardServer[before_init] >>>> Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point >>>> associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"] >>>> Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family >>>> unavailable >>>> >>>> On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston >>>> wrote: >>>>> >>>>> Stranger, I did an install on a different VM with the CentOS 7 minimal >>>>> ISO, then installed ipa-server and enough things to get X11 and >>>>> Firefox, ran ipa-server-install and it worked fine. I tested with >>>>> Firefox (and Safari) against my failing installation and it still >>>>> fails. So there's something else different that's causing it to >>>>> break. Will continue investigating, but if someone knows why the UI >>>>> would break this way it would be helpful to know where to look! >>>>> >>>>> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston >>>>> wrote: >>>>>> >>>>>> Just did it again with the same result. Reinstalled the machine, then >>>>>> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in >>>>>> version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the >>>>>> ipa-server-install as I used before, only without --mkhomedir this >>>>>> time. After entering the passwords for directory administrator and >>>>>> the admin user, I then logged in to the web interface, immediately >>>>>> clicked "add" and added a user 'foobar'. When I clicked "add and >>>>>> edit" and was brought to the user information page, it looks like this >>>>>> at the bottom: >>>>>> >>>>>> >>>>>> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 >>>>>> >>>>>> I then entered an employee number of '0001' just to give something to >>>>>> save, and clicked save. The screen now shows this (I've clicked the >>>>>> drop-down on the manager field so the choices are visible): >>>>>> >>>>>> >>>>>> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 >>>>>> >>>>>> Holding shift and clicking reload, the page now looks like this (the >>>>>> employee number field is also blank again): >>>>>> >>>>>> >>>>>> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 >>>>>> >>>>>> Since we do run a repackaged distribution here (Springdale Linux), I >>>>>> just unpacked ipa-server-common from our repository with the above >>>>>> version, and >>>>>> http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, >>>>>> and 'diff' found zero differences between them. Unlikely, but I >>>>>> wanted to rule out a packaging error causing the problem. >>>>>> >>>>>> On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston >>>>>> wrote: >>>>>>> >>>>>>> No, that should be all of the major changes; the puppet module that >>>>>>> installs things only puts the two plugin files in their respective >>>>>>> places. The client part of the IPA module makes changes to have the >>>>>>> machine join the domain and whatnot, but those shouldn't affect the >>>>>>> webui. >>>>>>> >>>>>>> I do modify the schema by adding some attribute types for Puppet, >>>>>>> namely puppetClass, parentNode, environment, puppetVar, and the >>>>>>> object >>>>>>> class puppetClient. That's basically right from one of the Puppet >>>>>>> webpages and also worked in the past - and is one of the things the >>>>>>> python plugin does, add the appropriate objectclass to host entries >>>>>>> if >>>>>>> puppetVar is added to a host entry. >>>>>>> >>>>>>> My steps to install: >>>>>>> * ipa-server-install --realm= --domain= --mkhomedir >>>>>>> --hostname= --no-host-dns >>>>>>> * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W >>>>>>> < paste puppet schema changes> >>>>>>> < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a >>>>>>> service account used by puppet for adding hosts to IPA > >>>>>>> * login to web UI >>>>>>> * * Change home directory base, default shell, default SELinux user >>>>>>> * * Add SELinux user map for staff/sysadmin users >>>>>>> * * Add "user adder" permission/privilege/role for users who will be >>>>>>> able to create stageusers >>>>>>> >>>>>>> That's about as far as I got before I realized some of the plugin >>>>>>> pieces weren't working, and then fixed the python plugin followed by >>>>>>> working on the UI plugin and finding this problem. I'll go wipe and >>>>>>> reinstall the system again and walk through the steps, but test the >>>>>>> UI >>>>>>> first and in between to see if I can find which of the steps might be >>>>>>> causing things to hiccup. >>>>>>> >>>>>>> On Wed, Jan 25, 2017 at 1:42 PM, Pavel Vomacka >>>>>>> wrote: >>>>>>>> >>>>>>>> Hello Steve, >>>>>>>> >>>>>>>> I tried to reproduce what you described on the very same version of >>>>>>>> ipa-server and I was not successful. Actually I was not used your >>>>>>>> back-end >>>>>>>> plugin. I tried it with no plugin and then with your UI plugin and >>>>>>>> both >>>>>>>> worked correctly. Did you do any other changes somewhere in your >>>>>>>> installation? >>>>>>>> >>>>>>>> I will try it again also with your Python plugin and we'll see. >>>>>>>> >>>>>>>> >>>>>>>> On 01/24/2017 08:59 PM, Steve Huston wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> And now I'm convinced this has nothing to do with my plugin and >>>>>>>>> instead is a bug somewhere in FreeIPA. >>>>>>>>> >>>>>>>>> I removed the entirety of the "astrocustom" plugin that I wrote, >>>>>>>>> restarted httpd, and force reloaded the page in chrome. I clicked >>>>>>>>> to >>>>>>>>> add a new user, gave the basic information, and clicked "add and >>>>>>>>> edit". The bottom of the page shows the "Employee information" on >>>>>>>>> the >>>>>>>>> left side bottom, and the manager drop-down is empty. I entered >>>>>>>>> '1' >>>>>>>>> in the "employee type" field and clicked save, and now "Employee >>>>>>>>> Information" is on the right side directly under "Contact >>>>>>>>> settings", >>>>>>>>> and the manager drop-down is populated with the list of UIDs on the >>>>>>>>> system. >>>>>>>>> >>>>>>>>> When the UI is in the failed state, the "email address" field is >>>>>>>>> also >>>>>>>>> blank, but when things switch to how they should be (after >>>>>>>>> submitting >>>>>>>>> a change) it is populated with the email address in the record. I >>>>>>>>> just tested by adding a telephone number to the record, and that >>>>>>>>> also >>>>>>>>> made the contact information and employee information facets >>>>>>>>> refresh >>>>>>>>> with the proper data. Pressing shift-reload again makes all the >>>>>>>>> information disappear (including the telephone number I just >>>>>>>>> entered). >>>>>>>>> >>>>>>>>> This is with ipa-server-4.4.0-14.el7_3.4 >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just tested again, and this is still baffling: >>>>>>>>>> >>>>>>>>>> * Create a stage user with the right data, works fine, can be >>>>>>>>>> edited. >>>>>>>>>> * Enable that user, and now the two fields ('manager' and >>>>>>>>>> 'employeeType') appear to have bogus data in the UI, and I cannot >>>>>>>>>> save >>>>>>>>>> the page without changing them to something else. >>>>>>>>>> * Once that user is saved, the "Employee Information" facet moves >>>>>>>>>> to >>>>>>>>>> the right side of the page, and now shows not only the current >>>>>>>>>> data in >>>>>>>>>> the manager drop down but also the other choices (uids). Change >>>>>>>>>> the >>>>>>>>>> value of manager and employeetype back to what they were >>>>>>>>>> previously >>>>>>>>>> and it saves. >>>>>>>>>> * An ldapsearch run when the user is first created (as the >>>>>>>>>> directory >>>>>>>>>> manager), and after having two edits (one to change the values to >>>>>>>>>> something else to let the webui save them, and one to change them >>>>>>>>>> back >>>>>>>>>> to what they should be and were the first time) produce completely >>>>>>>>>> identical results. >>>>>>>>>> * The output of "ipa user-show --all --raw" is also >>>>>>>>>> identical at >>>>>>>>>> those same steps. >>>>>>>>>> >>>>>>>>>> So something, somewhere, is being saved in a way that prevents the >>>>>>>>>> webui from displaying them properly, that gets fixed when those >>>>>>>>>> values >>>>>>>>>> are manually changed via the webui. >>>>>>>>>> >>>>>>>>>> On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Even more interesting... >>>>>>>>>>> >>>>>>>>>>> I tried to modify one of the records that was not displaying >>>>>>>>>>> properly >>>>>>>>>>> in the "active users" group, and sure enough the webui complained >>>>>>>>>>> that >>>>>>>>>>> the "Requested By" (relabeled "manager") field was not filled in >>>>>>>>>>> since >>>>>>>>>>> it was blank. It also, however, complained that the "User tier" >>>>>>>>>>> (relabeled "employeetype") was incorrect, even though it showed >>>>>>>>>>> the >>>>>>>>>>> label associated with the value 1. I clicked the search >>>>>>>>>>> drop-down for >>>>>>>>>>> manager, typed in my own uid, and even though everything had been >>>>>>>>>>> blank in the drop down before now my uid showed up. I clicked on >>>>>>>>>>> it, >>>>>>>>>>> and my uid was now in the manager field. I then clicked the drop >>>>>>>>>>> down >>>>>>>>>>> for employeetype, and chose one of the other options. I was now >>>>>>>>>>> able >>>>>>>>>>> to save the changes to the record. >>>>>>>>>>> >>>>>>>>>>> Upon reloading the page, the "Employee Information" facet now >>>>>>>>>>> shoed up >>>>>>>>>>> on the right side bottom, instead of the left side bottom where >>>>>>>>>>> it was >>>>>>>>>>> appearing. I was also now able to change the drop-down fields >>>>>>>>>>> for >>>>>>>>>>> manager and employeetype to another value, and save them, and >>>>>>>>>>> they >>>>>>>>>>> worked fine even filling in all the data that should have been >>>>>>>>>>> there. >>>>>>>>>>> This almost seemed like the data being returned by the server was >>>>>>>>>>> flawed somehow, and confusing the webui, but once it was forced >>>>>>>>>>> to >>>>>>>>>>> have the right data and re-saved it worked fine subsequently. >>>>>>>>>>> >>>>>>>>>>> I looked at the output of "ipa user-show --all --raw" both >>>>>>>>>>> before and after making such changes on a user, and can detect no >>>>>>>>>>> difference between them. >>>>>>>>>>> >>>>>>>>>>> On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On to, 19 tammi 2017, Steve Huston wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In short, FreeIPA 4.2 -> 4.4 change was by splitting server >>>>>>>>>>>>>> and >>>>>>>>>>>>>> client >>>>>>>>>>>>>> side plugins into different paths (ipaserver/plugins and >>>>>>>>>>>>>> ipaclient/plugins instead of being common in ipalib/plugins). >>>>>>>>>>>>>> The >>>>>>>>>>>>>> client >>>>>>>>>>>>>> code was also changed to always read metadata about API from >>>>>>>>>>>>>> the >>>>>>>>>>>>>> server >>>>>>>>>>>>>> side. This means the client can adopt to any server version >>>>>>>>>>>>>> that >>>>>>>>>>>>>> supports API metadata. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Right, and I think that the most of the plugin I had belongs >>>>>>>>>>>>> server-side; in fact, that's where I migrated it to, and things >>>>>>>>>>>>> work >>>>>>>>>>>>> fine. I haven't tested if I can change those values with the >>>>>>>>>>>>> cli, but >>>>>>>>>>>>> I'm less concerned about that at the moment. >>>>>>>>>>>>> >>>>>>>>>>>>>> In my sample external plugin you referenced above you can see >>>>>>>>>>>>>> that I >>>>>>>>>>>>>> have client-side change that replaces an input string by a >>>>>>>>>>>>>> file >>>>>>>>>>>>>> reference so that a file can supplied instead of typing the >>>>>>>>>>>>>> content >>>>>>>>>>>>>> of >>>>>>>>>>>>>> the file on the command line. This is one of most used >>>>>>>>>>>>>> patterns for >>>>>>>>>>>>>> client side plugins. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> In this case, my biggest problem is with the web UI. The >>>>>>>>>>>>> 'manager' >>>>>>>>>>>>> drop down (which I have renamed through the UI plugins to >>>>>>>>>>>>> "Requested >>>>>>>>>>>>> By" to show what user requested and is responsible for this >>>>>>>>>>>>> account) >>>>>>>>>>>>> works fine in the 'add/modify stageuser' context, but not at >>>>>>>>>>>>> all in >>>>>>>>>>>>> the adduser/moduser context, and I can't seem to find out why. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'll defer answer for this to our web UI wizards but they would >>>>>>>>>>>> need to >>>>>>>>>>>> see your code to help, I'd guess. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & >>>>>>>>>>> Astrophysical Sci >>>>>>>>>>> Princeton University | ICBM Address: 40.346344 >>>>>>>>>>> -74.652242 >>>>>>>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling >>>>>>>>>>> through >>>>>>>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of >>>>>>>>>>> Cygnus, >>>>>>>>>>> (267) 793-0852 | headlong into mystery." -Rush, >>>>>>>>>>> 'Cygnus X-1' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical >>>>>>>>>> Sci >>>>>>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling >>>>>>>>>> through >>>>>>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of >>>>>>>>>> Cygnus, >>>>>>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus >>>>>>>>>> X-1' >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Pavel^3 Vomacka >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical >>>>>>> Sci >>>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of >>>>>>> Cygnus, >>>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus >>>>>>> X-1' >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of >>>>>> Cygnus, >>>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>>> >>>> >>>> >>>> >>>> -- >>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>>> Princeton University | ICBM Address: 40.346344 -74.652242 >>>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >>> >>> >>> >>> >>> -- >>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci >>> Princeton University | ICBM Address: 40.346344 -74.652242 >>> 345 Lewis Library |"On my ship, the Rocinante, wheeling through >>> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, >>> (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' >> >> >> >> > -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From deepak.dimri2016 at gmail.com Wed Feb 1 17:22:02 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Wed, 1 Feb 2017 22:52:02 +0530 Subject: [Freeipa-users] Gateway_timeout Error In-Reply-To: References: <215e3abb-4137-d311-ea8c-dca541664178@redhat.com> Message-ID: sorry for not replying to all! I have apache reverse proxy front ending the ipa servers. As i mentioned if i try hitting ipa replica WebUI directly then i do get the objects loaded on the browser after waiting for over a minute or so. replica server (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}) shows hits coming through fine but for some reasons web browser ends up with the gateway error. both the ipa masters are running VERSION: 4.4.0, API_VERSION: 2.213 Kind Regards, Deepak On Wed, Feb 1, 2017 at 9:21 PM, Martin Babinsky wrote: > On 02/01/2017 04:26 PM, deepak dimri wrote: > >> Yes, Martin - i do see requests hitting >> replica.. /var/log/httpd/error_log shows: >> >> [Wed Feb 01 15:16:47.469766 2017] [:error] [pid 2464] ipa: INFO: >> admin at XXX.XYZ.COM : batch: >> host_show(u'xxx.abx.xyz ', rights=True, all=True): >> SUCCESS >> >> I used ansible playbook to build the replica server. ran >> ipa-replica-prepare on the primary: >> ipa-replica-prepare {{ replica_dns }} --password={{ipa_password}} >> --no-wait-for-dns >> >> copied the replica file over to replica server: >> scp -oStrictHostKeyChecking=no -i ~/.ssh/{{ssh_keyname}}.pem >> /var/lib/ipa/replica-info-{{ replica_dns }}.gpg root@{{ >> replica_dns }}:/var/lib/ipa/ >> >> ran the replica install on the replica server: >> ipa-replica-install /var/lib/ipa/replica-info-{{ replica_dns }}.gpg >> --password={{ipa_password}} --admin-password={{ipa_password}} >> >> I have notices that if i directly use the replica (bypassing proxy) URL >> then the objects shows after waiting for over a minute or so. When i use >> proxy pass then it just times out after few seconds. >> >> No clue why its behaving like this >> >> Many Thanks, >> Deepak >> >> On Wed, Feb 1, 2017 at 6:45 PM, Martin Babinsky > > wrote: >> >> On 02/01/2017 11:17 AM, deepak dimri wrote: >> >> Hello Martin, Thank you so much for your reply. >> >> I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary >> server and >> its pointing to its own hostname and not to primary server >> hostname :( >> >> any other clue, Martin? >> >> I have tried without proxy and again to luck either its throwing >> same >> gateway_error >> >> Regards, >> Deepak >> >> On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky >> >> >> wrote: >> >> On 02/01/2017 10:22 AM, deepak dimri wrote: >> >> Hi All, >> >> I have two IPA servers - primary and secondary running. >> the >> secondary >> ipa server is installed using ipa replica image of >> primary. >> While doing >> the testing i realised that when i manually shut down my >> primary ipa >> server making my secondary server to serve the UI. And >> now when >> i try to >> access user or hosts details using my secondary server >> then i am >> getting >> below error in the UI. I am able to login fine though; it >> is >> just that >> when i double click on host objects then i get the error. >> >> >> An error has occurred (GATEWAY_TIMEOUT) >> >> >> I am still trying to troubleshoot as why i am getting >> timeout >> error but >> thought of asking the group here to see if some one can >> share >> some pointers >> >> Many Thanks, >> Deepak >> >> >> Hi Deepak, >> >> please check /etc/ipa/default.conf on the secondary server >> and check >> the value of 'xmlrpc_uri'. Maybe it points to the URL of >> primary >> server and that's why you get timeouts when it is down. >> >> Re-setting it to the secondary server itself should fix it. >> >> -- >> Martin^3 Babinsky >> >> -- >> 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 >> >> >> >> Adding freeipa-users back to loop. >> >> That is strange, how did you stand up the replica? >> >> You can also inspect /var/log/http/error_log on the replica to see >> whether the commands from the WebUI reach the local HTTP server at >> all. >> >> -- >> Martin^3 Babinsky >> >> >> > Deepak, > > please keep replying to freeipa-users mailing list, otherwise other > members do not get updates on your problem. > > As for the issues with replica, I did not notice before that you are > connecting to WebUI through a proxy, what kind of proxy is that and how is > it configured? > > Nevertheless waiting for over a minute to display entries does not sound > right. I would investigate the root cause of this performance regression by > checking DS access and error logs on the replica > (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}). > > Does the master also take so long time to respond? What are the IPA > versions of master/replica? > > -- > Martin^3 Babinsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dag at sonsorol.org Wed Feb 1 17:29:37 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 01 Feb 2017 12:29:37 -0500 Subject: [Freeipa-users] guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error Message-ID: <58921B01.4060107@sonsorol.org> Hi folks, I've posted here and gotten amazing help on our odd setup with IPA having a 1-way trust to a massive remote AD forest with 90+ domain controllers and lots of child domains. I'm running into a strange issue where I can resolve and manage users in child domain (NAFTA.COMPANY.ORG) but I am getting failures and just discovered an interesting error that relates to resolving a user in the EAME.COMPANY.ORG forrest. However I've also been dragged down the rabbit hole tracking down errors that turned out to be meaningless so I figured my 1st question will be "is this the error should I be focusing on?" This is my situation: 1. "id user at NAFTA.COMPANY.ORG" works perfectly fine - no issues at all with RBAC, sudo and hosting SSH keys etc. 2. "id user at EAME.COMPANY.ORG" fails with "no such user" 3. We did not configure any specific SID-UID mapping rules in sssd.conf as we had assumed we'd use the "default" behavior After digging through the logs I found this which seems VERY clear about the root cause: (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=u474418 at eame.company.org] (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_idmap_sid_to_unix] (0x0040): Object SID [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger than the ldap_idmap_range_size. See the "ID MAPPING? section of sssd-ad(5) for an explanation of how to resolve this issue. (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user] (0x0020): Failed to save user [u474418 at eame.company.org] (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users] (0x0040): Failed to store user 0. Ignoring. The error about "Object SID has a RID that is larger than ldap_idmap_range_size .." seems pretty clear. I don't think this is a 'rabbit hole' message - this seems like a real config problem on my end. The problem is that I'm not quite sure what I should configure to resolve this. The man page for sssd-ad covers the topic but does not cover recommended configuration options. Questions for this list: 1) Confirm that the "SID has an RID that is larger ..." error is real and worth chasing down ? 2) My understanding was that by default SSSD will hash SIDs and come up with unique UID and GID ranges that will be consistent across any machine bound to the same IDM mechanism. So I've not configured anything specific related to SID-to-UID mapping as we wanted to go with the default behavior used by SSSD. Obviously the default is not working and I've got to make a change. I just don't know what the recommended change should be. Help appreciated! Config file details are below. Regards, Chris This is the sssd/sssd.conf file on the IPA server: ###---------------------- [domain/companyidm.org] ldap_user_principal = nosuchattr subdomain_inherit = ldap_user_principal debug_level = 5 krb5_validate = True cache_credentials = True krb5_store_password_if_offline = True ipa_domain = companyidm.org id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = usaeilidmp001.companyidm.org chpass_provider = ipa ipa_server = usaeilidmp001.companyidm.org ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = companyidm.org [nss] memcache_timeout = 600 homedir_substring = /home [pam] debug_level = 5 [sudo] [autofs] [ssh] debug_level = 5 [pac] [ifp] ###---------------------- This is krb5.conf which handles the child domain and trust things ... [capaths] COMPANYAWS.ORG = { COMPANYIDM.ORG = COMPANYAWS.ORG } COMPANYIDM.ORG = { COMPANYAWS.ORG = COMPANYAWS.ORG SYNGENTA.ORG = COMPANY.ORG EAME.COMPANY.ORG = SYNGENTA.ORG APAC.COMPANY.ORG = SYNGENTA.ORG LATAM.COMPANY.ORG = SYNGENTA.ORG NAFTA.COMPANY.ORG = SYNGENTA.ORG } COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } EAME.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } APAC.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } LATAM.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } NAFTA.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = COMPANYIDM.ORG dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] COMPANYIDM.ORG = { kdc = usaeilidmp001.companyidm.org:88 master_kdc = usaeilidmp001.companyidm.org:88 admin_server = usaeilidmp001.companyidm.org:749 default_domain = syngentaidm.org pkinit_anchors = FILE:/etccompanyidmipa/ca.crt } [dbmodules] COMPANYIDM.ORG = { db_library = ipadb.so } From peljasz at yahoo.co.uk Wed Feb 1 18:30:58 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 1 Feb 2017 18:30:58 +0000 Subject: [Freeipa-users] unable to delete a user - which has a double?? Message-ID: hi all, take a look: $ ipa user-find --uid 3501 -------------- 1 user matched -------------- User login: appmgr First name: app Last name: developer Home directory: /home.sysops/appmgr Login shell: /bin/bash Principal alias: appmgr at PRIVATE Email address: appmgr at private UID: 3501 GID: 3501 Account disabled: False $ ipa user-find --uid 1104 -------------- 1 user matched -------------- User login: appmgr First name: app Last name: devel 1 Home directory: /home.sysops/appmgr Login shell: /bin/bash Principal alias: appmgr at PRIVATE Email address: appmgr at private UID: 1104 GID: 1104 Account disabled: False ---------------------------- Number of entries returned 1 ---------------------------- I think it had something to do with an initial(long time ago) migration. How to safely delete such a user? Or one of them? $ ipa user-del appmgr --no-preserve ipa: ERROR: The search criteria was not specific enough. Expected 1 and found 2. many thanks, L. From mbasti at redhat.com Wed Feb 1 19:16:16 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 1 Feb 2017 20:16:16 +0100 Subject: [Freeipa-users] unable to delete a user - which has a double?? In-Reply-To: References: Message-ID: <8566438d-593f-cc46-9525-3ab78fde0466@redhat.com> Hello, you have to use ldapdelete command and remove it manually Martin On 01.02.2017 19:30, lejeczek wrote: > hi all, > take a look: > > $ ipa user-find --uid 3501 > -------------- > 1 user matched > -------------- > User login: appmgr > First name: app > Last name: developer > Home directory: /home.sysops/appmgr > Login shell: /bin/bash > Principal alias: appmgr at PRIVATE > Email address: appmgr at private > UID: 3501 > GID: 3501 > Account disabled: False > > $ ipa user-find --uid 1104 > -------------- > 1 user matched > -------------- > User login: appmgr > First name: app > Last name: devel 1 > Home directory: /home.sysops/appmgr > Login shell: /bin/bash > Principal alias: appmgr at PRIVATE > Email address: appmgr at private > UID: 1104 > GID: 1104 > Account disabled: False > ---------------------------- > Number of entries returned 1 > ---------------------------- > > I think it had something to do with an initial(long time ago) migration. > How to safely delete such a user? Or one of them? > > $ ipa user-del appmgr --no-preserve > ipa: ERROR: The search criteria was not specific enough. Expected 1 > and found 2. > > many thanks, > L. > From dag at sonsorol.org Wed Feb 1 19:41:35 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 01 Feb 2017 14:41:35 -0500 Subject: [Freeipa-users] [SOLVED] Re: guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error Message-ID: <589239EF.8030201@sonsorol.org> Update: Resolved. A bit of googling led me to some good RHEL pages as well as mailing list messages from Alex B that were concise and helpful. To summarize for others who may have this problem: 1. Don't make changes to sssd.conf if your provider is "ipa" - in this case you work only with "ipa idrange-mod" type commands or webUI 2. The simple solution is to increase the range and restart SSSD after blowing away out of date sssd database: # ipa idrange-mod --base-id=4000000 --range-size=1000000 EAME.COMPANY.ORG_id_range # service sssd stop; rm -f /var/lib/sss/db/*; service sssd start What I actually did on our IPA server was a bit more expansive. EAME was the first child domain where I had the SID to UID map issue but it would probably not have been the only one so I figured it would be safer to make sure that every child domain range had at least 1 million available IDs Using the IPA webUI under "IPA Server" -> "ID Ranges" -> "Range Name" I went through every single AD child domain and manually reconfigured both the "First Posix ID of the range" as well as "Number of IDs in the range" so we have at least 1,000,000 ID options in each child domain range: APAC.COMPANY.ORG 1st-Posix=1800000000 Ids-in-range: 1000000 EAME.COMPANY.ORG 1st-Posix=1810000000 Ids-in-range: 1000000 LATAM.COMPANY.ORG 1st-Posix=1820000000 Ids-in-range: 1000000 NAFTA.COMPANY.ORG 1st-Posix=1830000000 Ids-in-range: 1000000 We are still in testing mode with less than 6 users logging in via IDM identities at the moment so it was not disruptive to make this sort of core change. -Chris Chris Dagdigian wrote: > Hi folks, > > I've posted here and gotten amazing help on our odd setup with IPA > having a 1-way trust to a massive remote AD forest with 90+ domain > controllers and lots of child domains. > > I'm running into a strange issue where I can resolve and manage users > in child domain (NAFTA.COMPANY.ORG) but I am getting failures and just > discovered an interesting error that relates to resolving a user in > the EAME.COMPANY.ORG forrest. > > However I've also been dragged down the rabbit hole tracking down > errors that turned out to be meaningless so I figured my 1st question > will be "is this the error should I be focusing on?" > > This is my situation: > > 1. "id user at NAFTA.COMPANY.ORG" works perfectly fine - no issues at all > with RBAC, sudo and hosting SSH keys etc. > > 2. "id user at EAME.COMPANY.ORG" fails with "no such user" > > 3. We did not configure any specific SID-UID mapping rules in > sssd.conf as we had assumed we'd use the "default" behavior > > > After digging through the logs I found this which seems VERY clear > about the root cause: > > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > [dp_get_account_info_handler] (0x0200): Got request for > [0x1][BE_REQ_USER][1][name=u474418 at eame.company.org] > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > [sdap_idmap_sid_to_unix] (0x0040): Object SID > [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is > larger than the ldap_idmap_range_size. See the "ID MAPPING? section of > sssd-ad(5) for an explanation of how to resolve this issue. > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID > [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user] > (0x0020): Failed to save user [u474418 at eame.company.org] > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users] > (0x0040): Failed to store user 0. Ignoring. > > > The error about "Object SID has a RID that is larger than > ldap_idmap_range_size .." seems pretty clear. I don't think this is a > 'rabbit hole' message - this seems like a real config problem on my end. > > The problem is that I'm not quite sure what I should configure to > resolve this. The man page for sssd-ad covers the topic but does not > cover recommended configuration options. > > > Questions for this list: > > 1) Confirm that the "SID has an RID that is larger ..." error is real > and worth chasing down ? > > 2) My understanding was that by default SSSD will hash SIDs and come > up with unique UID and GID ranges that will be consistent across any > machine bound to the same IDM mechanism. So I've not configured > anything specific related to SID-to-UID mapping as we wanted to go > with the default behavior used by SSSD. Obviously the default is not > working and I've got to make a change. I just don't know what the > recommended change should be. Help appreciated! > > > > Config file details are below. > > > Regards, > Chris > > > > > > This is the sssd/sssd.conf file on the IPA server: > > ###---------------------- > > [domain/companyidm.org] > ldap_user_principal = nosuchattr > subdomain_inherit = ldap_user_principal > debug_level = 5 > krb5_validate = True > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = companyidm.org > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = usaeilidmp001.companyidm.org > chpass_provider = ipa > ipa_server = usaeilidmp001.companyidm.org > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > > domains = companyidm.org > [nss] > memcache_timeout = 600 > homedir_substring = /home > > [pam] > debug_level = 5 > [sudo] > > [autofs] > > [ssh] > debug_level = 5 > > [pac] > > [ifp] > > ###---------------------- > > > This is krb5.conf which handles the child domain and trust things ... > > [capaths] > COMPANYAWS.ORG = { > COMPANYIDM.ORG = COMPANYAWS.ORG > } > COMPANYIDM.ORG = { > COMPANYAWS.ORG = COMPANYAWS.ORG > SYNGENTA.ORG = COMPANY.ORG > EAME.COMPANY.ORG = SYNGENTA.ORG > APAC.COMPANY.ORG = SYNGENTA.ORG > LATAM.COMPANY.ORG = SYNGENTA.ORG > NAFTA.COMPANY.ORG = SYNGENTA.ORG > } > COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > EAME.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > APAC.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > LATAM.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > NAFTA.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > default_realm = COMPANYIDM.ORG > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > COMPANYIDM.ORG = { > kdc = usaeilidmp001.companyidm.org:88 > master_kdc = usaeilidmp001.companyidm.org:88 > admin_server = usaeilidmp001.companyidm.org:749 > default_domain = syngentaidm.org > pkinit_anchors = FILE:/etccompanyidmipa/ca.crt > } > > [dbmodules] > COMPANYIDM.ORG = { > db_library = ipadb.so > } > > > > From jochen at jochen.org Wed Feb 1 19:12:20 2017 From: jochen at jochen.org (Jochen Hein) Date: Wed, 01 Feb 2017 20:12:20 +0100 Subject: [Freeipa-users] unable to delete a user - which has a double?? In-Reply-To: (lejeczek's message of "Wed, 1 Feb 2017 18:30:58 +0000") References: Message-ID: <83zii5wwrv.fsf@jochen.org> Hi lejeczek writes: > I think it had something to do with an initial(long time ago) > migration. > How to safely delete such a user? Or one of them? > > $ ipa user-del appmgr --no-preserve > ipa: ERROR: The search criteria was not specific enough. Expected 1 > and found 2. Did you try "--continue"? You can check both users with "ipa user-find ... --all" and look for the ipauniqueid. I think you'll can remove the user with ldapremove. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From christophe.trefois at uni.lu Wed Feb 1 20:37:56 2017 From: christophe.trefois at uni.lu (Christophe TREFOIS) Date: Wed, 1 Feb 2017 20:37:56 +0000 Subject: [Freeipa-users] Replica FQDN / Domain question In-Reply-To: References: <1646193A-C60C-4D85-9306-881D5F2ED56C@uni.lu>, Message-ID: <8D09A5EC-43ED-4A45-AFA4-2FFF1A6CD0CC@uni.lu> Hi Martin, Thanks for the reply! That's the plan. As we can't really change REALM easily or as it's not recommended, we have to unfortunately drag this "issue" with us. This by the way, leads us to not being able to setup SRV records as we collide with an AD in the same organisation. Real shame realm can't be changed somehow. For now, no failover for us. Kind regards, Christophe Sent from my iPhone On 1 Feb 2017, at 14:18, Martin Basti > wrote: On 01.02.2017 14:06, Christophe TREFOIS wrote: Hi all, Small question which might be naive. We have an existing setup with 4 replicas, all with FQDNs like replica1.example.com and REALM example.com. We want to add another replica, replica5, whose FQDN would have a different domain, so say replica5.example.org. The DNS would be resolvable as it would be managed by the same DNS server (outside of our control). We don?t think this should have any impact. Is this a fair assumption? We just want to make sure. Kind regards, Christophe It should work, but keep on mind that replica5 will be still part of realm EXAMPLE.COM Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From telekomunikacije at gmail.com Wed Feb 1 20:44:34 2017 From: telekomunikacije at gmail.com (Gorazd) Date: Wed, 1 Feb 2017 21:44:34 +0100 Subject: [Freeipa-users] Dogtag vs Freeipa Dogtag Message-ID: Hello, i am interested if there is any feature matrix available for FreeIpa version of dogtag packaging. So which features of DogTak are not included or does come with limitations when installed with Freeipa (such as OCSP is already part of CA and could not be installed seperately), in contrast when on uses Dogtag as a standlone software installation? Thank you in advance. Regards, Gorazd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Wed Feb 1 21:00:55 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 1 Feb 2017 15:00:55 -0600 (CST) Subject: [Freeipa-users] Is WinSync A Bad Choice? Message-ID: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> Hello everyone, I'm about to deploy a fresh IPA domain that needs to integrate with Active Directory. In my lab environment I've setup a trust with AD and the following items are driving me away from using the trust: - Users can't login to a Linux box using just "username" (user at ad.domain is used) - Since AD trust users don't show up in FreeIPA web UI users can't login to manage their own SSH keys - User/group management in general becomes largely a command-line operation (such as mapping groups so they can be used in HBAC and sudo rules) First, if any of the above is incorrect or there are workarounds I am very much open to discussion. I'm considering using WinSync+PassSync so that users and groups appear as "real" IPA objects to be managed normally. Given that an entire tool has been written to migrate away from WinSync to AD trusts and language in the RH documentation suggesting to only use WinSync if you have to I'm wondering what issues I'm not considering and if I could be leading toward a world of hurt. Guidance in this area is appreciated. Thanks, j From jhrozek at redhat.com Wed Feb 1 21:44:57 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 1 Feb 2017 22:44:57 +0100 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> Message-ID: <20170201214457.cxr45itooxvvivtk@hendrix> On Wed, Feb 01, 2017 at 03:00:55PM -0600, Jason B. Nance wrote: > Hello everyone, > > I'm about to deploy a fresh IPA domain that needs to integrate with Active Directory. In my lab environment I've setup a trust with AD and the following items are driving me away from using the trust: > > - Users can't login to a Linux box using just "username" (user at ad.domain is used) In the current version you can use the 'default_domain_suffix' option in sssd.conf on the clients. In RHEL-7.4 we are looking into making this limitation go away. (I won't reply to the other two questions because they are outside my knowledge domain, sorry) From jason at tresgeek.net Wed Feb 1 22:19:39 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 1 Feb 2017 16:19:39 -0600 (CST) Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: <20170201214457.cxr45itooxvvivtk@hendrix> References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> Message-ID: <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> >> - Users can't login to a Linux box using just "username" (user at ad.domain is >> used) > > In the current version you can use the 'default_domain_suffix' option in > sssd.conf on the clients. In RHEL-7.4 we are looking into making this > limitation go away. Thank you very much, Jakub. That is helpful information! Are you saying that there will basically be a domain search order or something for users that login without specifying a domain? Back to the community as a whole, regarding these other items: > - Since AD trust users don't show up in FreeIPA web UI users can't login to manage their own SSH keys After doing some additional thinking/researching I realized that SSH keys become largely irrelevant because of GSSAPI (Dmitri Pal posed this question in this thread: https://www.redhat.com/archives/freeipa-users/2013-September/msg00290.html). > - User/group management in general becomes largely a command-line operation (such as mapping groups so they can be used in HBAC and sudo rules) While this is a nice-to-have, it isn't a deal breaker. I have another question. Can additional authentication requirements (such as 2FA) be imposed on users from a trust via IPA? Thanks, j From datakid at gmail.com Wed Feb 1 22:44:36 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Thu, 2 Feb 2017 09:44:36 +1100 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> Message-ID: On 2 February 2017 at 09:19, Jason B. Nance wrote: > > - User/group management in general becomes largely a command-line > operation (such as mapping groups so they can be used in HBAC and sudo > rules) > > While this is a nice-to-have, it isn't a deal breaker. > This definitely exists in WebUI? Unless you mean something I don't understand. Define groups: Identity->User Groups (second tab) Define user mappings: IPA Server -> ID Views -> Default Trust View Is that what you mean? (aside: does FreeIPA have plans to move toward PatternFly? http://www.patternfly.org/ ) cheers L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Feb 1 22:51:39 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 1 Feb 2017 23:51:39 +0100 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> Message-ID: <8ef84c22-12b8-f67a-71fc-a85e580e40f9@redhat.com> On 01.02.2017 23:44, Lachlan Musicman wrote: > On 2 February 2017 at 09:19, Jason B. Nance > wrote: > > > - User/group management in general becomes largely a command-line > operation (such as mapping groups so they can be used in HBAC and > sudo rules) > > While this is a nice-to-have, it isn't a deal breaker. > > > This definitely exists in WebUI? Unless you mean something I don't > understand. > > Define groups: > Identity->User Groups (second tab) > > Define user mappings: > IPA Server -> ID Views -> Default Trust View > > Is that what you mean? > > (aside: does FreeIPA have plans to move toward PatternFly? > http://www.patternfly.org/ ) Unless I missed something, FreeIPA 4.x already uses patternfly https://ipa.demo1.freeipa.org/ipa/ui/ admin/Secret123 Martin > > cheers > L. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From datakid at gmail.com Wed Feb 1 23:05:05 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Thu, 2 Feb 2017 10:05:05 +1100 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: <8ef84c22-12b8-f67a-71fc-a85e580e40f9@redhat.com> References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> <8ef84c22-12b8-f67a-71fc-a85e580e40f9@redhat.com> Message-ID: On 2 February 2017 at 09:51, Martin Basti wrote: > > On 01.02.2017 23:44, Lachlan Musicman wrote: > > > > (aside: does FreeIPA have plans to move toward PatternFly? > http://www.patternfly.org/ ) > > > Unless I missed something, FreeIPA 4.x already uses patternfly > > https://ipa.demo1.freeipa.org/ipa/ui/ > admin/Secret123 > > Ah! The thing I am missing is IPA 4.4! (still on 4.2. Upgrade in the planning) cheers L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Wed Feb 1 23:06:22 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 1 Feb 2017 17:06:22 -0600 (CST) Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> Message-ID: <704714061.2918.1485990382476.JavaMail.zimbra@tresgeek.net> >>> - User/group management in general becomes largely a command-line operation >> > (such as mapping groups so they can be used in HBAC and sudo rules) >> While this is a nice-to-have, it isn't a deal breaker. > This definitely exists in WebUI? Unless you mean something I don't understand. > Define groups: > Identity->User Groups (second tab) In my setup (FreeIPA 4.4.0 on CentOS 7) I don't see external users (users that are known via the trust with AD) under the "Users" tab. There is limited visibility / management of external groups and membership, but nothing that displays a list of available users/groups in AD when attempting to create/modify a user/group. > Define user mappings: > IPA Server -> ID Views -> Default Trust View By "mapping" I meant adding an AD group to a FreeIPA group (which can be used for HBAC/sudo) so that AD membership is known by IPA when applying the HBAC/sudo rules. For example: ipa group-add \ --desc="lab.gen.zone 'Domain Admins' external map" \ lgz_map_domain_admins \ --external ipa group-add \ --desc="lab.gen.zone 'Domain Admins' POSIX" \ lgz_domain_admins ipa group-add-member \ lgz_map_domain_admins \ --external 'LAB\Domain Admins' ipa group-add-member \ lgz_domain_admins \ --groups lgz_map_domain_admins -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Feb 1 23:12:25 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 2 Feb 2017 00:12:25 +0100 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> <8ef84c22-12b8-f67a-71fc-a85e580e40f9@redhat.com> Message-ID: <0226ffd7-a23d-acca-9abc-f5129aa10a7c@redhat.com> On 02.02.2017 00:05, Lachlan Musicman wrote: > On 2 February 2017 at 09:51, Martin Basti > wrote: > > > On 01.02.2017 23:44, Lachlan Musicman wrote: >> >> >> (aside: does FreeIPA have plans to move toward PatternFly? >> http://www.patternfly.org/ ) > > Unless I missed something, FreeIPA 4.x already uses patternfly > > https://ipa.demo1.freeipa.org/ipa/ui/ > > admin/Secret123 > > > Ah! The thing I am missing is IPA 4.4! (still on 4.2. Upgrade in the > planning) > > cheers > L. Actually patternfly is there since 4.0.0 http://www.freeipa.org/page/Releases/4.0.0 """ Web UI adopted Patternfly open interface project to promote design commonality and improved user experience. Web UI is now responsive and adapts to different screen sizes like mobile or tablets. """ So you should see it on 4.2, if not you have something broken :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From datakid at gmail.com Wed Feb 1 23:46:13 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Thu, 2 Feb 2017 10:46:13 +1100 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: <704714061.2918.1485990382476.JavaMail.zimbra@tresgeek.net> References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> <704714061.2918.1485990382476.JavaMail.zimbra@tresgeek.net> Message-ID: On 2 February 2017 at 10:06, Jason B. Nance wrote: > > > - User/group management in general becomes largely a command-line >> operation (such as mapping groups so they can be used in HBAC and sudo >> rules) >> >> While this is a nice-to-have, it isn't a deal breaker. >> > > This definitely exists in WebUI? Unless you mean something I don't > understand. > > Define groups: > Identity->User Groups (second tab) > > In my setup (FreeIPA 4.4.0 on CentOS 7) I don't see external users (users > that are known via the trust with AD) under the "Users" tab. There is > limited visibility / management of external groups and membership, but > nothing that displays a list of available users/groups in AD when > attempting to create/modify a user/group. > Ah! Yes, I can't see all the AD users either. But adding a user to the ID Views does fail on bad user names, which is not the same thing - I know - but I only have a one way trust (from FreeIPA to AD) and the AD is managed by the IT Overlords on Floor 6. Bi directional trust may have different usage? > Define user mappings: > IPA Server -> ID Views -> Default Trust View > > By "mapping" I meant adding an AD group to a FreeIPA group (which can be > used for HBAC/sudo) so that AD membership is known by IPA when applying the > HBAC/sudo rules. For example: > > ipa group-add \ > --desc="lab.gen.zone 'Domain Admins' external map" \ > lgz_map_domain_admins \ > --external > ipa group-add \ > --desc="lab.gen.zone 'Domain Admins' POSIX" \ > lgz_domain_admins > ipa group-add-member \ > lgz_map_domain_admins \ > --external 'LAB\Domain Admins' > ipa group-add-member \ > lgz_domain_admins \ > --groups lgz_map_domain_admins > > Through the groups UI, you can add an external group (we use the naming system "ad_my_group"), then add the AD group as an external member to that group (add AD-DOMAIN\my_group). Then we add the local POSIX group ("my_group") and make "ad_my_group" a member of that. When you add a group in the groups, you will see the option for the group to be POSIX, external or normal. cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_2017-02-02_10-41-09.png Type: image/png Size: 15655 bytes Desc: not available URL: From ftweedal at redhat.com Thu Feb 2 00:11:15 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 2 Feb 2017 10:11:15 +1000 Subject: [Freeipa-users] Dogtag vs Freeipa Dogtag In-Reply-To: References: Message-ID: <20170202001115.GI3557@dhcp-40-8.bne.redhat.com> On Wed, Feb 01, 2017 at 09:44:34PM +0100, Gorazd wrote: > Hello, > > i am interested if there is any feature matrix available for FreeIpa > version of dogtag packaging. So which features of DogTak are not included > or does come with limitations when installed with Freeipa (such as OCSP is > already part of CA and could not be installed seperately), in contrast when > on uses Dogtag as a standlone software installation? > FreeIPA does not use the standalone OCSP responder, or the token processing subsystems (TKS/TPS). There is nothing preventing you from installing them, but FreeIPA won't help you to do that, and there is no integration. Cheers, Fraser > Thank you in advance. > > Regards, > Gorazd > -- > 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 deepak.dimri2016 at gmail.com Thu Feb 2 04:42:16 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Thu, 2 Feb 2017 10:12:16 +0530 Subject: [Freeipa-users] Gateway_timeout Error In-Reply-To: References: <215e3abb-4137-d311-ea8c-dca541664178@redhat.com> Message-ID: Hey Martin, Is gateway error has anything to do with --no-wait-for-dns flag that i used when i created the replica image? i have another test IPA setup working fine in the same env and the only difference i see that in that env i did not use --no-wait-for-dns for replicas Thanks, Deepak On Wed, Feb 1, 2017 at 10:52 PM, deepak dimri wrote: > sorry for not replying to all! > > I have apache reverse proxy front ending the ipa servers. As i mentioned > if i try hitting ipa replica WebUI directly then i do get the objects > loaded on the browser after waiting for over a minute or so. replica server > (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}) shows hits coming > through fine but for some reasons web browser ends up with the gateway > error. > > both the ipa masters are running VERSION: 4.4.0, API_VERSION: 2.213 > > Kind Regards, > Deepak > > > On Wed, Feb 1, 2017 at 9:21 PM, Martin Babinsky > wrote: > >> On 02/01/2017 04:26 PM, deepak dimri wrote: >> >>> Yes, Martin - i do see requests hitting >>> replica.. /var/log/httpd/error_log shows: >>> >>> [Wed Feb 01 15:16:47.469766 2017] [:error] [pid 2464] ipa: INFO: >>> admin at XXX.XYZ.COM : batch: >>> host_show(u'xxx.abx.xyz ', rights=True, all=True): >>> SUCCESS >>> >>> I used ansible playbook to build the replica server. ran >>> ipa-replica-prepare on the primary: >>> ipa-replica-prepare {{ replica_dns }} --password={{ipa_password}} >>> --no-wait-for-dns >>> >>> copied the replica file over to replica server: >>> scp -oStrictHostKeyChecking=no -i ~/.ssh/{{ssh_keyname}}.pem >>> /var/lib/ipa/replica-info-{{ replica_dns }}.gpg root@{{ >>> replica_dns }}:/var/lib/ipa/ >>> >>> ran the replica install on the replica server: >>> ipa-replica-install /var/lib/ipa/replica-info-{{ replica_dns }}.gpg >>> --password={{ipa_password}} --admin-password={{ipa_password}} >>> >>> I have notices that if i directly use the replica (bypassing proxy) URL >>> then the objects shows after waiting for over a minute or so. When i use >>> proxy pass then it just times out after few seconds. >>> >>> No clue why its behaving like this >>> >>> Many Thanks, >>> Deepak >>> >>> On Wed, Feb 1, 2017 at 6:45 PM, Martin Babinsky >> > wrote: >>> >>> On 02/01/2017 11:17 AM, deepak dimri wrote: >>> >>> Hello Martin, Thank you so much for your reply. >>> >>> I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary >>> server and >>> its pointing to its own hostname and not to primary server >>> hostname :( >>> >>> any other clue, Martin? >>> >>> I have tried without proxy and again to luck either its throwing >>> same >>> gateway_error >>> >>> Regards, >>> Deepak >>> >>> On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky >>> >>> >> >>> wrote: >>> >>> On 02/01/2017 10:22 AM, deepak dimri wrote: >>> >>> Hi All, >>> >>> I have two IPA servers - primary and secondary running. >>> the >>> secondary >>> ipa server is installed using ipa replica image of >>> primary. >>> While doing >>> the testing i realised that when i manually shut down my >>> primary ipa >>> server making my secondary server to serve the UI. And >>> now when >>> i try to >>> access user or hosts details using my secondary server >>> then i am >>> getting >>> below error in the UI. I am able to login fine though; >>> it is >>> just that >>> when i double click on host objects then i get the error. >>> >>> >>> An error has occurred (GATEWAY_TIMEOUT) >>> >>> >>> I am still trying to troubleshoot as why i am getting >>> timeout >>> error but >>> thought of asking the group here to see if some one can >>> share >>> some pointers >>> >>> Many Thanks, >>> Deepak >>> >>> >>> Hi Deepak, >>> >>> please check /etc/ipa/default.conf on the secondary server >>> and check >>> the value of 'xmlrpc_uri'. Maybe it points to the URL of >>> primary >>> server and that's why you get timeouts when it is down. >>> >>> Re-setting it to the secondary server itself should fix it. >>> >>> -- >>> Martin^3 Babinsky >>> >>> -- >>> 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 >>> >>> >>> >>> Adding freeipa-users back to loop. >>> >>> That is strange, how did you stand up the replica? >>> >>> You can also inspect /var/log/http/error_log on the replica to see >>> whether the commands from the WebUI reach the local HTTP server at >>> all. >>> >>> -- >>> Martin^3 Babinsky >>> >>> >>> >> Deepak, >> >> please keep replying to freeipa-users mailing list, otherwise other >> members do not get updates on your problem. >> >> As for the issues with replica, I did not notice before that you are >> connecting to WebUI through a proxy, what kind of proxy is that and how is >> it configured? >> >> Nevertheless waiting for over a minute to display entries does not sound >> right. I would investigate the root cause of this performance regression by >> checking DS access and error logs on the replica >> (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}). >> >> Does the master also take so long time to respond? What are the IPA >> versions of master/replica? >> >> -- >> Martin^3 Babinsky >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Feb 2 07:19:30 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 2 Feb 2017 08:19:30 +0100 Subject: [Freeipa-users] guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error In-Reply-To: <58921B01.4060107@sonsorol.org> References: <58921B01.4060107@sonsorol.org> Message-ID: <20170202071930.GA894@p.Speedport_W_724V_Typ_A_05011603_00_011> On Wed, Feb 01, 2017 at 12:29:37PM -0500, Chris Dagdigian wrote: > Hi folks, > > I've posted here and gotten amazing help on our odd setup with IPA having a > 1-way trust to a massive remote AD forest with 90+ domain controllers and > lots of child domains. > > I'm running into a strange issue where I can resolve and manage users in > child domain (NAFTA.COMPANY.ORG) but I am getting failures and just > discovered an interesting error that relates to resolving a user in the > EAME.COMPANY.ORG forrest. > > However I've also been dragged down the rabbit hole tracking down errors > that turned out to be meaningless so I figured my 1st question will be "is > this the error should I be focusing on?" > > This is my situation: > > 1. "id user at NAFTA.COMPANY.ORG" works perfectly fine - no issues at all with > RBAC, sudo and hosting SSH keys etc. > > 2. "id user at EAME.COMPANY.ORG" fails with "no such user" > > 3. We did not configure any specific SID-UID mapping rules in sssd.conf as > we had assumed we'd use the "default" behavior > > > After digging through the logs I found this which seems VERY clear about the > root cause: > > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > [dp_get_account_info_handler] (0x0200): Got request for > [0x1][BE_REQ_USER][1][name=u474418 at eame.company.org] > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > [sdap_idmap_sid_to_unix] (0x0040): Object SID > [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger > than the ldap_idmap_range_size. See the "ID MAPPING? section of sssd-ad(5) > for an explanation of how to resolve this issue. > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID > [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user] > (0x0020): Failed to save user [u474418 at eame.company.org] > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users] > (0x0040): Failed to store user 0. Ignoring. > > > The error about "Object SID has a RID that is larger than > ldap_idmap_range_size .." seems pretty clear. I don't think this is a > 'rabbit hole' message - this seems like a real config problem on my end. Yes, unfortunately this messages is a bit misleading on an IPA client because here you do not have to fix the local configuration but you only have to add an id-range on an IPA server. Please check the existing id-ranges with ipa idrange-find There should be already one for EAME.COMPANY.ORG with the default size of 200000 ("Number of IDs in the range: 200000"). Please add a second idrange for EAME.COMPANY.ORG which covers the RIDs above 200000. If you need help with choosing the parameters please send the idrange-find output. HTH bye, Sumit > > The problem is that I'm not quite sure what I should configure to resolve > this. The man page for sssd-ad covers the topic but does not cover > recommended configuration options. > > > Questions for this list: > > 1) Confirm that the "SID has an RID that is larger ..." error is real and > worth chasing down ? > > 2) My understanding was that by default SSSD will hash SIDs and come up with > unique UID and GID ranges that will be consistent across any machine bound > to the same IDM mechanism. So I've not configured anything specific related > to SID-to-UID mapping as we wanted to go with the default behavior used by > SSSD. Obviously the default is not working and I've got to make a change. I > just don't know what the recommended change should be. Help appreciated! > > > > Config file details are below. > > > Regards, > Chris > > > > > > This is the sssd/sssd.conf file on the IPA server: > > ###---------------------- > > [domain/companyidm.org] > ldap_user_principal = nosuchattr > subdomain_inherit = ldap_user_principal > debug_level = 5 > krb5_validate = True > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = companyidm.org > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = usaeilidmp001.companyidm.org > chpass_provider = ipa > ipa_server = usaeilidmp001.companyidm.org > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > > domains = companyidm.org > [nss] > memcache_timeout = 600 > homedir_substring = /home > > [pam] > debug_level = 5 > [sudo] > > [autofs] > > [ssh] > debug_level = 5 > > [pac] > > [ifp] > > ###---------------------- > > > This is krb5.conf which handles the child domain and trust things ... > > [capaths] > COMPANYAWS.ORG = { > COMPANYIDM.ORG = COMPANYAWS.ORG > } > COMPANYIDM.ORG = { > COMPANYAWS.ORG = COMPANYAWS.ORG > SYNGENTA.ORG = COMPANY.ORG > EAME.COMPANY.ORG = SYNGENTA.ORG > APAC.COMPANY.ORG = SYNGENTA.ORG > LATAM.COMPANY.ORG = SYNGENTA.ORG > NAFTA.COMPANY.ORG = SYNGENTA.ORG > } > COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > EAME.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > APAC.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > LATAM.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > NAFTA.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > default_realm = COMPANYIDM.ORG > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > COMPANYIDM.ORG = { > kdc = usaeilidmp001.companyidm.org:88 > master_kdc = usaeilidmp001.companyidm.org:88 > admin_server = usaeilidmp001.companyidm.org:749 > default_domain = syngentaidm.org > pkinit_anchors = FILE:/etccompanyidmipa/ca.crt > } > > [dbmodules] > COMPANYIDM.ORG = { > db_library = ipadb.so > } > > > > > -- > 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 Thu Feb 2 07:27:36 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 2 Feb 2017 08:27:36 +0100 Subject: [Freeipa-users] [SOLVED] Re: guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error In-Reply-To: <589239EF.8030201@sonsorol.org> References: <589239EF.8030201@sonsorol.org> Message-ID: <20170202072736.GB894@p.Speedport_W_724V_Typ_A_05011603_00_011> On Wed, Feb 01, 2017 at 02:41:35PM -0500, Chris Dagdigian wrote: > > Update: > > Resolved. A bit of googling led me to some good RHEL pages as well as > mailing list messages from Alex B that were concise and helpful. > > To summarize for others who may have this problem: > > 1. Don't make changes to sssd.conf if your provider is "ipa" - in this case > you work only with "ipa idrange-mod" type commands or webUI > > 2. The simple solution is to increase the range and restart SSSD after > blowing away out of date sssd database: > > # ipa idrange-mod --base-id=4000000 --range-size=1000000 > EAME.COMPANY.ORG_id_range > # service sssd stop; rm -f /var/lib/sss/db/*; service sssd start > > > What I actually did on our IPA server was a bit more expansive. EAME was the > first child domain where I had the SID to UID map issue but it would > probably not have been the only one so I figured it would be safer to make > sure that every child domain range had at least 1 million available IDs > > Using the IPA webUI under "IPA Server" -> "ID Ranges" -> "Range Name" > > I went through every single AD child domain and manually reconfigured both > the "First Posix ID of the range" as well as "Number of IDs in the range" so > we have at least 1,000,000 ID options in each child domain range: > > APAC.COMPANY.ORG 1st-Posix=1800000000 Ids-in-range: 1000000 > EAME.COMPANY.ORG 1st-Posix=1810000000 Ids-in-range: 1000000 > LATAM.COMPANY.ORG 1st-Posix=1820000000 Ids-in-range: 1000000 > NAFTA.COMPANY.ORG 1st-Posix=1830000000 Ids-in-range: 1000000 > > We are still in testing mode with less than 6 users logging in via IDM > identities at the moment so it was not disruptive to make this sort of core > change. This is a valid way in testing mode. As I wrote in my other mail it is possible and recommended in production to add additional idrange for a domain to cover more RIDs if needed. The difference is that the IPA server already checks if there are no collisions in the idrange definitions and SSSD on the clients can then just safely add the new idrange. If a definition of an idrange changes it might be possible that existing ID-mappings changes, to be on the safe side here SSSD requires a restart with removing the cache on all clients. HTH bye, Sumit > > > -Chris > > > > > > > > Chris Dagdigian wrote: > > Hi folks, > > > > I've posted here and gotten amazing help on our odd setup with IPA > > having a 1-way trust to a massive remote AD forest with 90+ domain > > controllers and lots of child domains. > > > > I'm running into a strange issue where I can resolve and manage users in > > child domain (NAFTA.COMPANY.ORG) but I am getting failures and just > > discovered an interesting error that relates to resolving a user in the > > EAME.COMPANY.ORG forrest. > > > > However I've also been dragged down the rabbit hole tracking down errors > > that turned out to be meaningless so I figured my 1st question will be > > "is this the error should I be focusing on?" > > > > This is my situation: > > > > 1. "id user at NAFTA.COMPANY.ORG" works perfectly fine - no issues at all > > with RBAC, sudo and hosting SSH keys etc. > > > > 2. "id user at EAME.COMPANY.ORG" fails with "no such user" > > > > 3. We did not configure any specific SID-UID mapping rules in sssd.conf > > as we had assumed we'd use the "default" behavior > > > > > > After digging through the logs I found this which seems VERY clear about > > the root cause: > > > > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > > [dp_get_account_info_handler] (0x0200): Got request for > > [0x1][BE_REQ_USER][1][name=u474418 at eame.company.org] > > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > > [sdap_idmap_sid_to_unix] (0x0040): Object SID > > [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger > > than the ldap_idmap_range_size. See the "ID MAPPING? section of > > sssd-ad(5) for an explanation of how to resolve this issue. > > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] > > [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID > > [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID > > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user] > > (0x0020): Failed to save user [u474418 at eame.company.org] > > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users] > > (0x0040): Failed to store user 0. Ignoring. > > > > > > The error about "Object SID has a RID that is larger than > > ldap_idmap_range_size .." seems pretty clear. I don't think this is a > > 'rabbit hole' message - this seems like a real config problem on my end. > > > > The problem is that I'm not quite sure what I should configure to > > resolve this. The man page for sssd-ad covers the topic but does not > > cover recommended configuration options. > > > > > > Questions for this list: > > > > 1) Confirm that the "SID has an RID that is larger ..." error is real > > and worth chasing down ? > > > > 2) My understanding was that by default SSSD will hash SIDs and come up > > with unique UID and GID ranges that will be consistent across any > > machine bound to the same IDM mechanism. So I've not configured anything > > specific related to SID-to-UID mapping as we wanted to go with the > > default behavior used by SSSD. Obviously the default is not working and > > I've got to make a change. I just don't know what the recommended change > > should be. Help appreciated! > > > > > > > > Config file details are below. > > > > > > Regards, > > Chris > > > > > > > > > > > > This is the sssd/sssd.conf file on the IPA server: > > > > ###---------------------- > > > > [domain/companyidm.org] > > ldap_user_principal = nosuchattr > > subdomain_inherit = ldap_user_principal > > debug_level = 5 > > krb5_validate = True > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = companyidm.org > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = usaeilidmp001.companyidm.org > > chpass_provider = ipa > > ipa_server = usaeilidmp001.companyidm.org > > ipa_server_mode = True > > ldap_tls_cacert = /etc/ipa/ca.crt > > [sssd] > > services = nss, sudo, pam, ssh > > config_file_version = 2 > > > > domains = companyidm.org > > [nss] > > memcache_timeout = 600 > > homedir_substring = /home > > > > [pam] > > debug_level = 5 > > [sudo] > > > > [autofs] > > > > [ssh] > > debug_level = 5 > > > > [pac] > > > > [ifp] > > > > ###---------------------- > > > > > > This is krb5.conf which handles the child domain and trust things ... > > > > [capaths] > > COMPANYAWS.ORG = { > > COMPANYIDM.ORG = COMPANYAWS.ORG > > } > > COMPANYIDM.ORG = { > > COMPANYAWS.ORG = COMPANYAWS.ORG > > SYNGENTA.ORG = COMPANY.ORG > > EAME.COMPANY.ORG = SYNGENTA.ORG > > APAC.COMPANY.ORG = SYNGENTA.ORG > > LATAM.COMPANY.ORG = SYNGENTA.ORG > > NAFTA.COMPANY.ORG = SYNGENTA.ORG > > } > > COMPANY.ORG = { > > COMPANYIDM.ORG = COMPANY.ORG > > } > > EAME.COMPANY.ORG = { > > COMPANYIDM.ORG = COMPANY.ORG > > } > > APAC.COMPANY.ORG = { > > COMPANYIDM.ORG = COMPANY.ORG > > } > > LATAM.COMPANY.ORG = { > > COMPANYIDM.ORG = COMPANY.ORG > > } > > NAFTA.COMPANY.ORG = { > > COMPANYIDM.ORG = COMPANY.ORG > > } > > > > > > [logging] > > default = FILE:/var/log/krb5libs.log > > kdc = FILE:/var/log/krb5kdc.log > > admin_server = FILE:/var/log/kadmind.log > > > > [libdefaults] > > default_realm = COMPANYIDM.ORG > > dns_lookup_realm = true > > dns_lookup_kdc = true > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > udp_preference_limit = 0 > > default_ccache_name = KEYRING:persistent:%{uid} > > > > [realms] > > COMPANYIDM.ORG = { > > kdc = usaeilidmp001.companyidm.org:88 > > master_kdc = usaeilidmp001.companyidm.org:88 > > admin_server = usaeilidmp001.companyidm.org:749 > > default_domain = syngentaidm.org > > pkinit_anchors = FILE:/etccompanyidmipa/ca.crt > > } > > > > [dbmodules] > > COMPANYIDM.ORG = { > > db_library = ipadb.so > > } > > > > > > > > > > -- > 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 Feb 2 08:16:06 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 2 Feb 2017 10:16:06 +0200 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: <704714061.2918.1485990382476.JavaMail.zimbra@tresgeek.net> References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> <704714061.2918.1485990382476.JavaMail.zimbra@tresgeek.net> Message-ID: <20170202081606.dlr3s6ev4xysadwy@redhat.com> On ke, 01 helmi 2017, Jason B. Nance wrote: >>>> - User/group management in general becomes largely a command-line operation >>> > (such as mapping groups so they can be used in HBAC and sudo rules) > >>> While this is a nice-to-have, it isn't a deal breaker. > >> This definitely exists in WebUI? Unless you mean something I don't understand. > >> Define groups: >> Identity->User Groups (second tab) > >In my setup (FreeIPA 4.4.0 on CentOS 7) I don't see external users >(users that are known via the trust with AD) under the "Users" tab. >There is limited visibility / management of external groups and >membership, but nothing that displays a list of available users/groups >in AD when attempting to create/modify a user/group. Not seeing AD users is the correct thing, you don't miss anything. This topic comes regularly on the list. It is described in the Windows integration guide, we discuss it here, you can look into archives, for example: https://www.redhat.com/archives/freeipa-users/2016-October/msg00083.html IPA is not designed to give you ability to manage your AD users as if they were in IPA -- you cannot create them there, you cannot list them there. They are not and there is no need to pretend they are. POSIX attributes for them can be managed in the ID overrides (in Default Trust View). We are working on making possible to do self-service in web UI for AD users themselves in upcoming releases. You can do 'self-service' as an AD user in CLI already with ipa idoverrideuser-mod "default trust view" your.account at ad.domain [options] but you currently cannot login as AD user to web UI. Also ID Override needs to be pre-created by the IPA admin right now -- just do ipa idoverrideuser-add "default trust view" your.account at ad.domain >> Define user mappings: >> IPA Server -> ID Views -> Default Trust View > >By "mapping" I meant adding an AD group to a FreeIPA group (which can be used for HBAC/sudo) so that AD membership is known by IPA when applying the HBAC/sudo rules. For example: > >ipa group-add \ >--desc="lab.gen.zone 'Domain Admins' external map" \ >lgz_map_domain_admins \ >--external >ipa group-add \ >--desc="lab.gen.zone 'Domain Admins' POSIX" \ >lgz_domain_admins >ipa group-add-member \ >lgz_map_domain_admins \ >--external 'LAB\Domain Admins' >ipa group-add-member \ >lgz_domain_admins \ >--groups lgz_map_domain_admins >-- >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 jhrozek at redhat.com Thu Feb 2 08:32:37 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 2 Feb 2017 09:32:37 +0100 Subject: [Freeipa-users] Is WinSync A Bad Choice? In-Reply-To: <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> References: <1832220453.2396.1485982855024.JavaMail.zimbra@tresgeek.net> <20170201214457.cxr45itooxvvivtk@hendrix> <479239287.2645.1485987579477.JavaMail.zimbra@tresgeek.net> Message-ID: <20170202083237.mqn5ne53qtjoitbd@hendrix> On Wed, Feb 01, 2017 at 04:19:39PM -0600, Jason B. Nance wrote: > >> - Users can't login to a Linux box using just "username" (user at ad.domain is > >> used) > > > > In the current version you can use the 'default_domain_suffix' option in > > sssd.conf on the clients. In RHEL-7.4 we are looking into making this > > limitation go away. > > Thank you very much, Jakub. That is helpful information! Are you saying that there will basically be a domain search order or something for users that login without specifying a domain? For the IPA-AD case, probably: https://fedorahosted.org/sssd/ticket/3210 For the direct AD integration case (which will share the underlying code with the IPA-AD integration case), the admin would opt-in with a sssd.conf option, essentially saying 'let me always use shortnames for all domains, there are no name conflicts' and then sssd would not require shortnames for trusted domains. The ticket that tracks the shortname-for-trusted-domains case in general is: https://fedorahosted.org/sssd/ticket/3001 Please note the tickets are in the "Future releases" milestone at the moment, but we do plan them for the next RHEL release; the upstream milestones just need a bit more grooming. From peljasz at yahoo.co.uk Thu Feb 2 10:25:52 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 2 Feb 2017 10:25:52 +0000 Subject: [Freeipa-users] unable to delete a user - which has a double?? In-Reply-To: <83zii5wwrv.fsf@jochen.org> References: <83zii5wwrv.fsf@jochen.org> Message-ID: On 01/02/17 19:12, Jochen Hein wrote: > Hi > > lejeczek writes: > >> I think it had something to do with an initial(long time ago) >> migration. >> How to safely delete such a user? Or one of them? >> >> $ ipa user-del appmgr --no-preserve >> ipa: ERROR: The search criteria was not specific enough. Expected 1 >> and found 2. > Did you try "--continue"? nope, --continue won't help, at least with 4.4 > You can check both users with "ipa user-find ... --all" and look for the > ipauniqueid. I think you'll can remove the user with ldapremove. > > Jochen > From peljasz at yahoo.co.uk Thu Feb 2 10:30:18 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 2 Feb 2017 10:30:18 +0000 Subject: [Freeipa-users] unable to delete a user - which has a double?? In-Reply-To: <8566438d-593f-cc46-9525-3ab78fde0466@redhat.com> References: <8566438d-593f-cc46-9525-3ab78fde0466@redhat.com> Message-ID: <655c812e-498a-8b10-fa4b-7a75acd7d014@yahoo.co.uk> On 01/02/17 19:16, Martin Basti wrote: > Hello, > > you have to use ldapdelete command and remove it manually > > Martin > > and the user's group? I'm using a gui and it protests: .. Deleting a managed entry is not allowed. It needs to be manually unlinked first.] .. I've already have the user removed. Would be great if coming new versions account for this situation and provide users/admin with tool(s) that can take care of. many thanks, L. > On 01.02.2017 19:30, lejeczek wrote: >> hi all, >> take a look: >> >> $ ipa user-find --uid 3501 >> -------------- >> 1 user matched >> -------------- >> User login: appmgr >> First name: app >> Last name: developer >> Home directory: /home.sysops/appmgr >> Login shell: /bin/bash >> Principal alias: appmgr at PRIVATE >> Email address: appmgr at private >> UID: 3501 >> GID: 3501 >> Account disabled: False >> >> $ ipa user-find --uid 1104 >> -------------- >> 1 user matched >> -------------- >> User login: appmgr >> First name: app >> Last name: devel 1 >> Home directory: /home.sysops/appmgr >> Login shell: /bin/bash >> Principal alias: appmgr at PRIVATE >> Email address: appmgr at private >> UID: 1104 >> GID: 1104 >> Account disabled: False >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> I think it had something to do with an initial(long time >> ago) migration. >> How to safely delete such a user? Or one of them? >> >> $ ipa user-del appmgr --no-preserve >> ipa: ERROR: The search criteria was not specific enough. >> Expected 1 and found 2. >> >> many thanks, >> L. >> > From telekomunikacije at gmail.com Thu Feb 2 10:56:55 2017 From: telekomunikacije at gmail.com (Gorazd) Date: Thu, 2 Feb 2017 11:56:55 +0100 Subject: [Freeipa-users] Dogtag vs Freeipa Dogtag In-Reply-To: <20170202001115.GI3557@dhcp-40-8.bne.redhat.com> References: <20170202001115.GI3557@dhcp-40-8.bne.redhat.com> Message-ID: Hi Fraser, thank you for your comment. Still doing some decision making, could anyone know if for example KeyCloak (as identity and acces managment solution)+DogTag could have the same or better experience (since dogtag has more features than IPA's bundeled dogtag) than using Freeipa, what are really the benefits of FreeIPA to use it as a system for IdM and PKI solution, is that really just that it has integrations with RADIUS also supported, so to be also ready for the deploy within typical enterprise environments? Thank you in advance, Gorazd On Thu, Feb 2, 2017 at 1:11 AM, Fraser Tweedale wrote: > On Wed, Feb 01, 2017 at 09:44:34PM +0100, Gorazd wrote: > > Hello, > > > > i am interested if there is any feature matrix available for FreeIpa > > version of dogtag packaging. So which features of DogTak are not included > > or does come with limitations when installed with Freeipa (such as OCSP > is > > already part of CA and could not be installed seperately), in contrast > when > > on uses Dogtag as a standlone software installation? > > > FreeIPA does not use the standalone OCSP responder, or the token > processing subsystems (TKS/TPS). There is nothing preventing you > from installing them, but FreeIPA won't help you to do that, and > there is no integration. > > Cheers, > Fraser > > > Thank you in advance. > > > > Regards, > > Gorazd > > > -- > > 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 Thu Feb 2 11:25:43 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 2 Feb 2017 13:25:43 +0200 Subject: [Freeipa-users] Dogtag vs Freeipa Dogtag In-Reply-To: References: <20170202001115.GI3557@dhcp-40-8.bne.redhat.com> Message-ID: <20170202112542.2jwpai6a2cjaos5y@redhat.com> Hi, On to, 02 helmi 2017, Gorazd wrote: >Hi Fraser, > >thank you for your comment. > >Still doing some decision making, could anyone know if for example KeyCloak >(as identity and acces managment solution)+DogTag could have the same or >better experience (since dogtag has more features than IPA's bundeled >dogtag) than using Freeipa, what are really the benefits of FreeIPA to use >it as a system for IdM and PKI solution, is that really just that it has >integrations with RADIUS also supported, so to be also ready for the deploy >within typical enterprise environments? FreeIPA attempts to make easier deployment of common use cases we've seen so far. There are two limiting factors: 1) available people who can do the work (contributions are welcome!), and 2) priorities that come from paying customers for those teams that could contribute development resources. In short, a software needs to be written and maintained, that does not happens by itself. If someone wants to use more advanced Dogtag features, they are free to work with Dogtag and FreeIPA to contribute an integration pieces. Most of such integration requires changes on the Dogtag side as well -- we discovered multiple times that in order to automate/simplify/etc we have to change on both sides, so a deeper development cooperation between those projects was always needed (and was/is happening). Finally, talking to Dogtag developers directly to get an advise what is possible on their side is an option too. Obviously, doing a joint development takes time and has to be planned out. In some cases you might be not being able to contribute that time or your goals are to deploy within a shorter time frame. This means your other option could be to either use Dogtag directly or look for alternatives. >From my perspective it is just perfectly fine to make an informed decision to not use FreeIPA. It is also perfectly fine to consider installing additional Dogtag components and take responsibility of supporting a resulting deployment setup. Each situation has own constraints and limitations which only you are aware of, not other members of extended community. And only you can decide what amount of effort could be put to achieve your goals. > >Thank you in advance, >Gorazd > > > >On Thu, Feb 2, 2017 at 1:11 AM, Fraser Tweedale wrote: > >> On Wed, Feb 01, 2017 at 09:44:34PM +0100, Gorazd wrote: >> > Hello, >> > >> > i am interested if there is any feature matrix available for FreeIpa >> > version of dogtag packaging. So which features of DogTak are not included >> > or does come with limitations when installed with Freeipa (such as OCSP >> is >> > already part of CA and could not be installed seperately), in contrast >> when >> > on uses Dogtag as a standlone software installation? >> > >> FreeIPA does not use the standalone OCSP responder, or the token >> processing subsystems (TKS/TPS). There is nothing preventing you >> from installing them, but FreeIPA won't help you to do that, and >> there is no integration. >> >> Cheers, >> Fraser >> >> > Thank you in advance. >> > >> > Regards, >> > Gorazd >> >> > -- >> > 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 -- / Alexander Bokovoy From deepak.dimri2016 at gmail.com Thu Feb 2 12:30:44 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Thu, 2 Feb 2017 18:00:44 +0530 Subject: [Freeipa-users] Gateway_timeout Error In-Reply-To: References: <215e3abb-4137-d311-ea8c-dca541664178@redhat.com> Message-ID: Hi All, I am stuck with this gateway error on my replicas. I recreated the replicas but that did not help either. I realised that if i just keep my primary ipa up then i do not get the error on the secondary/replica server. The error logs on replica shows hits are getting successfully executed but i am certain that its trying to bind to primary ipa server when i am trying to open the hosts/users entries. It seems its failing to make ldap bind to primary server and then eventually timing out. Any idea why in my case replica is trying to connect to ipa master? Thanks, Deepak On Thu, Feb 2, 2017 at 10:12 AM, deepak dimri wrote: > Hey Martin, > > > Is gateway error has anything to do with --no-wait-for-dns flag that i > used when i created the replica image? i have another test IPA setup > working fine in the same env and the only difference i see that in that env > i did not use --no-wait-for-dns for replicas > > Thanks, > Deepak > > On Wed, Feb 1, 2017 at 10:52 PM, deepak dimri > wrote: > >> sorry for not replying to all! >> >> I have apache reverse proxy front ending the ipa servers. As i mentioned >> if i try hitting ipa replica WebUI directly then i do get the objects >> loaded on the browser after waiting for over a minute or so. replica server >> (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}) shows hits coming >> through fine but for some reasons web browser ends up with the gateway >> error. >> >> both the ipa masters are running VERSION: 4.4.0, API_VERSION: 2.213 >> >> Kind Regards, >> Deepak >> >> >> On Wed, Feb 1, 2017 at 9:21 PM, Martin Babinsky >> wrote: >> >>> On 02/01/2017 04:26 PM, deepak dimri wrote: >>> >>>> Yes, Martin - i do see requests hitting >>>> replica.. /var/log/httpd/error_log shows: >>>> >>>> [Wed Feb 01 15:16:47.469766 2017] [:error] [pid 2464] ipa: INFO: >>>> admin at XXX.XYZ.COM : batch: >>>> host_show(u'xxx.abx.xyz ', rights=True, all=True): >>>> SUCCESS >>>> >>>> I used ansible playbook to build the replica server. ran >>>> ipa-replica-prepare on the primary: >>>> ipa-replica-prepare {{ replica_dns }} --password={{ipa_password}} >>>> --no-wait-for-dns >>>> >>>> copied the replica file over to replica server: >>>> scp -oStrictHostKeyChecking=no -i ~/.ssh/{{ssh_keyname}}.pem >>>> /var/lib/ipa/replica-info-{{ replica_dns }}.gpg root@{{ >>>> replica_dns }}:/var/lib/ipa/ >>>> >>>> ran the replica install on the replica server: >>>> ipa-replica-install /var/lib/ipa/replica-info-{{ replica_dns }}.gpg >>>> --password={{ipa_password}} --admin-password={{ipa_password}} >>>> >>>> I have notices that if i directly use the replica (bypassing proxy) URL >>>> then the objects shows after waiting for over a minute or so. When i use >>>> proxy pass then it just times out after few seconds. >>>> >>>> No clue why its behaving like this >>>> >>>> Many Thanks, >>>> Deepak >>>> >>>> On Wed, Feb 1, 2017 at 6:45 PM, Martin Babinsky >>> > wrote: >>>> >>>> On 02/01/2017 11:17 AM, deepak dimri wrote: >>>> >>>> Hello Martin, Thank you so much for your reply. >>>> >>>> I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary >>>> server and >>>> its pointing to its own hostname and not to primary server >>>> hostname :( >>>> >>>> any other clue, Martin? >>>> >>>> I have tried without proxy and again to luck either its throwing >>>> same >>>> gateway_error >>>> >>>> Regards, >>>> Deepak >>>> >>>> On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky >>>> >>>> >> >>>> wrote: >>>> >>>> On 02/01/2017 10:22 AM, deepak dimri wrote: >>>> >>>> Hi All, >>>> >>>> I have two IPA servers - primary and secondary running. >>>> the >>>> secondary >>>> ipa server is installed using ipa replica image of >>>> primary. >>>> While doing >>>> the testing i realised that when i manually shut down my >>>> primary ipa >>>> server making my secondary server to serve the UI. And >>>> now when >>>> i try to >>>> access user or hosts details using my secondary server >>>> then i am >>>> getting >>>> below error in the UI. I am able to login fine though; >>>> it is >>>> just that >>>> when i double click on host objects then i get the >>>> error. >>>> >>>> >>>> An error has occurred (GATEWAY_TIMEOUT) >>>> >>>> >>>> I am still trying to troubleshoot as why i am getting >>>> timeout >>>> error but >>>> thought of asking the group here to see if some one can >>>> share >>>> some pointers >>>> >>>> Many Thanks, >>>> Deepak >>>> >>>> >>>> Hi Deepak, >>>> >>>> please check /etc/ipa/default.conf on the secondary server >>>> and check >>>> the value of 'xmlrpc_uri'. Maybe it points to the URL of >>>> primary >>>> server and that's why you get timeouts when it is down. >>>> >>>> Re-setting it to the secondary server itself should fix it. >>>> >>>> -- >>>> Martin^3 Babinsky >>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>>> Adding freeipa-users back to loop. >>>> >>>> That is strange, how did you stand up the replica? >>>> >>>> You can also inspect /var/log/http/error_log on the replica to see >>>> whether the commands from the WebUI reach the local HTTP server at >>>> all. >>>> >>>> -- >>>> Martin^3 Babinsky >>>> >>>> >>>> >>> Deepak, >>> >>> please keep replying to freeipa-users mailing list, otherwise other >>> members do not get updates on your problem. >>> >>> As for the issues with replica, I did not notice before that you are >>> connecting to WebUI through a proxy, what kind of proxy is that and how is >>> it configured? >>> >>> Nevertheless waiting for over a minute to display entries does not sound >>> right. I would investigate the root cause of this performance regression by >>> checking DS access and error logs on the replica >>> (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}). >>> >>> Does the master also take so long time to respond? What are the IPA >>> versions of master/replica? >>> >>> -- >>> Martin^3 Babinsky >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.karasek at elostech.cz Thu Feb 2 15:57:05 2017 From: jan.karasek at elostech.cz (Jan =?utf-8?Q?Kar=C3=A1sek?=) Date: Thu, 2 Feb 2017 16:57:05 +0100 (CET) Subject: [Freeipa-users] ipa- client rhel 6.9 support for UPN different then domain name In-Reply-To: References: Message-ID: <2061649106.9182.1486051025410.JavaMail.zimbra@elostech.cz> Hi, I just looked into RHEL 6.9 beta repos and I can see there is sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 6.9 will come support for using different UPN then domain name. I am talking about AD trust scenario where user in AD domain sits in user at subdomain.example.com but has a UPN set to user at example.com. It has been solved in RHEL 7.3 I guess with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or is there any known workaround ? Thanks, Jan From keesb at ghs.com Thu Feb 2 16:19:07 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 2 Feb 2017 17:19:07 +0100 Subject: [Freeipa-users] How to enable krb5_child log Message-ID: <8b7044c6-2d3f-e4ca-ebf1-e2760620c9b1@ghs.com> Hi Sorry, I did search wherever I could but I couldn't find it. How do I enable krb5_child debug log? I'm on an Ubuntu system which by default writes an empty /var/log/krb5_child.log Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What do I have to add where to get logging in krb5_child.log? BTW. I'm trying to debug a problem that results in "Invalid UID in persistent keyring" The weird thing is, if I become root (via another ssh login) and then do a "su - user" (the same user with the error), the problem does not show up. Meanwhile that user keeps getting the above error (for klist kdestroy, klist). -- Kees From jhrozek at redhat.com Thu Feb 2 16:32:25 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 2 Feb 2017 17:32:25 +0100 Subject: [Freeipa-users] How to enable krb5_child log In-Reply-To: <8b7044c6-2d3f-e4ca-ebf1-e2760620c9b1@ghs.com> References: <8b7044c6-2d3f-e4ca-ebf1-e2760620c9b1@ghs.com> Message-ID: <20170202163225.mfy5buez52gbeuup@hendrix> On Thu, Feb 02, 2017 at 05:19:07PM +0100, Kees Bakker wrote: > Hi > > Sorry, I did search wherever I could but I couldn't find it. > How do I enable krb5_child debug log? I'm on an Ubuntu > system which by default writes an empty /var/log/krb5_child.log > > Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What > do I have to add where to get logging in krb5_child.log? add debug_level= to the [domain] section. > > BTW. I'm trying to debug a problem that results in > "Invalid UID in persistent keyring" > The weird thing is, if I become root (via another ssh login) and > then do a "su - user" (the same user with the error), the problem > does not show up. Meanwhile that user keeps getting the above > error (for klist kdestroy, klist). su as root gets automatically authenticated by the pam_rootok.so module.. From sbose at redhat.com Thu Feb 2 17:30:09 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 2 Feb 2017 18:30:09 +0100 Subject: [Freeipa-users] ipa- client rhel 6.9 support for UPN different then domain name In-Reply-To: <2061649106.9182.1486051025410.JavaMail.zimbra@elostech.cz> References: <2061649106.9182.1486051025410.JavaMail.zimbra@elostech.cz> Message-ID: <20170202173009.GA3552@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Feb 02, 2017 at 04:57:05PM +0100, Jan Kar?sek wrote: > Hi, > > I just looked into RHEL 6.9 beta repos and I can see there is sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 6.9 will come support for using different UPN then domain name. I am talking about AD trust scenario where user in AD domain sits in user at subdomain.example.com but has a UPN set to user at example.com. It has been solved in RHEL 7.3 I guess with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or is there any known workaround ? This is basically a server side feature. You need an IPA server version which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically detect if the server supports this or not. This autodetection was not backported to 6.9 but if your servers support it you can set 'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details) on the IPA clients with older SSSD versions. HTH bye, Sumit > > Thanks, > Jan > > -- > 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 spammewoods at cox.net Thu Feb 2 19:03:28 2017 From: spammewoods at cox.net (spammewoods at cox.net) Date: Thu, 2 Feb 2017 11:03:28 -0800 Subject: [Freeipa-users] Smart Card login into an Active Directory User Message-ID: <20170202140328.HY733.98259.imail@fed1rmwml214> I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a Windows Active Directory server. I am trying to configure the IPA server to allow the Active Directory Users to log into Gnome with a CAC smart card. I?m having a hard time finding any instructions on how to do this. The problem I?m having is the Common Name from the smart card is not getting associated with the Active Directory account. I added the certificate from the smart card to the IPA server by creating a User ID override for the AD user account. I made sure to not use authconfig to configure smart cards and I added ifp to the services line in the sssd.conf file. I have the following packages installed: ipa-admintools.noarch 4.4.0-14.el7_3.4 ipa-client.x86_64 4.4.0-14.el7_3.4 ipa-client-common.noarch 4.4.0-14.el7_3.4 ipa-common.noarch 4.4.0-14.el7_3.4 ipa-python-compat.noarch 4.4.0-14.el7_3.4 ipa-server.x86_64 4.4.0-14.el7_3.4 ipa-server-common.noarch 4.4.0-14.el7_3.4 ipa-server-dns.noarch 4.4.0-14.el7_3.4 ipa-server-trust-ad.x86_64 4.4.0-14.el7_3.4 I can log in with AD user accounts that are configured with UserName and Passswords, so I know that the integration is working. When I try to log into GDM with my smart card, I don?t get prompted for a PIN number. It only asks for the password from the AD account. From pgb205 at yahoo.com Thu Feb 2 22:13:44 2017 From: pgb205 at yahoo.com (pgb205) Date: Thu, 2 Feb 2017 22:13:44 +0000 (UTC) Subject: [Freeipa-users] ipactl services running, but auth not working References: <762288497.596207.1486073624507.ref@mail.yahoo.com> Message-ID: <762288497.596207.1486073624507@mail.yahoo.com> We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line.Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows?everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are:1. What could be causing this, and what can I check.2. What logging should I enable on the server.3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up.What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron jobthat attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsullivan2 at bsd.uchicago.edu Thu Feb 2 22:16:58 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Thu, 2 Feb 2017 22:16:58 +0000 Subject: [Freeipa-users] ipactl services running, but auth not working In-Reply-To: <762288497.596207.1486073624507@mail.yahoo.com> References: <762288497.596207.1486073624507.ref@mail.yahoo.com> <762288497.596207.1486073624507@mail.yahoo.com> Message-ID: <91B861CB-5397-40F5-8A8D-771415546C4F@bsd.uchicago.edu> Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 > wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project From ftweedal at redhat.com Thu Feb 2 23:18:30 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Feb 2017 09:18:30 +1000 Subject: [Freeipa-users] Dogtag vs Freeipa Dogtag In-Reply-To: References: <20170202001115.GI3557@dhcp-40-8.bne.redhat.com> Message-ID: <20170202231830.GK3557@dhcp-40-8.bne.redhat.com> On Thu, Feb 02, 2017 at 11:56:55AM +0100, Gorazd wrote: > Hi Fraser, > > thank you for your comment. > > Still doing some decision making, could anyone know if for example KeyCloak > (as identity and acces managment solution)+DogTag could have the same or > better experience (since dogtag has more features than IPA's bundeled > dogtag) than using Freeipa, what are really the benefits of FreeIPA to use > it as a system for IdM and PKI solution, is that really just that it has > integrations with RADIUS also supported, so to be also ready for the deploy > within typical enterprise environments? > One of the big advantages: if you are issuing certificates for subject principals defined in the FreeIPA directory, you get a lot of validation and authorisation for those certificate requests based on what FreeIPA knows. It can be quite complicated to set up such a regime with Dogtag. OTOH if you need to issue certs for entities about which FreeIPA knows nothing, then FreeIPA doesn't bring a lot to the table right now. If you clearly know what you want but there's isn't support in FreeIPA, file an RFE. Like Alexander mentioned there's no guarantee if or when we can implement it, but at least we will know about it and be able to work assess it alongside other priorities. Cheers, Fraser > Thank you in advance, > Gorazd > > > > On Thu, Feb 2, 2017 at 1:11 AM, Fraser Tweedale wrote: > > > On Wed, Feb 01, 2017 at 09:44:34PM +0100, Gorazd wrote: > > > Hello, > > > > > > i am interested if there is any feature matrix available for FreeIpa > > > version of dogtag packaging. So which features of DogTak are not included > > > or does come with limitations when installed with Freeipa (such as OCSP > > is > > > already part of CA and could not be installed seperately), in contrast > > when > > > on uses Dogtag as a standlone software installation? > > > > > FreeIPA does not use the standalone OCSP responder, or the token > > processing subsystems (TKS/TPS). There is nothing preventing you > > from installing them, but FreeIPA won't help you to do that, and > > there is no integration. > > > > Cheers, > > Fraser > > > > > Thank you in advance. > > > > > > Regards, > > > Gorazd > > > > > -- > > > 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 amitbbhatt1990 at gmail.com Thu Feb 2 23:54:04 2017 From: amitbbhatt1990 at gmail.com (amit bhatt) Date: Fri, 3 Feb 2017 05:24:04 +0530 Subject: [Freeipa-users] Fwd: FreeIPA installation on centos 7 In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: amit bhatt Date: Thu, Feb 2, 2017 at 10:56 PM Subject: FreeIPA installation on centos 7 To: freeipa-users at redhat.com My QA development setup is running with IPA VERSION: 4.2.0 on centos 7 and I want to install the same version in my production environment as well. however when i am running yum install ipa-server i am getting VERSION: 4.4.0 (package ipa-server-4.4.0-14.el7.centos.4.x86_64) installed. How can i force IPA server to install 4.2.0 and not 4.4.0? Thanks for your help in advance ~Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Feb 3 08:33:13 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 3 Feb 2017 09:33:13 +0100 Subject: [Freeipa-users] Smart Card login into an Active Directory User In-Reply-To: <20170202140328.HY733.98259.imail@fed1rmwml214> References: <20170202140328.HY733.98259.imail@fed1rmwml214> Message-ID: <20170203083313.GB3552@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewoods at cox.net wrote: > I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a Windows Active Directory server. I am trying to configure the IPA server to allow the Active Directory Users to log into Gnome with a CAC smart card. I?m having a hard time finding any instructions on how to do this. The problem I?m having is the Common Name from the smart card is not getting associated with the Active Directory account. I added the certificate from the smart card to the IPA server by creating a User ID override for the AD user account. I made sure to not use authconfig to configure smart cards and I added ifp to the services line in the sssd.conf file. > > I have the following packages installed: > ipa-admintools.noarch 4.4.0-14.el7_3.4 > ipa-client.x86_64 4.4.0-14.el7_3.4 > ipa-client-common.noarch 4.4.0-14.el7_3.4 > ipa-common.noarch 4.4.0-14.el7_3.4 > ipa-python-compat.noarch 4.4.0-14.el7_3.4 > ipa-server.x86_64 4.4.0-14.el7_3.4 > ipa-server-common.noarch 4.4.0-14.el7_3.4 > ipa-server-dns.noarch 4.4.0-14.el7_3.4 > ipa-server-trust-ad.x86_64 4.4.0-14.el7_3.4 > > I can log in with AD user accounts that are configured with UserName and Passswords, so I know that the integration is working. When I try to log into GDM with my smart card, I don?t get prompted for a PIN number. It only asks for the password from the AD account. Please have a look at the steps described in https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me know if you run into issues. 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 keesb at ghs.com Fri Feb 3 08:45:34 2017 From: keesb at ghs.com (Kees Bakker) Date: Fri, 3 Feb 2017 09:45:34 +0100 Subject: [Freeipa-users] How to enable krb5_child log In-Reply-To: <20170202163225.mfy5buez52gbeuup@hendrix> References: <8b7044c6-2d3f-e4ca-ebf1-e2760620c9b1@ghs.com> <20170202163225.mfy5buez52gbeuup@hendrix> Message-ID: On 02-02-17 17:32, Jakub Hrozek wrote: > On Thu, Feb 02, 2017 at 05:19:07PM +0100, Kees Bakker wrote: >> Hi >> >> Sorry, I did search wherever I could but I couldn't find it. >> How do I enable krb5_child debug log? I'm on an Ubuntu >> system which by default writes an empty /var/log/krb5_child.log >> >> Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What >> do I have to add where to get logging in krb5_child.log? > add debug_level= to the [domain] section. OK. I've done that before with 0x3ff0 , but this time I used level 6 (which I read somewhere as being the old method). And now I see output in krb5_child.log Thanks What's weird though. On another system I'm doing the exactly same. Nothing is logged in krb5_child.log. > >> BTW. I'm trying to debug a problem that results in >> "Invalid UID in persistent keyring" >> The weird thing is, if I become root (via another ssh login) and >> then do a "su - user" (the same user with the error), the problem >> does not show up. Meanwhile that user keeps getting the above >> error (for klist kdestroy, klist). > su as root gets automatically authenticated by the pam_rootok.so > module.. > Hmm. I'm not sure if you understood what I was doing: The "root" way $ ssh root at xyz.example.com # su - someuser $ klist someuser klist: Credentials cache keyring 'persistent:1013:1013' not found $ kinit someuser Password for someuser at EXAMPLE.COM: The latter seems to be working (I can't finish because I don't have that password). Then, at the very same time user "someuser", on his own login, gets this: $ klist klist: Invalid UID in persistent keyring name while getting default ccache One more thing I should mention. It may be of influence. The "someuser" is a local user in /etc/passwd, _and_ it is a user in IPA, with different uid's. Could that trigger the error? -- Kees From jhrozek at redhat.com Fri Feb 3 09:17:23 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 3 Feb 2017 10:17:23 +0100 Subject: [Freeipa-users] How to enable krb5_child log In-Reply-To: References: <8b7044c6-2d3f-e4ca-ebf1-e2760620c9b1@ghs.com> <20170202163225.mfy5buez52gbeuup@hendrix> Message-ID: <20170203091723.jnnq3csm2trheloz@hendrix> On Fri, Feb 03, 2017 at 09:45:34AM +0100, Kees Bakker wrote: > On 02-02-17 17:32, Jakub Hrozek wrote: > > On Thu, Feb 02, 2017 at 05:19:07PM +0100, Kees Bakker wrote: > >> Hi > >> > >> Sorry, I did search wherever I could but I couldn't find it. > >> How do I enable krb5_child debug log? I'm on an Ubuntu > >> system which by default writes an empty /var/log/krb5_child.log > >> > >> Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What > >> do I have to add where to get logging in krb5_child.log? > > add debug_level= to the [domain] section. > > OK. I've done that before with 0x3ff0 , but this time I used level 6 > (which I read somewhere as being the old method). And now I see > output in krb5_child.log > Thanks > > What's weird though. On another system I'm doing the exactly same. > Nothing is logged in krb5_child.log. > > > > >> BTW. I'm trying to debug a problem that results in > >> "Invalid UID in persistent keyring" > >> The weird thing is, if I become root (via another ssh login) and > >> then do a "su - user" (the same user with the error), the problem > >> does not show up. Meanwhile that user keeps getting the above > >> error (for klist kdestroy, klist). > > su as root gets automatically authenticated by the pam_rootok.so > > module.. > > > > Hmm. > I'm not sure if you understood what I was doing: > > The "root" way > $ ssh root at xyz.example.com > # su - someuser As you can see you were not prompted for a password. This is the pam_rootok.so module in action that just flipped the current user to someuser. > $ klist someuser > klist: Credentials cache keyring 'persistent:1013:1013' not found This is expected, since pam_sss.so wasn't invoked because the PAM conversation finished after pam_rootok.so was called. > $ kinit someuser > Password for someuser at EXAMPLE.COM: > The latter seems to be working (I can't finish because I don't have that > password). Then you won't be able to kinit as the user because you need either to know the password or have the keytab to decrypt the KDC response with. > > Then, at the very same time user "someuser", on his own login, gets this: > $ klist > klist: Invalid UID in persistent keyring name while getting default ccache > > One more thing I should mention. It may be of influence. The "someuser" > is a local user in /etc/passwd, _and_ it is a user in IPA, with different uid's. > Could that trigger the error? Yes, if the UID of the local user and the IPA user differ. If you need to use the user from passwd and authenticate the user with his IPA credentials, then you can't use id_provider=ipa in sssd.conf, but id_provider=proxy and auth_provider=krb5. From amitbbhatt1990 at gmail.com Thu Feb 2 17:26:31 2017 From: amitbbhatt1990 at gmail.com (amit bhatt) Date: Thu, 2 Feb 2017 22:56:31 +0530 Subject: [Freeipa-users] FreeIPA installation on centos 7 Message-ID: My QA development setup is running with IPA VERSION: 4.2.0 on centos 7 and I want to install the same version in my production environment as well. however when i am running yum install ipa-server i am getting VERSION: 4.4.0 (package ipa-server-4.4.0-14.el7.centos.4.x86_64) installed. How can i force IPA server to install 4.2.0 and not 4.4.0? Thanks for your help in advance ~Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 3 09:33:05 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 3 Feb 2017 10:33:05 +0100 Subject: [Freeipa-users] FreeIPA installation on centos 7 In-Reply-To: References: Message-ID: amit bhatt wrote: > My QA development setup is running with IPA VERSION: 4.2.0 on centos 7 > and I want to install the same version in my production environment as > well. however when i am running yum install ipa-server i am getting > VERSION: 4.4.0 (package ipa-server-4.4.0-14.el7.centos.4.x86_64) installed. > > How can i force IPA server to install 4.2.0 and not 4.4.0? You'd need to create your own yum repository with the older bits and install from there (or push the packages onto your system and do a local install). Note that the IPA packages are tested against the current versions of the release which means that some packages may be newer and are therefore untested against IPA 4.2.x. Chances are things will work fine but there are no guarantees when mixing packages. rob From keesb at ghs.com Fri Feb 3 09:43:42 2017 From: keesb at ghs.com (Kees Bakker) Date: Fri, 3 Feb 2017 10:43:42 +0100 Subject: [Freeipa-users] How to enable krb5_child log In-Reply-To: <20170203091723.jnnq3csm2trheloz@hendrix> References: <8b7044c6-2d3f-e4ca-ebf1-e2760620c9b1@ghs.com> <20170202163225.mfy5buez52gbeuup@hendrix> <20170203091723.jnnq3csm2trheloz@hendrix> Message-ID: <3ddef783-59a9-9ca9-c2c3-6bf8307ab865@ghs.com> On 03-02-17 10:17, Jakub Hrozek wrote: > On Fri, Feb 03, 2017 at 09:45:34AM +0100, Kees Bakker wrote: >> On 02-02-17 17:32, Jakub Hrozek wrote: >>> On Thu, Feb 02, 2017 at 05:19:07PM +0100, Kees Bakker wrote: >>>> Hi >>>> >>>> Sorry, I did search wherever I could but I couldn't find it. >>>> How do I enable krb5_child debug log? I'm on an Ubuntu >>>> system which by default writes an empty /var/log/krb5_child.log >>>> >>>> Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What >>>> do I have to add where to get logging in krb5_child.log? >>> add debug_level= to the [domain] section. >> OK. I've done that before with 0x3ff0 , but this time I used level 6 >> (which I read somewhere as being the old method). And now I see >> output in krb5_child.log >> Thanks >> >> What's weird though. On another system I'm doing the exactly same. >> Nothing is logged in krb5_child.log. >> >>>> BTW. I'm trying to debug a problem that results in >>>> "Invalid UID in persistent keyring" >>>> The weird thing is, if I become root (via another ssh login) and >>>> then do a "su - user" (the same user with the error), the problem >>>> does not show up. Meanwhile that user keeps getting the above >>>> error (for klist kdestroy, klist). >>> su as root gets automatically authenticated by the pam_rootok.so >>> module.. >>> >> Hmm. >> I'm not sure if you understood what I was doing: >> >> The "root" way >> $ ssh root at xyz.example.com >> # su - someuser > As you can see you were not prompted for a password. This is the > pam_rootok.so module in action that just flipped the current user to > someuser. > >> $ klist someuser >> klist: Credentials cache keyring 'persistent:1013:1013' not found > This is expected, since pam_sss.so wasn't invoked because the PAM > conversation finished after pam_rootok.so was called. Ah, OK. Thanks for clarifying. Learn something new everyday :-) >> $ kinit someuser >> Password for someuser at EXAMPLE.COM: >> The latter seems to be working (I can't finish because I don't have that >> password). > Then you won't be able to kinit as the user because you need either to > know the password or have the keytab to decrypt the KDC response with. Yes, I did expect that. >> Then, at the very same time user "someuser", on his own login, gets this: >> $ klist >> klist: Invalid UID in persistent keyring name while getting default ccache >> >> One more thing I should mention. It may be of influence. The "someuser" >> is a local user in /etc/passwd, _and_ it is a user in IPA, with different uid's. >> Could that trigger the error? > Yes, if the UID of the local user and the IPA user differ. > > If you need to use the user from passwd and authenticate the user with > his IPA credentials, then you can't use id_provider=ipa in sssd.conf, > but id_provider=proxy and auth_provider=krb5. > Thanks, Jakub. I really appreciate your feedback. I'll test what you suggested. -- Kees From sbose at redhat.com Fri Feb 3 10:00:22 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 3 Feb 2017 11:00:22 +0100 Subject: [Freeipa-users] Smart Card login into an Active Directory User In-Reply-To: <20170203083313.GB3552@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20170202140328.HY733.98259.imail@fed1rmwml214> <20170203083313.GB3552@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <20170203100022.GC3552@p.Speedport_W_724V_Typ_A_05011603_00_011> On Fri, Feb 03, 2017 at 09:33:13AM +0100, Sumit Bose wrote: > On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewoods at cox.net wrote: > > I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a Windows Active Directory server. I am trying to configure the IPA server to allow the Active Directory Users to log into Gnome with a CAC smart card. I?m having a hard time finding any instructions on how to do this. The problem I?m having is the Common Name from the smart card is not getting associated with the Active Directory account. I added the certificate from the smart card to the IPA server by creating a User ID override for the AD user account. I made sure to not use authconfig to configure smart cards and I added ifp to the services line in the sssd.conf file. > > > > I have the following packages installed: > > ipa-admintools.noarch 4.4.0-14.el7_3.4 > > ipa-client.x86_64 4.4.0-14.el7_3.4 > > ipa-client-common.noarch 4.4.0-14.el7_3.4 > > ipa-common.noarch 4.4.0-14.el7_3.4 > > ipa-python-compat.noarch 4.4.0-14.el7_3.4 > > ipa-server.x86_64 4.4.0-14.el7_3.4 > > ipa-server-common.noarch 4.4.0-14.el7_3.4 > > ipa-server-dns.noarch 4.4.0-14.el7_3.4 > > ipa-server-trust-ad.x86_64 4.4.0-14.el7_3.4 > > > > I can log in with AD user accounts that are configured with UserName and Passswords, so I know that the integration is working. When I try to log into GDM with my smart card, I don?t get prompted for a PIN number. It only asks for the password from the AD account. > > Please have a look at the steps described in > https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me > know if you run into issues. Please also check if you followed the steps in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html HTH bye, Sumit From keesb at ghs.com Fri Feb 3 13:47:27 2017 From: keesb at ghs.com (Kees Bakker) Date: Fri, 3 Feb 2017 14:47:27 +0100 Subject: [Freeipa-users] How to enable krb5_child log In-Reply-To: <3ddef783-59a9-9ca9-c2c3-6bf8307ab865@ghs.com> References: <8b7044c6-2d3f-e4ca-ebf1-e2760620c9b1@ghs.com> <20170202163225.mfy5buez52gbeuup@hendrix> <20170203091723.jnnq3csm2trheloz@hendrix> <3ddef783-59a9-9ca9-c2c3-6bf8307ab865@ghs.com> Message-ID: <49d0c526-8d75-a84b-37f3-e93889e4e5f4@ghs.com> On 03-02-17 10:43, Kees Bakker wrote: > On 03-02-17 10:17, Jakub Hrozek wrote: >> On Fri, Feb 03, 2017 at 09:45:34AM +0100, Kees Bakker wrote: >> >>> Then, at the very same time user "someuser", on his own login, gets this: >>> $ klist >>> klist: Invalid UID in persistent keyring name while getting default ccache >>> >>> One more thing I should mention. It may be of influence. The "someuser" >>> is a local user in /etc/passwd, _and_ it is a user in IPA, with different uid's. >>> Could that trigger the error? >> Yes, if the UID of the local user and the IPA user differ. >> >> If you need to use the user from passwd and authenticate the user with >> his IPA credentials, then you can't use id_provider=ipa in sssd.conf, >> but id_provider=proxy and auth_provider=krb5. >> > Thanks, Jakub. I really appreciate your feedback. > I'll test what you suggested. Alas, still, no success. :-( -- Kees From dag at sonsorol.org Fri Feb 3 14:54:01 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Fri, 03 Feb 2017 09:54:01 -0500 Subject: [Freeipa-users] Can too many group memberships for an AD user cause SSSD or IPA problems? Message-ID: <58949989.3090301@sonsorol.org> I've got a case where "id @AD-DOMAIN" hangs forever after partially resolving and I think it may because they are in way too many AD groups? The 'id' command resolve the user but hangs before completing. There is a large amount of group data returned from the AD forest for this user and the 'id' command seems to pause/hang right at the 3024th character returned. Looking for pointers / tips. I'm thinking the AD user is in way too many groups but I don't know if this is a real limit or what the limit may be. Any other reason why an 'id' command may start to work but hang before completion for an AD-defined user? Regards, Chris From ivan.lago at futhwo.it Fri Feb 3 14:49:05 2017 From: ivan.lago at futhwo.it (ivan lago) Date: Fri, 3 Feb 2017 15:49:05 +0100 Subject: [Freeipa-users] Trust between freeipa servers of different domains Message-ID: <03B3930E-FF4F-405D-89F0-831F99B57B20@futhwo.it> Hello, Is it possible to configure 2 freeipa servers, serving different domains (let?s sal dom1.com and dom2.com ) to estabilish a trust so that users form one domain can use resources under the control of the other one? And if it is possible, would it be doable to estabilish cross-servers user groups, with users from both the servers? Initially I would be in control of both of servers, so I would be able to do any needed ?hack? on the configuration. Thanks, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Fri Feb 3 15:03:07 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 3 Feb 2017 16:03:07 +0100 Subject: [Freeipa-users] Trust between freeipa servers of different domains In-Reply-To: <03B3930E-FF4F-405D-89F0-831F99B57B20@futhwo.it> References: <03B3930E-FF4F-405D-89F0-831F99B57B20@futhwo.it> Message-ID: On 02/03/2017 03:49 PM, ivan lago wrote: > Hello, > > Is it possible to configure 2 freeipa servers, serving different domains > (let?s sal dom1.com and dom2.com ) to > estabilish a trust so that users form one domain can use resources under > the control of the other one? > And if it is possible, would it be doable to estabilish cross-servers > user groups, with users from both the servers? > > Initially I would be in control of both of servers, so I would be able > to do any needed ?hack? on the configuration. > > Thanks, > > Ivan > > Hi Ivan, there is no IPA-IPA trust functionality implemented. It is on the roadmap but the work on the feature won't start anytime soon. -- Martin^3 Babinsky From deepak.dimri2016 at gmail.com Fri Feb 3 15:40:15 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Fri, 3 Feb 2017 21:10:15 +0530 Subject: [Freeipa-users] FreeIPA installation on centos 7 In-Reply-To: References: Message-ID: Thanks Rob Is there a place/link i can download the release for centos 7? ~Amit On Fri, Feb 3, 2017 at 3:03 PM, Rob Crittenden wrote: > amit bhatt wrote: > >> My QA development setup is running with IPA VERSION: 4.2.0 on centos 7 >> and I want to install the same version in my production environment as >> well. however when i am running yum install ipa-server i am getting >> VERSION: 4.4.0 (package ipa-server-4.4.0-14.el7.centos.4.x86_64) >> installed. >> >> How can i force IPA server to install 4.2.0 and not 4.4.0? >> > > You'd need to create your own yum repository with the older bits and > install from there (or push the packages onto your system and do a local > install). > > Note that the IPA packages are tested against the current versions of the > release which means that some packages may be newer and are therefore > untested against IPA 4.2.x. Chances are things will work fine but there are > no guarantees when mixing packages. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raul at dias.com.br Fri Feb 3 16:04:55 2017 From: raul at dias.com.br (Raul Dias) Date: Fri, 3 Feb 2017 14:04:55 -0200 Subject: [Freeipa-users] client in many IPA domains Message-ID: <32241203-b8ad-822d-3375-50d759b468dc@dias.com.br> Hello, Can ipa-client (e.g., anotebook) be in more than one realm? e.g. depending on the network where it is connected. -rsd -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgb205 at yahoo.com Fri Feb 3 17:26:45 2017 From: pgb205 at yahoo.com (pgb205) Date: Fri, 3 Feb 2017 17:26:45 +0000 (UTC) Subject: [Freeipa-users] ipactl services running, but auth not working In-Reply-To: <91B861CB-5397-40F5-8A8D-771415546C4F@bsd.uchicago.edu> References: <762288497.596207.1486073624507.ref@mail.yahoo.com> <762288497.596207.1486073624507@mail.yahoo.com> <91B861CB-5397-40F5-8A8D-771415546C4F@bsd.uchicago.edu> Message-ID: <745747942.422975.1486142805830@mail.yahoo.com> My problem is with the server itself seemingly not providing services even though it claims to do so. would be curious to know what to look at on freeipa server or how to inrease logging From: "Sullivan, Daniel [CRI]" To: pgb205 Cc: Freeipa-users Sent: Thursday, February 2, 2017 5:16 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 > wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From redbranchwarrior at gmail.com Fri Feb 3 18:21:02 2017 From: redbranchwarrior at gmail.com (Matthew Carter) Date: Fri, 3 Feb 2017 13:21:02 -0500 Subject: [Freeipa-users] Wrong principal in request in NFS mount Message-ID: <7abe45e4-3fbe-cc37-f63f-84b75e9f66ff@gmail.com> So I have two test machines that I set up because of this same problem on my secure offline network. One of the test machines is a server that has FreeIPA and NFS running on it, the other test machine is a client that mounts two NFS shares from the server using krb5i sec. Upon initial install, everything works as it is supposed to. The domain users can log in just fine, the mount mounts perfectly. If I remove the client from the domain using: ipa-client-automount --uninstall ipa-client-install --uninstall And then on the server: ipa-client-automount --uninstall ipa-server-install --uninstall then delete the ca.crt, run sss -E (to clear the sssd caches), rm /tmp/krb5* and then reinstall the server: ipa-server-install service sshd restart kinit admin ipa service-add nfs/server.dar.lan ipa-getkeytab -s server.dar.lan -p host/server.dar.lan -k /etc/krb5.keytab ipa-getkeytab -s server.dar.lan -p nfs/server.dar.lan -k /etc/krb5.keytab ipa-client-automount and reinstall on the client: ipa-client-install ipa-client-automount I believe I now have the same setup as I had before. I can kinit and get a ticket: Ticket cache: FILE:/tmp/krb5cc_615200000_TinxaO Default principal: admin at DAR.LAN Valid starting Expires Service principal 02/03/17 12:54:02 02/04/17 12:53:59 krbtgt/DAR.LAN at DAR.LAN My domain users can log in to their desktops. But I can't mount the shares. I get: mount.nfs4: timeout set for Fri Feb 3 12:58:36 2017 mount.nfs4: trying text-based options 'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting server:/NFS_SHARE/USERS mount.nfs4: timeout set for Fri Feb 3 12:58:36 2017 mount.nfs4: trying text-based options 'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting server:/NFS_SHARE/admin Originally I chased permissions, but when I started looking at /var/log/messages on the server, I noticed that rpcgssd was complaining about a wrong principal. On the server I executed kadmin.local and then listprincs K/M at DAR.LAN krbtgt/DAR.LAN at DAR.LAN kadmin/server.dar.lan at DAR.LAN kadmin/admin at DAR.LAN kadmin/changepw at DAR.LAN ldap/server.dar.lan at DAR.LAN host/server.dar.lan at DAR.LAN HTTP/server.dar.lan at DAR.LAN nfs/server.dar.lan at DAR.LAN s_sharkey at DAR.LAN host/as1.dar.lan at DAR.LAN and then a getprinc on nfs/server.dar.lan at DAR.LAN: Principal: nfs/server.dar.lan at DAR.LAN Expiration date: [never] Last password change: Thu Feb 02 15:31:24 EST 2017 Password expiration date: [none] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Thu Feb 02 15:31:24 EST 2017 (nfs/server.dar.lan at DAR.LAN) Last successful authentication: Thu Feb 02 16:52:16 EST 2017 Last failed authentication: Fri Feb 03 12:09:14 EST 2017 Failed password attempts: 1 Number of keys: 4 Key: vno 3, aes256-cts-hmac-sha1-96, no salt Key: vno 3, aes128-cts-hmac-sha1-96, no salt Key: vno 3, des3-cbc-sha1, no salt Key: vno 3, arcfour-hmac, no salt MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] looking at my keytab, klist -ke /etc/krb5.keytab 1 2 host/server.dar.lan at DAR.LAN 2 1 nfs/server.dar.lan at DAR.LAN 3 3 host/server.dar.lan at DAR.LAN 4 3 host/server.dar.lan at DAR.LAN 5 3 host/server.dar.lan at DAR.LAN 6 3 host/server.dar.lan at DAR.LAN 7 2 nfs/server.dar.lan at DAR.LAN 8 2 nfs/server.dar.lan at DAR.LAN 9 2 nfs/server.dar.lan at DAR.LAN 10 2 nfs/server.dar.lan at DAR.LAN I saw I had two extra older kt's so I used kadmin.local to remove them with modprinc. Not sure where they came from. . . I again tried to mount, this time using -vvv in /etc/sysconfig/nfs for rpcgssd, rpcsvcgssd, and rpcbind and /var/log/messages output this on the server (I'll only paste the data from one mount attempt as there is two mounts and they're complaining identically.): Feb 3 12:25:32 server rpc.svcgssd[4796]: leaving poll Feb 3 12:25:32 server rpc.svcgssd[4796]: handling null request Feb 3 12:25:32 server rpc.svcgssd[4796]: svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 enctypes from the kernel Feb 3 12:25:32 server rpc.svcgssd[4796]: WARNING: gss_accept_sec_context failed Feb 3 12:25:32 server rpc.svcgssd[4796]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Feb 3 12:25:32 server rpc.svcgssd[4796]: sending null reply Feb 3 12:25:32 server rpc.svcgssd[4796]: writing message: \x \x6082025f06092a864886f71201020201006e82024e3082024aa003020105a10302010ea20703050020000000a382015a6182015630820152a003020105a1091b074441522e4c414ea220301ea003020103a11730151b036e66731b0e7365727665722e6461722e6c616ea382011c30820118a003020112a103020103a282010a048201063acb411e685126d45ffc67763e9d9fb3eaa42765e44ad17b924d930583f95f8169980758f7d7ac59b5668c40a6a4c0aadee0e4a655a29343e09b69922cf65e2bf639b30fa764d415d3e1207da584b0d3d4ffb668d0d6fbcf52a7eed73cf9f51dd777096647e13931c30a6929115f8d1244086a78fa35fbe4073c195be3f49ba34ffe04bd3ae0bba9f8d9713d931f129fa0087872514f5aa4b0f933549b27cd45bcda4460d562b9b9dec90e5d358d6824aad6e46f50bbd03b35ac80df8b65f771bacf3ab7c96336f3051833d11fe283506a20c3eeae9d7df743a634e9928443cafb088a2adb083d2fa32eec78934a27e7d3358a451dd5ba36a94a5fdeb255aa5e884230069bdda481d63081d3a003020112a281cb0481c802b37853075fe8f79de1d93289e493dd95e7724a050d44cc629521c0a1504d2a33589d4e13c4941a9451b4d2cfb74129ac2943664b9adb01b89d8746fd531c251fbe87660c9305d73a18fb3166907ac85a0c38fe59b475899f0f69b4193311cab6ed19ca0ce1f2a0dfc7b7a04d2bb1195406dc6d846f3535db5c083ade0a4dfa0c5d4466ee10fd04d72325192fd8473e05d0318b390d6c87c440ca5eabdc3017fec828c29543b3414fac312b597e0ea4726cb33fe825feef00527e14d5f426cc7781dcd3dd0a0969 1486142792 851968 2529639056 \x \x REPEATED 3x . . . Feb 3 12:25:32 server rpc.svcgssd[4796]: finished handling null request Feb 3 12:25:32 server audispd: node=server type=SYSCALL msg=audit(1486142732.066:592): arch=c000003e syscall=87 success=yes exit=0 a0=2110480 a1=c2 a2=1a a3=f items=2 ppid=1 pid=4525 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gnome-terminal" exe="/usr/bin/gnome-terminal" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="delete" Feb 3 12:25:32 server audispd: node=server type=CWD msg=audit(1486142732.066:592): cwd="/home/adminnt" Feb 3 12:25:32 server rpc.svcgssd[4796]: entering poll Feb 3 12:25:34 as1 audispd: node=as1 type=SYSCALL msg=audit(1486142734.451:79839): arch=c000003e syscall=165 success=no exit=-13 a0=7ffcb5014564 a1=7f00d8823ea0 a2=7f00d72133f6 a3=0 items=17 ppid=7132 pid=7133 auid=615200000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="mount.nfs4" exe="/sbin/mount.nfs" subj=unconfined_u:unconfined_r:unconfined_mount_t:s0-s0:c0.c1023 key="export" Feb 3 12:25:34 as1 audispd: node=as1 type=CWD msg=audit(1486142734.451:79839): cwd="/usr" Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=0 name="/NFS_SHARE" inode=654083 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 nametype=NORMAL Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=1 name=(null) inode=103 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=NORMAL Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=2 name=(null) inode=103 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=3 name=(null) inode=280 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=4 name=(null) inode=280 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=5 name=(null) inode=281 dev=00:12 mode=0100400 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=6 name=(null) inode=280 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=7 name=(null) inode=282 dev=00:12 mode=010600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=8 name=(null) inode=280 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=9 name=(null) inode=283 dev=00:12 mode=010600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=10 name=(null) inode=280 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=11 name=(null) inode=284 dev=00:12 mode=010600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=12 name=(null) inode=103 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=NORMAL Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=13 name=(null) inode=103 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=14 name=(null) inode=285 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=15 name=(null) inode=285 dev=00:12 mode=040555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT Feb 3 12:25:34 as1 audispd: node=as1 type=PATH msg=audit(1486142734.451:79839): item=16 name=(null) inode=286 dev=00:12 mode=0100400 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE I apoligize for the wall o' words, but you know how log files can be. So my setup naming conventions is exactly as during the initial install which worked. The config files shouldn't have changed. It seems as if the principal name, KVNO, and the keytab match up. Did something not get cleaned properly? Currently I can mount just fine without krb5i security, but my Govt STIG requires it for NFS mounts and I'm stuck. Thanks for any help! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsullivan2 at bsd.uchicago.edu Fri Feb 3 19:47:31 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Fri, 3 Feb 2017 19:47:31 +0000 Subject: [Freeipa-users] ipactl services running, but auth not working In-Reply-To: <745747942.422975.1486142805830@mail.yahoo.com> References: <762288497.596207.1486073624507.ref@mail.yahoo.com> <762288497.596207.1486073624507@mail.yahoo.com> <91B861CB-5397-40F5-8A8D-771415546C4F@bsd.uchicago.edu> <745747942.422975.1486142805830@mail.yahoo.com> Message-ID: <70FBEC28-08EF-423C-A7CA-133775DA6520@bsd.uchicago.edu> What exactly are you seeing to determine that the server is actually failing? Is it not possible that sssd (the client) is timing out? Will 389ds service an LDAP request, i.e. can you run ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" "(objectclass=*)? What exactly are you trying to do? Just password authentication to an sssd client? Are you operating in a trusted AD environment? Dan On Feb 3, 2017, at 11:26 AM, pgb205 > wrote: My problem is with the server itself seemingly not providing services even though it claims to do so. would be curious to know what to look at on freeipa server or how to inrease logging ________________________________ From: "Sullivan, Daniel [CRI]" > To: pgb205 > Cc: Freeipa-users > Sent: Thursday, February 2, 2017 5:16 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 >> wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project From spammewoods at cox.net Fri Feb 3 20:59:26 2017 From: spammewoods at cox.net (spammewoods at cox.net) Date: Fri, 3 Feb 2017 12:59:26 -0800 Subject: [Freeipa-users] Smart Card login into an Active Directory User In-Reply-To: Message-ID: <20170203155926.9ZD85.121757.imail@fed1rmwml303> ---- Sumit Bose wrote: > On Fri, Feb 03, 2017 at 09:33:13AM +0100, Sumit Bose wrote: > On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewoods at cox.net wrote: > > I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a Windows Active Directory server. I am trying to configure the IPA server to allow the Active Directory Users to log into Gnome with a CAC smart card. I?m having a hard time finding any instructions on how to do this. The problem I?m having is the Common Name from the smart card is not getting associated with the Active Directory account. I added the certificate from the smart card to the IPA server by creating a User ID override for the AD user account. I made sure to not use authconfig to configure smart cards and I added ifp to the services line in the sssd.conf file. > > > > I have the following packages installed: > > ipa-admintools.noarch 4.4.0-14.el7_3.4 > > ipa-client.x86_64 4.4.0-14.el7_3.4 > > ipa-client-common.noarch 4.4.0-14.el7_3.4 > > ipa-common.noarch 4.4.0-14.el7_3.4 > > ipa-python-compat.noarch 4.4.0-14.el7_3.4 > > ipa-server.x86_64 4.4.0-14.el7_3.4 > > ipa-server-common.noarch 4.4.0-14.el7_3.4 > > ipa-server-dns.noarch 4.4.0-14.el7_3.4 > > ipa-server-trust-ad.x86_64 4.4.0-14.el7_3.4 > > > > I can log in with AD user accounts that are configured with UserName and Passswords, so I know that the integration is working. When I try to log into GDM with my smart card, I don?t get prompted for a PIN number. It only asks for the password from the AD account. > > Please have a look at the steps described in > https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me > know if you run into issues. Please also check if you followed the steps in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html HTH bye, Sumit -- Hello Sumit, I followed the instructions in comment #9. I modified the /etc/pam.d/smartcard-auth file and the two files that are under /etc/dconf/db/distro.d/. But it still doesn't work. GDM will prompt me for a password not the PIN when I plug in the smart card. Do I need to run "authconfig --enablesmartcard --smartcardmodule=no_module --update" before I change the files ? Should I remove pam_pkcs11 too ? I have been able to get AD smart card login working using standard authconfig, pam_pkcs11, and the cn_map. I just don't want to use the cn_map file and have to list all of my user's "Common Names" in this file. From pgb205 at yahoo.com Fri Feb 3 22:11:03 2017 From: pgb205 at yahoo.com (pgb205) Date: Fri, 3 Feb 2017 22:11:03 +0000 (UTC) Subject: [Freeipa-users] ipactl services running, but auth not working In-Reply-To: <70FBEC28-08EF-423C-A7CA-133775DA6520@bsd.uchicago.edu> References: <762288497.596207.1486073624507.ref@mail.yahoo.com> <762288497.596207.1486073624507@mail.yahoo.com> <91B861CB-5397-40F5-8A8D-771415546C4F@bsd.uchicago.edu> <745747942.422975.1486142805830@mail.yahoo.com> <70FBEC28-08EF-423C-A7CA-133775DA6520@bsd.uchicago.edu> Message-ID: <284778203.607162.1486159863488@mail.yahoo.com> there are reports from multiple clients being unable to authenticate. ipactl status shows all services as running.The problem is fixed when I 'ipactl restart'. From: "Sullivan, Daniel [CRI]" To: pgb205 Cc: Freeipa-users Sent: Friday, February 3, 2017 2:47 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working What exactly are you seeing to determine that the server is actually failing?? Is it not possible that sssd (the client) is timing out?? Will 389ds service an LDAP request, i.e. can you run ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" "(objectclass=*)? What exactly are you trying to do?? Just password authentication to an sssd client?? Are you operating in a trusted AD environment? Dan On Feb 3, 2017, at 11:26 AM, pgb205 > wrote: My problem is with the server itself seemingly not providing services even though it claims to do so. would be curious to know what to look at on freeipa server or how to inrease logging ________________________________ From: "Sullivan, Daniel [CRI]" > To: pgb205 > Cc: Freeipa-users > Sent: Thursday, February 2, 2017 5:16 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 >> wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Sat Feb 4 09:21:39 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Sat, 4 Feb 2017 14:51:39 +0530 Subject: [Freeipa-users] IPA replica setup for version 4.4 Message-ID: I am trying to install ipa replica but getting below error when running ipa-replica-install i am following below link for ipa 4.4: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html Run connection check to master ipa.ipapython.install.cli.install_tool(Replica): ERROR Connection check failed! Please fix your network settings according to error messages above What could be reason for this error? Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sat Feb 4 11:48:29 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sat, 4 Feb 2017 12:48:29 +0100 Subject: [Freeipa-users] Can too many group memberships for an AD user cause SSSD or IPA problems? In-Reply-To: <58949989.3090301@sonsorol.org> References: <58949989.3090301@sonsorol.org> Message-ID: <20170204114829.canfub7juexwwquo@hendrix> On Fri, Feb 03, 2017 at 09:54:01AM -0500, Chris Dagdigian wrote: > > I've got a case where "id @AD-DOMAIN" hangs forever after partially > resolving and I think it may because they are in way too many AD groups? I don't think id should hang totally (at the very least, there is a NSS timeout that should eventually kick in). > > The 'id' command resolve the user but hangs before completing. There is a > large amount of group data returned from the AD forest for this user and the > 'id' command seems to pause/hang right at the 3024th character returned. > > Looking for pointers / tips. I'm thinking the AD user is in way too many > groups but I don't know if this is a real limit or what the limit may be. > Any other reason why an 'id' command may start to work but hang before > completion for an AD-defined user? I would tail the sssd logs on the client and server to see if the command really hangs or 'just' processes some super-large group. Also, see: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ From deepak.dimri2016 at gmail.com Sat Feb 4 12:16:18 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Sat, 4 Feb 2017 17:46:18 +0530 Subject: [Freeipa-users] VERSION: 4.4.0, IPA Replica DOES NOT Work Message-ID: I am wondering Does IPA Replica as standalone without IPA Master being up works for you guys? Mine and my collogue IPA setup in our own Dev environment with VERSION: 4.2 works perfectly fine. but now when we are moving to staging env we are getting IPA version VERSION: 4.4.0, API_VERSION: 2.213 installed through yum in centos 7 and replica now DOES NOT WORK as standalone unit. We either keep getting GATEWAY_TIMEOUT Error on the browser or its taking hell lot of time to fetch user and host objects from Replica DS. The moment we bring up our IPA Server up replica also starts working fine. I am not sure but unfortunately there is no helpful reply i am getting on this issue and wondering if any one else is having TIMEOUT issue with replica with version 4.4? Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsullivan2 at bsd.uchicago.edu Sat Feb 4 20:45:03 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Sat, 4 Feb 2017 20:45:03 +0000 Subject: [Freeipa-users] ipactl services running, but auth not working In-Reply-To: <284778203.607162.1486159863488@mail.yahoo.com> References: <762288497.596207.1486073624507.ref@mail.yahoo.com> <762288497.596207.1486073624507@mail.yahoo.com> <91B861CB-5397-40F5-8A8D-771415546C4F@bsd.uchicago.edu> <745747942.422975.1486142805830@mail.yahoo.com> <70FBEC28-08EF-423C-A7CA-133775DA6520@bsd.uchicago.edu> <284778203.607162.1486159863488@mail.yahoo.com> Message-ID: <0382061C-D0E6-47EE-8D1F-A85F17B18CFF@bsd.uchicago.edu> I understand that there are reports from the client being unable to authenticate but what do the actual sssd logs say from the client, and from the server? When the problem occurs just point a client to the DC directly (instead of using _srv_ for example). Have you looked in /var/log/messages or ran dmesg on the server? Maybe something is dying because the system is running out of memory. Is it swapping? High CPU load? Is it responding to LDAP queries (see my previous email)? I still don?t know what you are actually trying to do really (i.e. is it just password authentication with sssd, are you using smart cards, kerberized sessions, is there an AD domain involved, etc?). IPA is a suite of different components that work together having an understanding of what you are doing and what your environment looks like is really important if you need help. Dan On Feb 3, 2017, at 4:11 PM, pgb205 > wrote: there are reports from multiple clients being unable to authenticate. ipactl status shows all services as running. The problem is fixed when I 'ipactl restart'. ________________________________ From: "Sullivan, Daniel [CRI]" > To: pgb205 > Cc: Freeipa-users > Sent: Friday, February 3, 2017 2:47 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working What exactly are you seeing to determine that the server is actually failing? Is it not possible that sssd (the client) is timing out? Will 389ds service an LDAP request, i.e. can you run ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" "(objectclass=*)? What exactly are you trying to do? Just password authentication to an sssd client? Are you operating in a trusted AD environment? Dan On Feb 3, 2017, at 11:26 AM, pgb205 >> wrote: My problem is with the server itself seemingly not providing services even though it claims to do so. would be curious to know what to look at on freeipa server or how to inrease logging ________________________________ From: "Sullivan, Daniel [CRI]" >> To: pgb205 >> Cc: Freeipa-users >> Sent: Thursday, February 2, 2017 5:16 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 >>>> wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project From rakesh.rajasekharan at gmail.com Sun Feb 5 14:17:43 2017 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Sun, 5 Feb 2017 19:47:43 +0530 Subject: [Freeipa-users] freeipa hostbased auth "connection closed" Message-ID: Hi, I am running a freeipa server version 4.4.0 and have setup hbac rules which work fine However, just on one single host , I am seeing this issue wherein it is not allowing me ssh access. When I check my hbac permissions.. it say access granted but on trying to login.. it blocks me On the Freeipa server ipa hbactest --user=p-testhbac --host=>my-test-host> --service=sshd -------------------- Access granted: True -------------------- Matched rules: ipa-alluser-access Not matched rules: ipa-alluser-sudo-access On the client I get this message while doing an ssh "Connection closed by 10.0.30.28". In /var/log/secure I see these messages Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.4.6 user=p-testhbac Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:account): Access denied for user p-testhbac: 4 (System error) Feb 5 13:57:41 10 sshd[26692]: Failed password for p-testhbac from 10.0.4.6 port 40540 ssh2 Feb 5 13:57:41 10 sshd[26692]: fatal: Access denied for user p-testhbac by PAM account configuration [preauth] /var/log/sssd/sssd_domain.log I see this error at the end, (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): DP Request [PAM SELinux #13]: Request removed. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #12]: Sending result [4][mydomain.com] (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [child_sig_handler] (0x1000): Waiting for child [26795]. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [child_sig_handler] (0x0020): child [26795] failed with status [1]. But few lines above.. I see that I was allowed in by the hbac rule. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [hbac_evaluate] (0x0100): ALLOWED by rule [ipa-alluser-access]. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [hbac_evaluate] (0x0100): hbac_evaluate() >] (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [ipa-alluser-access] (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_done] (0x0400): DP Request [PAM Account #12]: Request handler finished [0]: Success (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [_dp_req_recv] (0x0400): DP Request [PAM Account #12]: Receiving request data. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): DP Request [PAM Account #12]: Request removed.I was allowed in per the HBAC rule Not sure whats blocking me.. Thanks Rakesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsullivan2 at bsd.uchicago.edu Sun Feb 5 14:21:02 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Sun, 5 Feb 2017 14:21:02 +0000 Subject: [Freeipa-users] freeipa hostbased auth "connection closed" In-Reply-To: References: Message-ID: <472868D2-5A46-469E-BC24-3A9256D90A53@bsd.uchicago.edu> Did you check /var/log/messages and /var/log/secure? I think I?ve seen problems with hosts.allow/hosts.deny dump output in there. Dan On Feb 5, 2017, at 8:17 AM, Rakesh Rajasekharan > wrote: Hi, I am running a freeipa server version 4.4.0 and have setup hbac rules which work fine However, just on one single host , I am seeing this issue wherein it is not allowing me ssh access. When I check my hbac permissions.. it say access granted but on trying to login.. it blocks me On the Freeipa server ipa hbactest --user=p-testhbac --host=>my-test-host> --service=sshd -------------------- Access granted: True -------------------- Matched rules: ipa-alluser-access Not matched rules: ipa-alluser-sudo-access On the client I get this message while doing an ssh "Connection closed by 10.0.30.28". In /var/log/secure I see these messages Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.4.6 user=p-testhbac Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:account): Access denied for user p-testhbac: 4 (System error) Feb 5 13:57:41 10 sshd[26692]: Failed password for p-testhbac from 10.0.4.6 port 40540 ssh2 Feb 5 13:57:41 10 sshd[26692]: fatal: Access denied for user p-testhbac by PAM account configuration [preauth] /var/log/sssd/sssd_domain.log I see this error at the end, (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): DP Request [PAM SELinux #13]: Request removed. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #12]: Sending result [4][mydomain.com] (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [child_sig_handler] (0x1000): Waiting for child [26795]. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [child_sig_handler] (0x0020): child [26795] failed with status [1]. But few lines above.. I see that I was allowed in by the hbac rule. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [hbac_evaluate] (0x0100): ALLOWED by rule [ipa-alluser-access]. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [hbac_evaluate] (0x0100): hbac_evaluate() >] (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [ipa-alluser-access] (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_done] (0x0400): DP Request [PAM Account #12]: Request handler finished [0]: Success (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [_dp_req_recv] (0x0400): DP Request [PAM Account #12]: Receiving request data. (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): DP Request [PAM Account #12]: Request removed.I was allowed in per the HBAC rule Not sure whats blocking me.. Thanks Rakesh -- 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 dsullivan2 at bsd.uchicago.edu Sun Feb 5 14:22:58 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Sun, 5 Feb 2017 14:22:58 +0000 Subject: [Freeipa-users] freeipa hostbased auth "connection closed" In-Reply-To: <472868D2-5A46-469E-BC24-3A9256D90A53@bsd.uchicago.edu> References: <472868D2-5A46-469E-BC24-3A9256D90A53@bsd.uchicago.edu> Message-ID: Also, check your ssshd configuration, there might be some restriction in there. Dan > On Feb 5, 2017, at 8:21 AM, Sullivan, Daniel [CRI] wrote: > > Did you check /var/log/messages and /var/log/secure? I think I?ve seen problems with hosts.allow/hosts.deny dump output in there. > > Dan > > On Feb 5, 2017, at 8:17 AM, Rakesh Rajasekharan > wrote: > > Hi, > > I am running a freeipa server version 4.4.0 and have setup hbac rules which work fine > > However, just on one single host , I am seeing this issue wherein it is not allowing me ssh access. > When I check my hbac permissions.. it say access granted but on trying to login.. it blocks me > > On the Freeipa server > ipa hbactest --user=p-testhbac --host=>my-test-host> --service=sshd > > -------------------- > Access granted: True > -------------------- > Matched rules: ipa-alluser-access > Not matched rules: ipa-alluser-sudo-access > > On the client I get this message while doing an ssh "Connection closed by 10.0.30.28". > > In /var/log/secure I see these messages > Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.4.6 user=p-testhbac > Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:account): Access denied for user p-testhbac: 4 (System error) > Feb 5 13:57:41 10 sshd[26692]: Failed password for p-testhbac from 10.0.4.6 port 40540 ssh2 > Feb 5 13:57:41 10 sshd[26692]: fatal: Access denied for user p-testhbac by PAM account configuration [preauth] > > /var/log/sssd/sssd_domain.log I see this error at the end, > > > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): DP Request [PAM SELinux #13]: Request removed. > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #12]: Sending result [4][mydomain.com] > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [child_sig_handler] (0x1000): Waiting for child [26795]. > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [child_sig_handler] (0x0020): child [26795] failed with status [1]. > > > > But few lines above.. I see that I was allowed in by the hbac rule. > > > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [hbac_evaluate] (0x0100): ALLOWED by rule [ipa-alluser-access]. > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [hbac_evaluate] (0x0100): hbac_evaluate() >] > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [ipa-alluser-access] > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_done] (0x0400): DP Request [PAM Account #12]: Request handler finished [0]: Success > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [_dp_req_recv] (0x0400): DP Request [PAM Account #12]: Receiving request data. > (Sun Feb 5 13:57:41 2017) [sssd[be[mydomain.com]]] [dp_req_destructor] (0x0400): DP Request [PAM Account #12]: Request removed.I was allowed in per the HBAC rule > > > Not sure whats blocking me.. > > > Thanks > Rakesh > > -- > 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 jhrozek at redhat.com Sun Feb 5 21:18:34 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 5 Feb 2017 22:18:34 +0100 Subject: [Freeipa-users] freeipa hostbased auth "connection closed" In-Reply-To: References: Message-ID: <20170205211834.jvfqwjjm7ztjpdbf@hendrix> On Sun, Feb 05, 2017 at 07:47:43PM +0530, Rakesh Rajasekharan wrote: > Hi, > > I am running a freeipa server version 4.4.0 and have setup hbac rules which > work fine > > However, just on one single host , I am seeing this issue wherein it is not > allowing me ssh access. > When I check my hbac permissions.. it say access granted but on trying to > login.. it blocks me > > On the Freeipa server > ipa hbactest --user=p-testhbac --host=>my-test-host> --service=sshd > > -------------------- > Access granted: True > -------------------- > Matched rules: ipa-alluser-access > Not matched rules: ipa-alluser-sudo-access > > On the client I get this message while doing an ssh "Connection closed by > 10.0.30.28". > > In /var/log/secure I see these messages > Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:auth): authentication success; > logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.4.6 user=p-testhbac > Feb 5 13:57:41 10 sshd[26692]: pam_sss(sshd:account): Access denied for > user p-testhbac: 4 (System error) If SSSD throws a System Error, you really need to look into SSSD's logs -- System Error is kind of an unhandled exception in SSSD's code. > Feb 5 13:57:41 10 sshd[26692]: Failed password for p-testhbac from > 10.0.4.6 port 40540 ssh2 From datakid at gmail.com Sun Feb 5 21:59:37 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Mon, 6 Feb 2017 08:59:37 +1100 Subject: [Freeipa-users] FreeIPA installation on centos 7 In-Reply-To: References: Message-ID: On 4 February 2017 at 02:40, deepak dimri wrote: > Thanks Rob > > Is there a place/link i can download the release for centos 7? > > Amit, You can get them from the vault: http://vault.centos.org/7.2.1511/updates/x86_64/Packages/ I've still not done a comprehensive test, but the tests I have done show sssd 1.14 working nicely (ie, as expected) with 4.4.0, *after* an upgrade from 4.2.0. Cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper > ~Amit > > On Fri, Feb 3, 2017 at 3:03 PM, Rob Crittenden > wrote: > >> amit bhatt wrote: >> >>> My QA development setup is running with IPA VERSION: 4.2.0 on centos 7 >>> and I want to install the same version in my production environment as >>> well. however when i am running yum install ipa-server i am getting >>> VERSION: 4.4.0 (package ipa-server-4.4.0-14.el7.centos.4.x86_64) >>> installed. >>> >>> How can i force IPA server to install 4.2.0 and not 4.4.0? >>> >> >> You'd need to create your own yum repository with the older bits and >> install from there (or push the packages onto your system and do a local >> install). >> >> Note that the IPA packages are tested against the current versions of the >> release which means that some packages may be newer and are therefore >> untested against IPA 4.2.x. Chances are things will work fine but there are >> no guarantees when mixing packages. >> >> 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 >> > > > -- > 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 th at casalogic.dk Mon Feb 6 07:59:20 2017 From: th at casalogic.dk (Troels Hansen) Date: Mon, 6 Feb 2017 08:59:20 +0100 (CET) Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> Message-ID: <1359190682.1911254.1486367960580.JavaMail.zimbra@casalogic.dk> Hi I'm aware of the anatomy of how the lookup is done, but I would suppose a valid cache on the IPA server would result in the cache from the IPA server being used? I have been debugging this issue some more, and can confirm is the client have its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid cache, when the client asks for the user, the IPA server still asks the AD for the entire group info? I can see, that even though the cache is refreshed the attribute initgrExpireTimestamp (in the ldb cache) isn't updated. I have been unable to find out exactly what this controls? lastUpdate and dataExpireTimestamp is updated to the time stamp of when the refresh ran. ----- On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: > Have you checked to see if the user is expired in the cache, or if it is > impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry > timeout is only 90 minutes and entry_cache_nowait_percentage default is 50. > > ldbsearch -H /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb > > ~/timestamps.txt > ldbsearch -H /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt > > Might be able to provide more info. > > Again, I?d really familiarize yourself with the anatomy of an sssd lookup, if > you get to know the diagram and steps 1-7 here it will be a big help to your > question(s). > https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ > > Dan > > >> On Feb 1, 2017, at 4:32 AM, Troels Hansen wrote: >> >>> From looking af at TCP dump, I can see that if a client requests a AD user from >>> IPA, IPA does a full user lookup in AD, even though the IPA server have the >>> user in local cache? >> >> It looks like a single group generates a LOT of traffic to AD like: >> client -> IPA >> IPA -> client >> IPA -> AD >> AD -> IPA >> IPA -> AD >> IPA -> Second AD >> Second AD -> IPA >> IPA -> Second AD >> IPA -> AD >> AD -> IPA >> IPA -> AD >> IPA -> client >> client -> IPA >> IPA -> Client >> >> Something similar continues for every group the user has. >> >> Soo, I guess the question that I haven't been able to find documented anywhere. >> Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd >> client requests a user? >> >> >> >> ----- On Feb 1, 2017, at 9:53 AM, Troels Hansen th at casalogic.dk wrote: >> >>> Hmm, suspect its happening on the server...... thous I haven't been able to >>> pinpoint a log entry that confirms my suspecting. >>> >>> I have pinpointed the timeout to happen after 58 seconds after completely >>> removing the SSSD cache and restaring SSSD, which leads me to think my issue is >>> related to ldap_enumaration_search_timeout which defaults to 60. >>> >>> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja >>> >>> However, I'm unable to crank it up on the server as it seems to be adjusted Down >>> to 60 Again? >>> >>> Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option >>> ldap_enumeration_search_timeout has value 120 >>> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >>> Option ldap_enumeration_search_timeout has value 60 >>> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >>> Option ldap_enumeration_search_timeout has value 60 >>> >>> LDAP seems speedy enough, not timeouts while querying it manually while a client >>> is doing a user lookup. >>> >>> ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] >>> dsullivan2 at bsd.uchicago.edu wrote: >>> >>>> >>>> If the timeout is occurring on the server, I would start by increasing one or >>>> both of these values: >>>> >>>> ldap_opt_timeout >>>> ldap_search_timeout >>>> >>>> If that doesn?t work I?d take look to see if the 389 server is under high load >>>> when you are performing this operation. The easiest way I have found to do >>>> this is to just execute an LDAP query directly against the IPA server when you >>>> are performing an id lookup, for example: >>>> >>>> ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" >>>> "(objectclass=*)? >>>> >>>> If the LDAP server is not responsive you probably need to increase the number of >>>> worker threads for 389ds. Also, you might want to disable referrals, check out >>>> the man pages for this; >>>> >>>> ldap_referrals = false >>>> >>>> Also, FWIW, if you crank up debug logging on the sssd client, you should be able >>>> to see the amount of seconds of timeout assigned to the operation, and witness >>>> the fact that the operation is actually timing out by inspecting the logs >>>> themselves. The logs can get a little verbose but the data is there. >>>> >>> >>> -- >>> 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 >> >> -- >> Med venlig hilsen >> >> Troels Hansen >> >> Systemkonsulent >> >> Casalogic A/S >> >> >> T (+45) 70 20 10 63 >> >> M (+45) 22 43 71 57 >> >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >> meget mere. >> >> -- >> 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From abokovoy at redhat.com Mon Feb 6 08:52:35 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 6 Feb 2017 10:52:35 +0200 Subject: [Freeipa-users] VERSION: 4.4.0, IPA Replica DOES NOT Work In-Reply-To: References: Message-ID: <20170206085235.uk5af6ykv4l334rr@redhat.com> On la, 04 helmi 2017, deepak dimri wrote: >I am wondering Does IPA Replica as standalone without IPA Master being up >works for you guys? Mine and my collogue IPA setup in our own Dev >environment with VERSION: 4.2 works perfectly fine. but now when we are >moving to staging env we are getting IPA version VERSION: 4.4.0, >API_VERSION: 2.213 installed through yum in centos 7 and replica now DOES >NOT WORK as standalone unit. > >We either keep getting GATEWAY_TIMEOUT Error on the browser or its taking >hell lot of time to fetch user and host objects from Replica DS. The moment >we bring up our IPA Server up replica also starts working fine. > >I am not sure but unfortunately there is no helpful reply i am getting on >this issue and wondering if any one else is having TIMEOUT issue with >replica with version 4.4? I have a hard time understanding what exactly you are trying to do and what 'standalone IPA replica without IPA master' means. Could you please show a sequence of operations you tried to perform? -- / Alexander Bokovoy From mbasti at redhat.com Mon Feb 6 10:57:56 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 6 Feb 2017 11:57:56 +0100 Subject: [Freeipa-users] IPA replica setup for version 4.4 In-Reply-To: References: Message-ID: <65b05854-fe18-6c6a-fe09-565e0b361879@redhat.com> On 04.02.2017 10:21, deepak dimri wrote: > I am trying to install ipa replica but getting below error when > running ipa-replica-install > > i am following below link for ipa 4.4: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html > > > Run connection check to master > ipa.ipapython.install.cli.install_tool(Replica): ERROR Connection > check failed! > Please fix your network settings according to error messages above > > > What could be reason for this error? > > Thanks, > Deepak > > > Hello, this can be caused by firewall IMO. Could you provide ipareplica-install.log ? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Mon Feb 6 11:16:58 2017 From: dkupka at redhat.com (David Kupka) Date: Mon, 6 Feb 2017 12:16:58 +0100 Subject: [Freeipa-users] client in many IPA domains In-Reply-To: <32241203-b8ad-822d-3375-50d759b468dc@dias.com.br> References: <32241203-b8ad-822d-3375-50d759b468dc@dias.com.br> Message-ID: <20170206111657.GA10018@dkupka.usersys.redhat.com> On Fri, Feb 03, 2017 at 02:04:55PM -0200, Raul Dias wrote: > Hello, > > Can ipa-client (e.g., anotebook) be in more than one realm? e.g. depending > on the network where it is connected. > > -rsd > > -- > 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 Hello! It depends what are you expectation about features that will be available on such client. If you just want to be able to obtain Kerberos ticket for a user on the client it will work even without FreeIPA (assuming DNS records for Kerberos are in place). Enrolling the client to two FreeIPA domains is theoretically doable but: a) would require some experimentation and manual tinkering, b) may bring security issues (e.g. sharing the same Kerberos key with both domains), c) will likely result in weird behavior, d) is definitelly not supported nor encouraged. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From dsullivan2 at bsd.uchicago.edu Mon Feb 6 13:24:36 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Mon, 6 Feb 2017 13:24:36 +0000 Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: <1359190682.1911254.1486367960580.JavaMail.zimbra@casalogic.dk> References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> <1359190682.1911254.1486367960580.JavaMail.zimbra@casalogic.dk> Message-ID: Have you looked at the ignore_group_members option? Maybe this is the problem you are seeing? https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ ==snip== ignore_group_members Normally the most data-intensive operation is downloading the groups including their members. Usually, we are interested in what groups a user is a member of (id aduser at ad_domain) as the initial step rather than what members do specific groups include (getent group adgroup at ad_domain). Setting the ignore_group_members option to True makes all groups appear as empty, thus downloading only information about the group objects themselves and not their members, providing a significant performance boost. Please note that id aduser at ad_domain would still return all the correct groups! ==snip== Dan On Feb 6, 2017, at 1:59 AM, Troels Hansen wrote: Hi I'm aware of the anatomy of how the lookup is done, but I would suppose a valid cache on the IPA server would result in the cache from the IPA server being used? I have been debugging this issue some more, and can confirm is the client have its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid cache, when the client asks for the user, the IPA server still asks the AD for the entire group info? I can see, that even though the cache is refreshed the attribute initgrExpireTimestamp (in the ldb cache) isn't updated. I have been unable to find out exactly what this controls? lastUpdate and dataExpireTimestamp is updated to the time stamp of when the refresh ran. ----- On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: Have you checked to see if the user is expired in the cache, or if it is impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry timeout is only 90 minutes and entry_cache_nowait_percentage default is 50. ldbsearch -H /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb > ~/timestamps.txt ldbsearch -H /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt Might be able to provide more info. Again, I?d really familiarize yourself with the anatomy of an sssd lookup, if you get to know the diagram and steps 1-7 here it will be a big help to your question(s). https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ Dan On Feb 1, 2017, at 4:32 AM, Troels Hansen wrote: >From looking af at TCP dump, I can see that if a client requests a AD user from IPA, IPA does a full user lookup in AD, even though the IPA server have the user in local cache? It looks like a single group generates a LOT of traffic to AD like: client -> IPA IPA -> client IPA -> AD AD -> IPA IPA -> AD IPA -> Second AD Second AD -> IPA IPA -> Second AD IPA -> AD AD -> IPA IPA -> AD IPA -> client client -> IPA IPA -> Client Something similar continues for every group the user has. Soo, I guess the question that I haven't been able to find documented anywhere. Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd client requests a user? ----- On Feb 1, 2017, at 9:53 AM, Troels Hansen th at casalogic.dk wrote: Hmm, suspect its happening on the server...... thous I haven't been able to pinpoint a log entry that confirms my suspecting. I have pinpointed the timeout to happen after 58 seconds after completely removing the SSSD cache and restaring SSSD, which leads me to think my issue is related to ldap_enumaration_search_timeout which defaults to 60. rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja However, I'm unable to crank it up on the server as it seems to be adjusted Down to 60 Again? Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option ldap_enumeration_search_timeout has value 120 (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60 (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60 LDAP seems speedy enough, not timeouts while querying it manually while a client is doing a user lookup. ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: If the timeout is occurring on the server, I would start by increasing one or both of these values: ldap_opt_timeout ldap_search_timeout If that doesn?t work I?d take look to see if the 389 server is under high load when you are performing this operation. The easiest way I have found to do this is to just execute an LDAP query directly against the IPA server when you are performing an id lookup, for example: ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" "(objectclass=*)? If the LDAP server is not responsive you probably need to increase the number of worker threads for 389ds. Also, you might want to disable referrals, check out the man pages for this; ldap_referrals = false Also, FWIW, if you crank up debug logging on the sssd client, you should be able to see the amount of seconds of timeout assigned to the operation, and witness the fact that the operation is actually timing out by inspecting the logs themselves. The logs can get a little verbose but the data is there. -- 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -- 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From tommy.nikjoo at armourcomms.com Mon Feb 6 13:56:06 2017 From: tommy.nikjoo at armourcomms.com (Tommy Nikjoo) Date: Mon, 6 Feb 2017 13:56:06 +0000 Subject: [Freeipa-users] Ubuntu client 2FA not working In-Reply-To: <20161214224809.GA4232@dhcp-40-8.bne.redhat.com> References: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> <20161214224809.GA4232@dhcp-40-8.bne.redhat.com> Message-ID: <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> Hi, I'm having some issues with 2FA PAM config's on Ubuntu clients. Currently, I'm guessing that the PAM module doesn't know how to talk to the 2FA protocol. Is anyone able to give an in site into how to get this working correctly? Thanks ** // On 14/12/16 22:48, Fraser Tweedale wrote: > On Wed, Dec 14, 2016 at 05:35:35PM +0000, Tommy Nikjoo wrote: >> Hi, >> >> I'm trying to install FreeIPA on CentOS 7 using the yum package, but I >> keep getting an error when it tries to restart DogTag >> >> [26/31]: restarting certificate server >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart >> the Dogtag instance.See the installation log for details. >> [27/31]: migrating certificate profiles to LDAP >> [error] NetworkError: cannot connect to >> 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' >> ipa.ipapython.install.cli.install_tool(Server): ERROR cannot connect >> to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' >> ipa.ipapython.install.cli.install_tool(Server): ERROR The >> ipa-server-install command failed. See /var/log/ipaserver-install.log >> for more information >> >> >> The log shows the following error >> >> 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com >> 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0 >> 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage = >> SSL Server >> 2016-12-14T16:53:05Z DEBUG cert valid True for >> "CN=ldap.example.com,O=EXAMPLE.COM" >> 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443 >> 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2 >> 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA >> 2016-12-14T16:53:05Z DEBUG response status 200 >> 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205', >> 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/; >> Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server': >> 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec >> 2016 16:53:05 GMT', 'content-type': 'application/xml'} >> 2016-12-14T16:53:05Z DEBUG response body '> encoding="UTF-8" standalone="yes"?>> id="ipara">iparaCertificate Manager >> AgentsRegistration Manager Agents' >> 2016-12-14T16:53:05Z DEBUG request POST >> https://ldap.example.com:8443/ca/rest/profiles/raw >> 2016-12-14T16:53:05Z DEBUG request body >> 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user >> certificates with IECUserRoles extension via IPA-RA agent >> authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA >> Agent-Authenticated Server Certificate >> Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject >> Name >> Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject >> Name >> Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, >> O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity >> Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity >> Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key >> Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key >> Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No >> Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority >> Key Identifier >> Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No >> Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA >> Extension >> Default\npolicyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp\npolicyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1\npolicyset.serverCertSet.5.default.params.authInfoAccessCritical=false\npolicyset.serverCertSet.5.default.params.authInfoAccessNumADs=1\npolicyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl\npolicyset.serverCertSet.6.constraint.name=Key >> Usage Extension >> Constraint\npolicyset.serverCertSet.6.constraint.params.keyUsageCritical=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl\npolicyset.serverCertSet.6.default.name=Key >> Usage >> Default\npolicyset.serverCertSet.6.default.params.keyUsageCritical=true\npolicyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.default.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.7.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.7.constraint.name=No >> Constraint\npolicyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl\npolicyset.serverCertSet.7.default.name=Extended >> Key Usage Extension >> Default\npolicyset.serverCertSet.7.default.params.exKeyUsageCritical=false\npolicyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2\npolicyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl\npolicyset.serverCertSet.8.constraint.name=No >> Constraint\npolicyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC\npolicyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl\npolicyset.serverCertSet.8.default.name=Signing >> Alg\npolicyset.serverCertSet.8.default.params.signingAlg=-\npolicyset.serverCertSet.9.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.9.constraint.name=No >> Constraint\npolicyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl\npolicyset.serverCertSet.9.default.name=CRL >> Distribution Points Extension >> Default\npolicyset.serverCertSet.9.default.params.crlDistPointsCritical=false\npolicyset.serverCertSet.9.default.params.crlDistPointsNum=1\npolicyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate >> Authority,o=ipaca\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName\npolicyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.example.com/ipa/crl/MasterCRL.bin\npolicyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName\npolicyset.serverCertSet.9.default.params.crlDistPointsReasons_0=\npolicyset.serverCertSet.10.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.10.constraint.name=No >> Constraint\npolicyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.10.default.name=Subject >> Key Identifier Extension >> Default\npolicyset.serverCertSet.10.default.params.critical=false\npolicyset.serverCertSet.11.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.11.constraint.name=No >> Constraint\npolicyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.11.default.name=User >> Supplied Extension >> Default\npolicyset.serverCertSet.11.default.params.userExtOID=2.5.29.17\npolicyset.serverCertSet.12.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.12.constraint.name=No >> Constraint\npolicyset.serverCertSet.12.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.12.default.name=IECUserRoles >> Extension >> Default\npolicyset.serverCertSet.12.default.params.userExtOID=1.2.840.10070.8.1\n' >> >> Is there anything I can do to get around this? >> >> Thanks, >> >> Tommy >> > Could you look at `journalctl -u pki-tomcatd at pki-tomcat' and see if > there are any errors there? > > Also could you provide more of /var/log/ipaserver-install.log and > /var/log/pki/pki-tomcat/ca/debug ? > > Thanks, > Fraser -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Feb 6 14:28:39 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 6 Feb 2017 09:28:39 -0500 Subject: [Freeipa-users] Wrong principal in request in NFS mount In-Reply-To: <7abe45e4-3fbe-cc37-f63f-84b75e9f66ff@gmail.com> References: <7abe45e4-3fbe-cc37-f63f-84b75e9f66ff@gmail.com> Message-ID: <2ac25506-5350-bdc9-d212-e69b169768b3@redhat.com> Matthew Carter wrote: > So I have two test machines that I set up because of this same problem > on my secure offline network. One of the test machines is a server that > has FreeIPA and NFS running on it, the other test machine is a client > that mounts two NFS shares from the server using krb5i sec. > > Upon initial install, everything works as it is supposed to. The domain > users can log in just fine, the mount mounts perfectly. It sounds to me like /etc/krb5.keytab isn't being cleaned up properly on uninstall. What I'd suggest is to re-fetch the service principal, perhaps several times, to bump the KVNO to be sure you have the right one. Then restart the NFS services and see if that helps. Conceivably you'd need to do something similar on the client if that too has a mix of principals from the old and new masters. Getting some logging from the previous uninstall would be useful. IIRC there is a separate uninstall log for the client. rob > If I remove the client from the domain using: > > ipa-client-automount --uninstall > > ipa-client-install --uninstall > > > And then on the server: > > ipa-client-automount --uninstall > > ipa-server-install --uninstall > > then delete the ca.crt, run sss -E (to clear the sssd caches), rm > /tmp/krb5* > > > and then reinstall the server: > > ipa-server-install > > service sshd restart > > kinit admin > > ipa service-add nfs/server.dar.lan > > ipa-getkeytab -s server.dar.lan -p host/server.dar.lan -k > /etc/krb5.keytab > > ipa-getkeytab -s server.dar.lan -p nfs/server.dar.lan -k > /etc/krb5.keytab > > ipa-client-automount > > > and reinstall on the client: > > ipa-client-install > > ipa-client-automount > > > I believe I now have the same setup as I had before. > > I can kinit and get a ticket: > > Ticket cache: FILE:/tmp/krb5cc_615200000_TinxaO > Default principal: admin at DAR.LAN > > Valid starting Expires Service principal > 02/03/17 12:54:02 02/04/17 12:53:59 krbtgt/DAR.LAN at DAR.LAN > > My domain users can log in to their desktops. > > But I can't mount the shares. > > I get: > > mount.nfs4: timeout set for Fri Feb 3 12:58:36 2017 > mount.nfs4: trying text-based options > 'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11' > mount.nfs4: mount(2): Permission denied > mount.nfs4: access denied by server while mounting > server:/NFS_SHARE/USERS > mount.nfs4: timeout set for Fri Feb 3 12:58:36 2017 > mount.nfs4: trying text-based options > 'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11' > mount.nfs4: mount(2): Permission denied > mount.nfs4: access denied by server while mounting > server:/NFS_SHARE/admin > > > Originally I chased permissions, but when I started looking at > /var/log/messages on the server, I noticed that rpcgssd was complaining > about a wrong principal. > > On the server I executed kadmin.local and then listprincs > > K/M at DAR.LAN > krbtgt/DAR.LAN at DAR.LAN > kadmin/server.dar.lan at DAR.LAN > kadmin/admin at DAR.LAN > kadmin/changepw at DAR.LAN > ldap/server.dar.lan at DAR.LAN > host/server.dar.lan at DAR.LAN > HTTP/server.dar.lan at DAR.LAN > nfs/server.dar.lan at DAR.LAN > s_sharkey at DAR.LAN > host/as1.dar.lan at DAR.LAN > > and then a getprinc on nfs/server.dar.lan at DAR.LAN: > > Principal: nfs/server.dar.lan at DAR.LAN > Expiration date: [never] > Last password change: Thu Feb 02 15:31:24 EST 2017 > Password expiration date: [none] > Maximum ticket life: 1 day 00:00:00 > Maximum renewable life: 7 days 00:00:00 > Last modified: Thu Feb 02 15:31:24 EST 2017 > (nfs/server.dar.lan at DAR.LAN) > Last successful authentication: Thu Feb 02 16:52:16 EST 2017 > Last failed authentication: Fri Feb 03 12:09:14 EST 2017 > Failed password attempts: 1 > Number of keys: 4 > Key: vno 3, aes256-cts-hmac-sha1-96, no salt > Key: vno 3, aes128-cts-hmac-sha1-96, no salt > Key: vno 3, des3-cbc-sha1, no salt > Key: vno 3, arcfour-hmac, no salt > MKey: vno 1 > Attributes: REQUIRES_PRE_AUTH > Policy: [none] > > looking at my keytab, klist -ke /etc/krb5.keytab > > 1 2 host/server.dar.lan at DAR.LAN > 2 1 nfs/server.dar.lan at DAR.LAN > 3 3 host/server.dar.lan at DAR.LAN > 4 3 host/server.dar.lan at DAR.LAN > 5 3 host/server.dar.lan at DAR.LAN > 6 3 host/server.dar.lan at DAR.LAN > 7 2 nfs/server.dar.lan at DAR.LAN > 8 2 nfs/server.dar.lan at DAR.LAN > 9 2 nfs/server.dar.lan at DAR.LAN > 10 2 nfs/server.dar.lan at DAR.LAN > > I saw I had two extra older kt's so I used kadmin.local to remove them > with modprinc. Not sure where they came from. . . > > I again tried to mount, this time using -vvv in /etc/sysconfig/nfs for > rpcgssd, rpcsvcgssd, and rpcbind and /var/log/messages output this on > the server (I'll only paste the data from one mount attempt as there is > two mounts and they're complaining identically.): > > Feb 3 12:25:32 server rpc.svcgssd[4796]: leaving poll > Feb 3 12:25:32 server rpc.svcgssd[4796]: handling null request > Feb 3 12:25:32 server rpc.svcgssd[4796]: svcgssd_limit_krb5_enctypes: > Calling gss_set_allowable_enctypes with 7 enctypes from the kernel > Feb 3 12:25:32 server rpc.svcgssd[4796]: WARNING: > gss_accept_sec_context failed > Feb 3 12:25:32 server rpc.svcgssd[4796]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - Wrong principal in > request > Feb 3 12:25:32 server rpc.svcgssd[4796]: sending null reply > Feb 3 12:25:32 server rpc.svcgssd[4796]: writing message: \x > \x6082025f06092a864886f71201020201006e82024e3082024aa003020105a10302010ea20703050020000000a382015a6182015630820152a003020105a1091b074441522e4c414ea220301ea003020103a11730151b036e66731b0e7365727665722e6461722e6c616ea382011c30820118a003020112a103020103a282010a048201063acb411e685126d45ffc67763e9d9fb3eaa42765e44ad17b924d930583f95f8169980758f7d7ac59b5668c40a6a4c0aadee0e4a655a29343e09b69922cf65e2bf639b30fa764d415d3e1207da584b0d3d4ffb668d0d6fbcf52a7eed73cf9f51dd777096647e13931c30a6929115f8d1244086a78fa35fbe4073c195be3f49ba34ffe04bd3ae0bba9f8d9713d931f129fa0087872514f5aa4b0f933549b27cd45bcda4460d562b9b9dec90e5d358d6824aad6e46f50bbd03b35ac80df8b65f771bacf3ab7c96336f3051833d11fe283506a20c3eeae9d7df743a634e9928443cafb088a2adb083d2fa32eec78934a27e7d3358a451dd5ba36a94a5fdeb255aa5e884230069bdda481d63081d3a003020112a281cb0481c802b37853075fe8f79de1d93289e493dd95e7724a050d44cc629521c0a1504d2a33589d4e13c4941a9451b4d2cfb74129ac2943664b9adb01b89d8746fd531c251fbe87660c9305d73a18fb3166907ac85a0c38fe59b475899f0f69b4193311cab6ed19ca0ce1f2a0dfc7b7a04d2bb1195406dc6d846f3535db5c083ade0a4dfa0c5d4466ee10fd04d72325192fd8473e05d0318b390d6c87c440ca5eabdc3017fec828c29543b3414fac312b597e0ea4726cb33fe825feef00527e14d5f426cc7781dcd3dd0a0969 > 1486142792 851968 2529639056 \x \x > REPEATED 3x . . . > > > Feb 3 12:25:32 server rpc.svcgssd[4796]: finished handling null request > Feb 3 12:25:32 server audispd: node=server type=SYSCALL > msg=audit(1486142732.066:592): arch=c000003e syscall=87 success=yes > exit=0 a0=2110480 a1=c2 a2=1a a3=f items=2 ppid=1 pid=4525 auid=500 > uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 > tty=(none) ses=1 comm="gnome-terminal" exe="/usr/bin/gnome-terminal" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="delete" > Feb 3 12:25:32 server audispd: node=server type=CWD > msg=audit(1486142732.066:592): cwd="/home/adminnt" > Feb 3 12:25:32 server rpc.svcgssd[4796]: entering poll > Feb 3 12:25:34 as1 audispd: node=as1 type=SYSCALL > msg=audit(1486142734.451:79839): arch=c000003e syscall=165 success=no > exit=-13 a0=7ffcb5014564 a1=7f00d8823ea0 a2=7f00d72133f6 a3=0 items=17 > ppid=7132 pid=7133 auid=615200000 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="mount.nfs4" > exe="/sbin/mount.nfs" > subj=unconfined_u:unconfined_r:unconfined_mount_t:s0-s0:c0.c1023 > key="export" > Feb 3 12:25:34 as1 audispd: node=as1 type=CWD > msg=audit(1486142734.451:79839): cwd="/usr" > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=0 name="/NFS_SHARE" inode=654083 > dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 > obj=unconfined_u:object_r:default_t:s0 nametype=NORMAL > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=1 name=(null) inode=103 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=NORMAL > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=2 name=(null) inode=103 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=3 name=(null) inode=280 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=4 name=(null) inode=280 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=5 name=(null) inode=281 dev=00:12 > mode=0100400 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=6 name=(null) inode=280 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=7 name=(null) inode=282 dev=00:12 > mode=010600 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=8 name=(null) inode=280 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=9 name=(null) inode=283 dev=00:12 > mode=010600 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=10 name=(null) inode=280 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=11 name=(null) inode=284 dev=00:12 > mode=010600 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=12 name=(null) inode=103 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=NORMAL > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=13 name=(null) inode=103 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=14 name=(null) inode=285 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=15 name=(null) inode=285 dev=00:12 > mode=040555 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=PARENT > Feb 3 12:25:34 as1 audispd: node=as1 type=PATH > msg=audit(1486142734.451:79839): item=16 name=(null) inode=286 dev=00:12 > mode=0100400 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:rpc_pipefs_t:s0 nametype=CREATE > > > I apoligize for the wall o' words, but you know how log files can be. > > So my setup naming conventions is exactly as during the initial install > which worked. The config files shouldn't have changed. It seems as if > the principal name, KVNO, and the keytab match up. Did something not get > cleaned properly? > > Currently I can mount just fine without krb5i security, but my Govt STIG > requires it for NFS mounts and I'm stuck. > > > Thanks for any help! > > > Matt > > > > From giorgio at di.unimi.it Mon Feb 6 15:50:25 2017 From: giorgio at di.unimi.it (Giorgio Biacchi) Date: Mon, 6 Feb 2017 16:50:25 +0100 Subject: [Freeipa-users] IPA replica issue Message-ID: <9cfdecb6-2f62-d3ba-41db-e6187579c1a5@di.unimi.it> Hi list, I have this message in the logs: Feb 6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100] NSMMReplicationPlugin - agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized. But ipa-replica-manage re-initialize --from dc02.myorg.local does not fix the problem. Even moving away the changelog directory didn't help.. I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and 389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is: #ipa-replica-manage list Directory Manager password: dc01.myorg.local: master dc02.myorg.local: master Can someone please tell me which is the correct sequence of actions to fix this issue? Thanks -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 From rcritten at redhat.com Mon Feb 6 15:54:22 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 6 Feb 2017 10:54:22 -0500 Subject: [Freeipa-users] IPA replica issue In-Reply-To: <9cfdecb6-2f62-d3ba-41db-e6187579c1a5@di.unimi.it> References: <9cfdecb6-2f62-d3ba-41db-e6187579c1a5@di.unimi.it> Message-ID: <44104eb0-20e4-e9ac-a9f4-030d28cf4281@redhat.com> Giorgio Biacchi wrote: > Hi list, > I have this message in the logs: > > Feb 6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100] > NSMMReplicationPlugin - > agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data > required to update replica has been purged from the changelog. The > replica must be reinitialized. > > But ipa-replica-manage re-initialize --from dc02.myorg.local does not > fix the problem. Even moving away the changelog directory didn't help.. > > I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and > 389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is: > > #ipa-replica-manage list > Directory Manager password: > > dc01.myorg.local: master > dc02.myorg.local: master > > Can someone please tell me which is the correct sequence of actions to > fix this issue? The error appears to be the CA replicated data (ref to tomcat in the agreement) so you need to use ipa-csreplica-manage instead of ipa-replica-manage. rob From giorgio at di.unimi.it Mon Feb 6 16:14:10 2017 From: giorgio at di.unimi.it (Giorgio Biacchi) Date: Mon, 6 Feb 2017 17:14:10 +0100 Subject: [Freeipa-users] IPA replica issue In-Reply-To: <44104eb0-20e4-e9ac-a9f4-030d28cf4281@redhat.com> References: <9cfdecb6-2f62-d3ba-41db-e6187579c1a5@di.unimi.it> <44104eb0-20e4-e9ac-a9f4-030d28cf4281@redhat.com> Message-ID: On 02/06/2017 04:54 PM, Rob Crittenden wrote: > Giorgio Biacchi wrote: >> Hi list, >> I have this message in the logs: >> >> Feb 6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100] >> NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data >> required to update replica has been purged from the changelog. The >> replica must be reinitialized. >> >> But ipa-replica-manage re-initialize --from dc02.myorg.local does not >> fix the problem. Even moving away the changelog directory didn't help.. >> >> I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and >> 389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is: >> >> #ipa-replica-manage list >> Directory Manager password: >> >> dc01.myorg.local: master >> dc02.myorg.local: master >> >> Can someone please tell me which is the correct sequence of actions to >> fix this issue? > > The error appears to be the CA replicated data (ref to tomcat in the > agreement) so you need to use ipa-csreplica-manage instead of > ipa-replica-manage. > > rob > Hi Rob, even ipa-csreplica-manage re-initialize --from dc02.myorg.local seems not to solve the issue, here's the logs after the command you suggested: Feb 6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.432485541 +0100] NSMMReplicationPlugin - changelog program - agmt="cn=meTodc02.myorg.local" (idc02:389): CSN 58989367000c00040000 not found, we aren't as up to date, or we purged Feb 6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.436444629 +0100] NSMMReplicationPlugin - agmt="cn=meTodc02.myorg.local" (dc02:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized. Thanks for your kind attention -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 From giorgio at di.unimi.it Mon Feb 6 17:28:36 2017 From: giorgio at di.unimi.it (Giorgio Biacchi) Date: Mon, 6 Feb 2017 18:28:36 +0100 Subject: [Freeipa-users] IPA replica issue In-Reply-To: References: <9cfdecb6-2f62-d3ba-41db-e6187579c1a5@di.unimi.it> <44104eb0-20e4-e9ac-a9f4-030d28cf4281@redhat.com> Message-ID: <1053fb43-ea0e-60e3-4272-d3cc20abebf6@di.unimi.it> On 02/06/2017 05:14 PM, Giorgio Biacchi wrote: > On 02/06/2017 04:54 PM, Rob Crittenden wrote: >> Giorgio Biacchi wrote: >>> Hi list, >>> I have this message in the logs: >>> >>> Feb 6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100] >>> NSMMReplicationPlugin - >>> agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data >>> required to update replica has been purged from the changelog. The >>> replica must be reinitialized. >>> >>> But ipa-replica-manage re-initialize --from dc02.myorg.local does not >>> fix the problem. Even moving away the changelog directory didn't help.. >>> >>> I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and >>> 389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is: >>> >>> #ipa-replica-manage list >>> Directory Manager password: >>> >>> dc01.myorg.local: master >>> dc02.myorg.local: master >>> >>> Can someone please tell me which is the correct sequence of actions to >>> fix this issue? >> >> The error appears to be the CA replicated data (ref to tomcat in the >> agreement) so you need to use ipa-csreplica-manage instead of >> ipa-replica-manage. >> >> rob >> > > Hi Rob, > even ipa-csreplica-manage re-initialize --from dc02.myorg.local seems not to > solve the issue, here's the logs after the command you suggested: > > Feb 6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.432485541 +0100] > NSMMReplicationPlugin - changelog program - agmt="cn=meTodc02.myorg.local" > (idc02:389): CSN 58989367000c00040000 not found, we aren't as up to date, or we > purged > Feb 6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.436444629 +0100] > NSMMReplicationPlugin - agmt="cn=meTodc02.myorg.local" (dc02:389): Data required > to update replica has been purged from the changelog. The replica must be > reinitialized. > > Thanks for your kind attention Hello again, after a couple of re-initialization (ipa-csreplica-manage and ipa-replica-manage) and after systemctl restart ipa now the previuos error is gone and the replica is working in both directions. Now I have a new error: Feb 6 18:02:12 dc01 [sssd[ldap_child[10109]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection. Feb 6 18:02:12 dc01 [sssd[ldap_child[10109]]]: Decrypt integrity check failed There's a way to fix this?? Thanks -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 From acollins at chegg.com Tue Feb 7 03:25:11 2017 From: acollins at chegg.com (Aaron Collins) Date: Tue, 7 Feb 2017 03:25:11 +0000 Subject: [Freeipa-users] ipactl services running, but auth not working In-Reply-To: <284778203.607162.1486159863488@mail.yahoo.com> References: <762288497.596207.1486073624507.ref@mail.yahoo.com> <762288497.596207.1486073624507@mail.yahoo.com> <91B861CB-5397-40F5-8A8D-771415546C4F@bsd.uchicago.edu> <745747942.422975.1486142805830@mail.yahoo.com> <70FBEC28-08EF-423C-A7CA-133775DA6520@bsd.uchicago.edu> <284778203.607162.1486159863488@mail.yahoo.com> Message-ID: <867F7D26-E8F2-4E1A-A8DC-2E1D53F31F71@chegg.com> It sounds like your IPA service is hanging. The fastest way to check is do an ldap search against that host to see if it replies. If it doesn?t look under /var/log/dirvsrv/sapd-$INSTANCE-NAME/error to see if you have an error. I?ve seen this with the out of fd error, or if you server is in a dead lock. [ignature_882888092] Aaron Collins | Senior DevOps Engineer 3990 Freedom Circle, Santa Clara, CA 95054 808.203.8756 mobile | acollins at chegg.com www.chegg.com | t @chegg | f chegg We put students first. Chegg is proud to have helped students & their families save over $1 billion. From: on behalf of pgb205 Reply-To: pgb205 Date: Friday, February 3, 2017 at 12:11 PM To: "Sullivan, Daniel [CRI]" Cc: Freeipa-users Subject: Re: [Freeipa-users] ipactl services running, but auth not working there are reports from multiple clients being unable to authenticate. ipactl status shows all services as running. The problem is fixed when I 'ipactl restart'. ________________________________ From: "Sullivan, Daniel [CRI]" To: pgb205 Cc: Freeipa-users Sent: Friday, February 3, 2017 2:47 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working What exactly are you seeing to determine that the server is actually failing? Is it not possible that sssd (the client) is timing out? Will 389ds service an LDAP request, i.e. can you run ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" "(objectclass=*)? What exactly are you trying to do? Just password authentication to an sssd client? Are you operating in a trusted AD environment? Dan On Feb 3, 2017, at 11:26 AM, pgb205 >> wrote: My problem is with the server itself seemingly not providing services even though it claims to do so. would be curious to know what to look at on freeipa server or how to inrease logging ________________________________ From: "Sullivan, Daniel [CRI]" >> To: pgb205 >> Cc: Freeipa-users >> Sent: Thursday, February 2, 2017 5:16 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 >>>> wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4896 bytes Desc: image001.png URL: From wgraboyes at cenic.org Wed Feb 8 00:57:25 2017 From: wgraboyes at cenic.org (William Graboyes) Date: Tue, 7 Feb 2017 16:57:25 -0800 Subject: [Freeipa-users] Issue with MFA in CentOS 6.8 Message-ID: <79d00e59-1391-88c9-8880-b22e3b78ecd9@cenic.org> Hi All, I am having some odd issues with MFA on CentOS release 6.8 (Final), debug logs included below. I have two users, one with MFA enabled, and one without. They are both in the same groups and have the same level of access to the server, both pass the HBAC tests, however the one with MFA fails to be granted access to the server and I am unable to come to an idea of a solution. Both users show up in the proper group with the getent command. OS: CentOS 6.8 IPA Version: ipa-client-3.0.0-50.el6.centos.3.x86_64 sssd Version: sssd-ipa-1.13.3-22.el6_8.4.x86_64 Any help would be greatly appreciated. Thanks, Bill Debug logs (sanitized and for a single transaction of the MFA user): sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_get_account_info] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=usermfa] sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_req_set_domain] (0x0400): Changing request domain from [domain.tld] to [domain.tld] sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=domain,dc=tld] sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=usermfa)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_save_user] (0x0400): Save user sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_primary_name] (0x0400): Processing object usermfa sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_save_user] (0x0400): Processing user usermfa sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [usermfa]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_save_user] (0x0400): Adding user principal [usermfa at domain.tld] to attributes of [usermfa]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_save_user] (0x0400): Storing info for user usermfa sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_primary_name] (0x0400): Processing object usermfa sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=ipausers,cn=groups,cn=accounts,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][ipaUniqueID=5e66b39e-f8dc-11e4-b00c-525400bb2465,cn=hbac,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_initgr_nested_search] (0x0040): Search for group ipaUniqueID=5e66b39e-f8dc-11e4-b00c-525400bb2465,cn=hbac,dc=domain,dc=tld, returned 0 results. Skipping sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=tacacs,cn=groups,cn=accounts,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][ipaUniqueID=eb439cf0-4a90-11e4-9d94-525400e99b50,cn=hbac,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_initgr_nested_search] (0x0040): Search for group ipaUniqueID=eb439cf0-4a90-11e4-9d94-525400e99b50,cn=hbac,dc=domain,dc=tld, returned 0 results. Skipping sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=tacacs_users,cn=groups,cn=accounts,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][ipaUniqueID=50a61ece-4a8c-11e4-b5a2-525400e99b50,cn=sudorules,cn=sudo,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_initgr_nested_search] (0x0040): Search for group ipaUniqueID=50a61ece-4a8c-11e4-b5a2-525400e99b50,cn=sudorules,cn=sudo,dc=domain,dc=tld, returned 0 results. Skipping sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][cn=shell,cn=groups,cn=accounts,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*))][ipaUniqueID=0d5e97e6-b98e-11e5-9d11-5254002ece04,cn=hbac,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_initgr_nested_search] (0x0040): Search for group ipaUniqueID=0d5e97e6-b98e-11e5-9d11-5254002ece04,cn=hbac,dc=domain,dc=tld, returned 0 results. Skipping sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_primary_name] (0x0400): Processing object ipausers sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_primary_name] (0x0400): Processing object tacacs sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_primary_name] (0x0400): Processing object tacacs_users sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_primary_name] (0x0400): Processing object shell sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_initgr_done] (0x0400): Primary group already cached, nothing to do. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:domain.tld:60fdb0fa-b1d9-11e6-8e62-5254002ece04))][cn=Default Trust View,cn=views,cn=accounts,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_req_set_domain] (0x0400): Changing request domain from [domain.tld] to [domain.tld] sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_pam_handler] (0x0100): Got request with the following data sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): domain: domain.tld sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): user: usermfa sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): service: sshd sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): tty: ssh sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): ruser: sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): rhost: dynd093.domain.tld sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): authtok type: 1 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): newauthtok type: 0 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): priv: 1 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): cli_pid: 21707 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [pam_print_data] (0x0100): logon name: not set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_resolve_server_process] (0x0200): Found address for server tus-auth-2.domain.tld: [267.260.582.247] TTL 8801 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://tus-auth-2.domain.tld' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [write_pipe_handler] (0x0400): All data has been sent! sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [read_pipe_handler] (0x0400): EOF received, client finished sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=domain,dc=tld]. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [child_sig_handler] (0x0100): child [21713] finished successfully. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_resolve_server_process] (0x0200): Found address for server tus-auth-2.domain.tld: [267.260.582.247] TTL 8801 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_sys_connect_done] (0x0100): Executing START TLS sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'tus-auth-2.domain.tld' as 'working' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [set_server_common_status] (0x0100): Marking server 'tus-auth-2.domain.tld' as 'working' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'tus-auth-2.domain.tld' as 'working' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password is missing, starting password migration. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=usermfa,cn=users,cn=accounts,dc=domain,dc=tld sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [simple_bind_done] (0x0400): Bind result: Success(0), no errmsg set sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [ipa_auth_ldap_done] (0x0400): LDAP authentication succeded, trying Kerberos authentication again. sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_resolve_server_process] (0x0200): Found address for server tus-auth-2.domain.tld: [267.260.582.247] TTL 8801 sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://tus-auth-2.domain.tld' sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [write_pipe_handler] (0x0400): All data has been sent! sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [read_pipe_handler] (0x0400): EOF received, client finished sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 17, ) [Success] sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_pam_handler_callback] (0x0100): Sending result [17][domain.tld] sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [be_pam_handler_callback] (0x0100): Sent result [17][domain.tld] sssd_domain.tld.log:(Tue Feb 7 16:27:36 2017) [sssd[be[domain.tld]]] [child_sig_handler] (0x0100): child [21714] finished successfully. sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [accept_fd_handler] (0x0400): Client connected to privileged pipe! sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'usermfa' matched without domain, user is usermfa sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not set sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): user: usermfa sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: dynd093.domain.tld sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 21707 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: usermfa sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x410330:3:usermfa at domain.tld] sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [domain.tld][0x3][BE_REQ_INITGROUPS][1][name=usermfa] sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x410330:3:usermfa at domain.tld] sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [usermfa at domain.tld] sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [usermfa at domain.tld] sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: domain.tld sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): user: usermfa sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: dynd093.domain.tld sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 21707 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: usermfa sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x410330:3:usermfa at domain.tld] sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [17 (Failure setting user credentials)][domain.tld] sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [17]: Failure setting user credentials. sssd_pam.log:(Tue Feb 7 16:27:36 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 sssd_pam.log:(Tue Feb 7 16:27:40 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From th at casalogic.dk Wed Feb 8 07:27:02 2017 From: th at casalogic.dk (Troels Hansen) Date: Wed, 8 Feb 2017 08:27:02 +0100 (CET) Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> <1359190682.1911254.1486367960580.JavaMail.zimbra@casalogic.dk> Message-ID: <1291496609.1940875.1486538822821.JavaMail.zimbra@casalogic.dk> No, ignore_group_members option is already set. Tried setting and removing it on the client but didn't make a huge different. Is a client have an completely empty cache, newly joined, empty /var/lig/sssd/db and mc cache or something, the IPA server ALWAYS asks the AD for group info, despite having a valid cache. This leads to a delay of up to, or even more 5 minutes before a user can login. Being denied access at first, but logging again later with success. If the client have a cache thats only expired its able to pull the account info from the cache on the IPA, without the IPA having to contact the AD. ----- On Feb 6, 2017, at 2:24 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: > Have you looked at the ignore_group_members option? Maybe this is the problem > you are seeing? > > https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ > > ==snip== > > ignore_group_members > Normally the most data-intensive operation is downloading the groups including > their members. Usually, we are interested in what groups a user is a member of > (id aduser at ad_domain) as the initial step rather than what members do specific > groups include (getent group adgroup at ad_domain). Setting the > ignore_group_members option to True makes all groups appear as empty, thus > downloading only information about the group objects themselves and not their > members, providing a significant performance boost. Please note that id > aduser at ad_domain would still return all the correct groups! > ==snip== > > > Dan > > On Feb 6, 2017, at 1:59 AM, Troels Hansen wrote: > > Hi > > I'm aware of the anatomy of how the lookup is done, but I would suppose a valid > cache on the IPA server would result in the cache from the IPA server being > used? > > I have been debugging this issue some more, and can confirm is the client have > its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid > cache, when the client asks for the user, the IPA server still asks the AD for > the entire group info? > > I can see, that even though the cache is refreshed the attribute > initgrExpireTimestamp (in the ldb cache) isn't updated. > I have been unable to find out exactly what this controls? > > lastUpdate and dataExpireTimestamp is updated to the time stamp of when the > refresh ran. > > > ----- On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI] > dsullivan2 at bsd.uchicago.edu wrote: > > Have you checked to see if the user is expired in the cache, or if it is > impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry > timeout is only 90 minutes and entry_cache_nowait_percentage default is 50. > > ldbsearch -H /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb > > ~/timestamps.txt > ldbsearch -H /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt > > Might be able to provide more info. > > Again, I?d really familiarize yourself with the anatomy of an sssd lookup, if > you get to know the diagram and steps 1-7 here it will be a big help to your > question(s). > https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ > > Dan > > > On Feb 1, 2017, at 4:32 AM, Troels Hansen wrote: > > From looking af at TCP dump, I can see that if a client requests a AD user from > IPA, IPA does a full user lookup in AD, even though the IPA server have the > user in local cache? > > It looks like a single group generates a LOT of traffic to AD like: > client -> IPA > IPA -> client > IPA -> AD > AD -> IPA > IPA -> AD > IPA -> Second AD > Second AD -> IPA > IPA -> Second AD > IPA -> AD > AD -> IPA > IPA -> AD > IPA -> client > client -> IPA > IPA -> Client > > Something similar continues for every group the user has. > > Soo, I guess the question that I haven't been able to find documented anywhere. > Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd > client requests a user? > > > > ----- On Feb 1, 2017, at 9:53 AM, Troels Hansen th at casalogic.dk wrote: > > Hmm, suspect its happening on the server...... thous I haven't been able to > pinpoint a log entry that confirms my suspecting. > > I have pinpointed the timeout to happen after 58 seconds after completely > removing the SSSD cache and restaring SSSD, which leads me to think my issue is > related to ldap_enumaration_search_timeout which defaults to 60. > > rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja > > However, I'm unable to crank it up on the server as it seems to be adjusted Down > to 60 Again? > > Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option > ldap_enumeration_search_timeout has value 120 > (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): > Option ldap_enumeration_search_timeout has value 60 > (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): > Option ldap_enumeration_search_timeout has value 60 > > LDAP seems speedy enough, not timeouts while querying it manually while a client > is doing a user lookup. > > ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] > dsullivan2 at bsd.uchicago.edu wrote: > > > If the timeout is occurring on the server, I would start by increasing one or > both of these values: > > ldap_opt_timeout > ldap_search_timeout > > If that doesn?t work I?d take look to see if the 389 server is under high load > when you are performing this operation. The easiest way I have found to do > this is to just execute an LDAP query directly against the IPA server when you > are performing an id lookup, for example: > > ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" > "(objectclass=*)? > > If the LDAP server is not responsive you probably need to increase the number of > worker threads for 389ds. Also, you might want to disable referrals, check out > the man pages for this; > > ldap_referrals = false > > Also, FWIW, if you crank up debug logging on the sssd client, you should be able > to see the amount of seconds of timeout assigned to the operation, and witness > the fact that the operation is actually timing out by inspecting the logs > themselves. The logs can get a little verbose but the data is there. > > > -- > 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 > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > meget mere. > > -- > 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 > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > meget mere. -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From sbose at redhat.com Wed Feb 8 08:39:00 2017 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Feb 2017 09:39:00 +0100 Subject: [Freeipa-users] Ubuntu client 2FA not working In-Reply-To: <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> References: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> <20161214224809.GA4232@dhcp-40-8.bne.redhat.com> <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> Message-ID: <20170208083900.GH3552@p.Speedport_W_724V_Typ_A_05011603_00_011> On Mon, Feb 06, 2017 at 01:56:06PM +0000, Tommy Nikjoo wrote: > Hi, > > I'm having some issues with 2FA PAM config's on Ubuntu clients. > Currently, I'm guessing that the PAM module doesn't know how to talk to > the 2FA protocol. Is anyone able to give an in site into how to get > this working correctly? In general you have to make sure the pam_sss is the pam modules which does the conversation with the user and not e.g. pam_unix because pam_unix will only ask for a password. E.g. on Fedora/RHEL a general auth part of the PAM configuration might look like: auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so The pam_localuser module checks if the user trying to log in is a local user, i.e. listed in /etc/passwd, and if it is a local user (success=ok) the next module pam_unix is called. For non-local user the next module is skipped (default=1) and after the uid check pam_sss is call which now can prompt the user according to the authentication methods available for the user on the IPA server. HTH bye, Sumit > > Thanks > > ** > > // > > > > On 14/12/16 22:48, Fraser Tweedale wrote: > > On Wed, Dec 14, 2016 at 05:35:35PM +0000, Tommy Nikjoo wrote: > >> Hi, > >> > >> I'm trying to install FreeIPA on CentOS 7 using the yum package, but I > >> keep getting an error when it tries to restart DogTag > >> > >> [26/31]: restarting certificate server > >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart > >> the Dogtag instance.See the installation log for details. > >> [27/31]: migrating certificate profiles to LDAP > >> [error] NetworkError: cannot connect to > >> 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' > >> ipa.ipapython.install.cli.install_tool(Server): ERROR cannot connect > >> to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' > >> ipa.ipapython.install.cli.install_tool(Server): ERROR The > >> ipa-server-install command failed. See /var/log/ipaserver-install.log > >> for more information > >> > >> > >> The log shows the following error > >> > >> 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com > >> 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0 > >> 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage = > >> SSL Server > >> 2016-12-14T16:53:05Z DEBUG cert valid True for > >> "CN=ldap.example.com,O=EXAMPLE.COM" > >> 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443 > >> 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2 > >> 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA > >> 2016-12-14T16:53:05Z DEBUG response status 200 > >> 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205', > >> 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/; > >> Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server': > >> 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec > >> 2016 16:53:05 GMT', 'content-type': 'application/xml'} > >> 2016-12-14T16:53:05Z DEBUG response body ' >> encoding="UTF-8" standalone="yes"?> >> id="ipara">iparaCertificate Manager > >> AgentsRegistration Manager Agents' > >> 2016-12-14T16:53:05Z DEBUG request POST > >> https://ldap.example.com:8443/ca/rest/profiles/raw > >> 2016-12-14T16:53:05Z DEBUG request body > >> 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user > >> certificates with IECUserRoles extension via IPA-RA agent > >> authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA > >> Agent-Authenticated Server Certificate > >> Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject > >> Name > >> Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject > >> Name > >> Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, > >> O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity > >> Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity > >> Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key > >> Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key > >> Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No > >> Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority > >> Key Identifier > >> Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No > >> Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA > >> Extension > >> Default\npolicyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp\npolicyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1\npolicyset.serverCertSet.5.default.params.authInfoAccessCritical=false\npolicyset.serverCertSet.5.default.params.authInfoAccessNumADs=1\npolicyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl\npolicyset.serverCertSet.6.constraint.name=Key > >> Usage Extension > >> Constraint\npolicyset.serverCertSet.6.constraint.params.keyUsageCritical=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl\npolicyset.serverCertSet.6.default.name=Key > >> Usage > >> Default\npolicyset.serverCertSet.6.default.params.keyUsageCritical=true\npolicyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.default.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.7.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.7.constraint.name=No > >> Constraint\npolicyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl\npolicyset.serverCertSet.7.default.name=Extended > >> Key Usage Extension > >> Default\npolicyset.serverCertSet.7.default.params.exKeyUsageCritical=false\npolicyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2\npolicyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl\npolicyset.serverCertSet.8.constraint.name=No > >> Constraint\npolicyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC\npolicyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl\npolicyset.serverCertSet.8.default.name=Signing > >> Alg\npolicyset.serverCertSet.8.default.params.signingAlg=-\npolicyset.serverCertSet.9.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.9.constraint.name=No > >> Constraint\npolicyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl\npolicyset.serverCertSet.9.default.name=CRL > >> Distribution Points Extension > >> Default\npolicyset.serverCertSet.9.default.params.crlDistPointsCritical=false\npolicyset.serverCertSet.9.default.params.crlDistPointsNum=1\npolicyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate > >> Authority,o=ipaca\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName\npolicyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.example.com/ipa/crl/MasterCRL.bin\npolicyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName\npolicyset.serverCertSet.9.default.params.crlDistPointsReasons_0=\npolicyset.serverCertSet.10.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.10.constraint.name=No > >> Constraint\npolicyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.10.default.name=Subject > >> Key Identifier Extension > >> Default\npolicyset.serverCertSet.10.default.params.critical=false\npolicyset.serverCertSet.11.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.11.constraint.name=No > >> Constraint\npolicyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.11.default.name=User > >> Supplied Extension > >> Default\npolicyset.serverCertSet.11.default.params.userExtOID=2.5.29.17\npolicyset.serverCertSet.12.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.12.constraint.name=No > >> Constraint\npolicyset.serverCertSet.12.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.12.default.name=IECUserRoles > >> Extension > >> Default\npolicyset.serverCertSet.12.default.params.userExtOID=1.2.840.10070.8.1\n' > >> > >> Is there anything I can do to get around this? > >> > >> Thanks, > >> > >> Tommy > >> > > Could you look at `journalctl -u pki-tomcatd at pki-tomcat' and see if > > there are any errors there? > > > > Also could you provide more of /var/log/ipaserver-install.log and > > /var/log/pki/pki-tomcat/ca/debug ? > > > > Thanks, > > Fraser > > -- > 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 Wed Feb 8 08:45:13 2017 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Feb 2017 09:45:13 +0100 Subject: [Freeipa-users] Smart Card login into an Active Directory User In-Reply-To: <20170203155926.9ZD85.121757.imail@fed1rmwml303> References: <20170203155926.9ZD85.121757.imail@fed1rmwml303> Message-ID: <20170208084513.GI3552@p.Speedport_W_724V_Typ_A_05011603_00_011> On Fri, Feb 03, 2017 at 12:59:26PM -0800, spammewoods at cox.net wrote: > > ---- Sumit Bose wrote: > > On Fri, Feb 03, 2017 at 09:33:13AM +0100, Sumit Bose wrote: > > On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewoods at cox.net wrote: > > > I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a Windows Active Directory server. I am trying to configure the IPA server to allow the Active Directory Users to log into Gnome with a CAC smart card. I?m having a hard time finding any instructions on how to do this. The problem I?m having is the Common Name from the smart card is not getting associated with the Active Directory account. I added the certificate from the smart card to the IPA server by creating a User ID override for the AD user account. I made sure to not use authconfig to configure smart cards and I added ifp to the services line in the sssd.conf file. > > > > > > I have the following packages installed: > > > ipa-admintools.noarch 4.4.0-14.el7_3.4 > > > ipa-client.x86_64 4.4.0-14.el7_3.4 > > > ipa-client-common.noarch 4.4.0-14.el7_3.4 > > > ipa-common.noarch 4.4.0-14.el7_3.4 > > > ipa-python-compat.noarch 4.4.0-14.el7_3.4 > > > ipa-server.x86_64 4.4.0-14.el7_3.4 > > > ipa-server-common.noarch 4.4.0-14.el7_3.4 > > > ipa-server-dns.noarch 4.4.0-14.el7_3.4 > > > ipa-server-trust-ad.x86_64 4.4.0-14.el7_3.4 > > > > > > I can log in with AD user accounts that are configured with UserName and Passswords, so I know that the integration is working. When I try to log into GDM with my smart card, I don?t get prompted for a PIN number. It only asks for the password from the AD account. > > > > Please have a look at the steps described in > > https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me > > know if you run into issues. > > Please also check if you followed the steps in > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html > > HTH > > bye, > Sumit > > -- > Hello Sumit, > I followed the instructions in comment #9. I modified the /etc/pam.d/smartcard-auth file and the two files that are under /etc/dconf/db/distro.d/. But it still doesn't work. GDM will prompt me for a password not the PIN when I plug in the smart card. Do I need to run "authconfig --enablesmartcard --smartcardmodule=no_module --update" before I change the files ? Should I remove pam_pkcs11 too ? I have been able to get AD smart card login working using standard authconfig, pam_pkcs11, and the cn_map. I just don't want to use the cn_map file and have to list all of my user's "Common Names" in this file. With the steps you described running authconfig is not needed and might even do more harm than good. I think it would be best check the SSSD logs next. Please add 'debug_level = 9' at least to the [pam] section of sssd.conf and restart SSSD (see https://fedorahosted.org/sssd/wiki/Troubleshooting for details). Now try to authenticate again. The relevant log files are /var/log/sssd/sssd_pam.log and /var/log/sssd/p11_child.log. The latter e.g. should show if there are any issues validation the certificate. Feel free to send the logs file to me directly if you do not want to share them on a public list. 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 keesb at ghs.com Wed Feb 8 08:59:52 2017 From: keesb at ghs.com (Kees Bakker) Date: Wed, 8 Feb 2017 09:59:52 +0100 Subject: [Freeipa-users] Where in the login process is KRB5CCNAME being set Message-ID: Hi, This is a follow-up on the problem I had with klist: Invalid UID in persistent keyring name while getting default ccache (See "How to enable krb5_child log" earlier this month.) The situation is that we have local users with the same name that exist in IPA, but the UIDs are different. We have this on several systems, and it is because we are in the process of setting up a FreeIPA server. Now (so far), on one system the environment variable KRB5CCNAME is set during login. (Login via display manager or console, does not matter. If logged via SSH then the variable is not set.) My question: where / how is that variable being set? I'd like to understand why this one system is different from the rest. Other details: Ubuntu 16.04 (server and clients). BTW. The klist / kinit problem can easily be solved by unsetting that environment variable. -- Kees From jhrozek at redhat.com Wed Feb 8 09:11:07 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 8 Feb 2017 10:11:07 +0100 Subject: [Freeipa-users] Where in the login process is KRB5CCNAME being set In-Reply-To: References: Message-ID: <20170208091107.hbbwu43aidxktyyz@hendrix> On Wed, Feb 08, 2017 at 09:59:52AM +0100, Kees Bakker wrote: > Hi, > > This is a follow-up on the problem I had with > klist: Invalid UID in persistent keyring name while getting default ccache > (See "How to enable krb5_child log" earlier this month.) > > The situation is that we have local users with the same name that exist in IPA, > but the UIDs are different. We have this on several systems, and it is because > we are in the process of setting up a FreeIPA server. > > Now (so far), on one system the environment variable KRB5CCNAME is set during > login. (Login via display manager or console, does not matter. If logged via SSH > then the variable is not set.) > > My question: where / how is that variable being set? I'd like to understand why > this one system is different from the rest. The variable is set by pam_sss.so during the authentication phase. I suspect the difference might be in the PAM stack -- maybe on the systems where KRB5CCNAME is not set, the PAM stack is configured using pam_localuser.so so that if the username exists in /etc/passwd, only pam_unix.so is tried? > > Other details: Ubuntu 16.04 (server and clients). > > BTW. The klist / kinit problem can easily be solved by unsetting that environment > variable. > -- > Kees > > > -- > 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 blanchet at abes.fr Wed Feb 8 10:59:53 2017 From: blanchet at abes.fr (=?UTF-8?Q?Nathana=c3=abl_Blanchet?=) Date: Wed, 8 Feb 2017 11:59:53 +0100 Subject: [Freeipa-users] sudo rules are not active immediatly Message-ID: <0b2a6168-88e1-fcef-e246-ca8af359a7ff@abes.fr> Hello, on latest IPA, when adding a command to a rule or a sudo option for example, the change is not active on the user session. For example, after removing !authenticate option, I still can execute sudo commands without password. I tried to logout and relogin, but nothing changes, but on a new vm where never logeed in before it wroks. Is there a cache or somting to do so as to commands to be immediatly available? -- Nathana?l Blanchet Supervision r?seau P?le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 T?l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet at abes.fr From jan.karasek at elostech.cz Wed Feb 8 11:17:46 2017 From: jan.karasek at elostech.cz (Jan =?utf-8?Q?Kar=C3=A1sek?=) Date: Wed, 8 Feb 2017 12:17:46 +0100 (CET) Subject: [Freeipa-users] ipa- client rhel 6.9 support for UPN different then domain name In-Reply-To: References: Message-ID: <515788472.9241.1486552666991.JavaMail.zimbra@elostech.cz> Hi, thank you for help. I am running RHEL 7.3 on IPA serveres and with RHEL 7.3 clients it works really nice. Trouble is on RHEL 6 machines. I have tried to add krb5_use_enterprise_principal = true into domain section of sssd.conf on RHEL 6 IPA clients but problem still persists. Is there anything else that should be set ? I have restarted sssd service, both on servers and client, empty sssd_cache and so on but I am still unable resolve users(on RHEL 6) with short UPN - id and getent passwd return no such user...We still have more servers on RHEL 6 then on RHEL 7. Thanks, Jan > Hi, > > I just looked into RHEL 6.9 beta repos and I can see there is sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 6.9 will come support for using different UPN then domain name. I am talking about AD trust scenario where user in AD domain sits in user at subdomain.example.com but has a UPN set to user at example.com. It has been solved in RHEL 7.3 I guess with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or is there any known workaround ? This is basically a server side feature. You need an IPA server version which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically detect if the server supports this or not. This autodetection was not backported to 6.9 but if your servers support it you can set 'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details) on the IPA clients with older SSSD versions. HTH bye, Sumit > > Thanks, > Jan > From th at casalogic.dk Wed Feb 8 11:44:07 2017 From: th at casalogic.dk (Troels Hansen) Date: Wed, 8 Feb 2017 12:44:07 +0100 (CET) Subject: [Freeipa-users] ipa- client rhel 6.9 support for UPN different then domain name In-Reply-To: <515788472.9241.1486552666991.JavaMail.zimbra@elostech.cz> References: <515788472.9241.1486552666991.JavaMail.zimbra@elostech.cz> Message-ID: <7552581.1944433.1486554247760.JavaMail.zimbra@casalogic.dk> Hi, Have you tried setting ldap_user_principal to something nonexisting? For example: ldap_user_principal = nosuchattr and inherit this to the AD domain with: subdomain_inherit = ldap_user_principal Both in the domain section of sssd. ----- On Feb 8, 2017, at 12:17 PM, Jan Kar?sek jan.karasek at elostech.cz wrote: > Hi, thank you for help. > > I am running RHEL 7.3 on IPA serveres and with RHEL 7.3 clients it works really > nice. > Trouble is on RHEL 6 machines. I have tried to add krb5_use_enterprise_principal > = true into domain section of sssd.conf on RHEL 6 IPA clients but problem still > persists. Is there anything else that should be set ? I have restarted sssd > service, both on servers and client, empty sssd_cache and so on but I am still > unable resolve users(on RHEL 6) with short UPN - id and getent passwd return no > such user...We still have more servers on RHEL 6 then on RHEL 7. > > Thanks, > Jan > > >> Hi, >> >> I just looked into RHEL 6.9 beta repos and I can see there is >> sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 6.9 >> will come support for using different UPN then domain name. I am talking about >> AD trust scenario where user in AD domain sits in user at subdomain.example.com >> but has a UPN set to user at example.com. It has been solved in RHEL 7.3 I guess >> with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or is >> there any known workaround ? > > This is basically a server side feature. You need an IPA server version > which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically > detect if the server supports this or not. This autodetection was not > backported to 6.9 but if your servers support it you can set > 'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details) > on the IPA clients with older SSSD versions. > > HTH > > bye, > Sumit > >> >> Thanks, >> Jan >> > > > -- > 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From pbrezina at redhat.com Wed Feb 8 12:00:12 2017 From: pbrezina at redhat.com (=?UTF-8?Q?Pavel_B=c5=99ezina?=) Date: Wed, 8 Feb 2017 13:00:12 +0100 Subject: [Freeipa-users] sudo rules are not active immediatly In-Reply-To: <0b2a6168-88e1-fcef-e246-ca8af359a7ff@abes.fr> References: <0b2a6168-88e1-fcef-e246-ca8af359a7ff@abes.fr> Message-ID: On 02/08/2017 11:59 AM, Nathana?l Blanchet wrote: > Hello, > on latest IPA, when adding a command to a rule or a sudo option for > example, the change is not active on the user session. > For example, after removing !authenticate option, I still can execute > sudo commands without password. > I tried to logout and relogin, but nothing changes, but on a new vm > where never logeed in before it wroks. > Is there a cache or somting to do so as to commands to be immediatly > available? > Hi, sudo rules are cache on the client and refresh happens periodically. We have several update mechanisms that deals with finding new rules, deleting non-existent ones and updating expired but it cannot be performed on desired at the moment. We have a ticket for that [1]. Please see 'man sssd-sudo' to get better understanding how it works. It is possible to expired cached rules with sss_cache. This won't find you newly added rules but it will fetch updated rules and removed deleted ones. [1] https://fedorahosted.org/sssd/ticket/2884 From sbose at redhat.com Wed Feb 8 12:13:41 2017 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Feb 2017 13:13:41 +0100 Subject: [Freeipa-users] ipa- client rhel 6.9 support for UPN different then domain name In-Reply-To: <7552581.1944433.1486554247760.JavaMail.zimbra@casalogic.dk> References: <515788472.9241.1486552666991.JavaMail.zimbra@elostech.cz> <7552581.1944433.1486554247760.JavaMail.zimbra@casalogic.dk> Message-ID: <20170208121341.GN3552@p.Speedport_W_724V_Typ_A_05011603_00_011> On Wed, Feb 08, 2017 at 12:44:07PM +0100, Troels Hansen wrote: > Hi, > > Have you tried setting ldap_user_principal to something nonexisting? For example: > > ldap_user_principal = nosuchattr > > and inherit this to the AD domain with: > > subdomain_inherit = ldap_user_principal > > Both in the domain section of sssd. Enterprise principals are supported by IPA since RHEL 7.3, so this work-around for older versions should not be needed anymore. > > ----- On Feb 8, 2017, at 12:17 PM, Jan Kar?sek jan.karasek at elostech.cz wrote: > > > Hi, thank you for help. > > > > I am running RHEL 7.3 on IPA serveres and with RHEL 7.3 clients it works really > > nice. > > Trouble is on RHEL 6 machines. I have tried to add krb5_use_enterprise_principal > > = true into domain section of sssd.conf on RHEL 6 IPA clients but problem still > > persists. Is there anything else that should be set ? I have restarted sssd > > service, both on servers and client, empty sssd_cache and so on but I am still > > unable resolve users(on RHEL 6) with short UPN - id and getent passwd return no > > such user...We still have more servers on RHEL 6 then on RHEL 7. SSSD logs from a RHEL 6 client which includes a failing user lookup are needed to see why it is still failing, see https://fedorahosted.org/sssd/wiki/Troubleshooting for details. bye, Sumit > > > > Thanks, > > Jan > > > > > >> Hi, > >> > >> I just looked into RHEL 6.9 beta repos and I can see there is > >> sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 6.9 > >> will come support for using different UPN then domain name. I am talking about > >> AD trust scenario where user in AD domain sits in user at subdomain.example.com > >> but has a UPN set to user at example.com. It has been solved in RHEL 7.3 I guess > >> with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or is > >> there any known workaround ? > > > > This is basically a server side feature. You need an IPA server version > > which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically > > detect if the server supports this or not. This autodetection was not > > backported to 6.9 but if your servers support it you can set > > 'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details) > > on the IPA clients with older SSSD versions. > > > > HTH > > > > bye, > > Sumit > > > >> > >> Thanks, > >> Jan > >> > > > > > > -- > > 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 > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. > > -- > 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 dsullivan2 at bsd.uchicago.edu Wed Feb 8 13:12:12 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Wed, 8 Feb 2017 13:12:12 +0000 Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: <1291496609.1940875.1486538822821.JavaMail.zimbra@casalogic.dk> References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> <1359190682.1911254.1486367960580.JavaMail.zimbra@casalogic.dk> <1291496609.1940875.1486538822821.JavaMail.zimbra@casalogic.dk> Message-ID: Are you actually logging in or or just doing a lookup on a user? I remember reading somewhere that groups are always re-evaluated at the point of login, regardless of what is in the cache. I am not sure if this is accurate or the implications of whether or not it is on the client, server or both, but this could be what is happening. Also, how are verifying that the group in the cache on the server is valid? If you do a lookup a user on the server after the mapped memory cache expires (i.e. if you restart sssd), do you see a log entry that a valid cache entry has been found and that entry is being returned (from memory it is in the nsss logs)? It might help you to focus on the sysdb cache by setting a very low timeout value for the in memory mapped cache and or negative cache timeouts. Based on my experiencif a valid cache entry in the sysdb *NOT* found, a log entry is not returned (just a lookup is performed), which for an untrained eye makes it difficult to assess when timeouts are occurring in the sysdb cache. Also, five minutes is a ridiculously long time to have to wait, have you inspected the performance of your 389 server? Is your environment large or under large load? Based on experience and another thread from this list, I have seen the 389ds threads get tied up due to extop operations because AD lookups via SSSD eventually will be blocked sssd under high load. I had to significantly scale 389ds worker threads and processor cores to accommodate large numbers of concurrent AD lookups, this improved the performance of our environment and solved many issues. Dan > On Feb 8, 2017, at 1:27 AM, Troels Hansen wrote: > > No, ignore_group_members option is already set. > Tried setting and removing it on the client but didn't make a huge different. > > Is a client have an completely empty cache, newly joined, empty /var/lig/sssd/db and mc cache or something, the IPA server ALWAYS asks the AD for group info, despite having a valid cache. > > This leads to a delay of up to, or even more 5 minutes before a user can login. Being denied access at first, but logging again later with success. > > If the client have a cache thats only expired its able to pull the account info from the cache on the IPA, without the IPA having to contact the AD. > > > ----- On Feb 6, 2017, at 2:24 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: > >> Have you looked at the ignore_group_members option? Maybe this is the problem >> you are seeing? >> >> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ >> >> ==snip== >> >> ignore_group_members >> Normally the most data-intensive operation is downloading the groups including >> their members. Usually, we are interested in what groups a user is a member of >> (id aduser at ad_domain) as the initial step rather than what members do specific >> groups include (getent group adgroup at ad_domain). Setting the >> ignore_group_members option to True makes all groups appear as empty, thus >> downloading only information about the group objects themselves and not their >> members, providing a significant performance boost. Please note that id >> aduser at ad_domain would still return all the correct groups! >> ==snip== >> >> >> Dan >> >> On Feb 6, 2017, at 1:59 AM, Troels Hansen wrote: >> >> Hi >> >> I'm aware of the anatomy of how the lookup is done, but I would suppose a valid >> cache on the IPA server would result in the cache from the IPA server being >> used? >> >> I have been debugging this issue some more, and can confirm is the client have >> its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid >> cache, when the client asks for the user, the IPA server still asks the AD for >> the entire group info? >> >> I can see, that even though the cache is refreshed the attribute >> initgrExpireTimestamp (in the ldb cache) isn't updated. >> I have been unable to find out exactly what this controls? >> >> lastUpdate and dataExpireTimestamp is updated to the time stamp of when the >> refresh ran. >> >> >> ----- On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI] >> dsullivan2 at bsd.uchicago.edu wrote: >> >> Have you checked to see if the user is expired in the cache, or if it is >> impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry >> timeout is only 90 minutes and entry_cache_nowait_percentage default is 50. >> >> ldbsearch -H /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb > >> ~/timestamps.txt >> ldbsearch -H /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt >> >> Might be able to provide more info. >> >> Again, I?d really familiarize yourself with the anatomy of an sssd lookup, if >> you get to know the diagram and steps 1-7 here it will be a big help to your >> question(s). >> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ >> >> Dan >> >> >> On Feb 1, 2017, at 4:32 AM, Troels Hansen wrote: >> >> From looking af at TCP dump, I can see that if a client requests a AD user from >> IPA, IPA does a full user lookup in AD, even though the IPA server have the >> user in local cache? >> >> It looks like a single group generates a LOT of traffic to AD like: >> client -> IPA >> IPA -> client >> IPA -> AD >> AD -> IPA >> IPA -> AD >> IPA -> Second AD >> Second AD -> IPA >> IPA -> Second AD >> IPA -> AD >> AD -> IPA >> IPA -> AD >> IPA -> client >> client -> IPA >> IPA -> Client >> >> Something similar continues for every group the user has. >> >> Soo, I guess the question that I haven't been able to find documented anywhere. >> Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd >> client requests a user? >> >> >> >> ----- On Feb 1, 2017, at 9:53 AM, Troels Hansen th at casalogic.dk wrote: >> >> Hmm, suspect its happening on the server...... thous I haven't been able to >> pinpoint a log entry that confirms my suspecting. >> >> I have pinpointed the timeout to happen after 58 seconds after completely >> removing the SSSD cache and restaring SSSD, which leads me to think my issue is >> related to ldap_enumaration_search_timeout which defaults to 60. >> >> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja >> >> However, I'm unable to crank it up on the server as it seems to be adjusted Down >> to 60 Again? >> >> Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option >> ldap_enumeration_search_timeout has value 120 >> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >> Option ldap_enumeration_search_timeout has value 60 >> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >> Option ldap_enumeration_search_timeout has value 60 >> >> LDAP seems speedy enough, not timeouts while querying it manually while a client >> is doing a user lookup. >> >> ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] >> dsullivan2 at bsd.uchicago.edu wrote: >> >> >> If the timeout is occurring on the server, I would start by increasing one or >> both of these values: >> >> ldap_opt_timeout >> ldap_search_timeout >> >> If that doesn?t work I?d take look to see if the 389 server is under high load >> when you are performing this operation. The easiest way I have found to do >> this is to just execute an LDAP query directly against the IPA server when you >> are performing an id lookup, for example: >> >> ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" >> "(objectclass=*)? >> >> If the LDAP server is not responsive you probably need to increase the number of >> worker threads for 389ds. Also, you might want to disable referrals, check out >> the man pages for this; >> >> ldap_referrals = false >> >> Also, FWIW, if you crank up debug logging on the sssd client, you should be able >> to see the amount of seconds of timeout assigned to the operation, and witness >> the fact that the operation is actually timing out by inspecting the logs >> themselves. The logs can get a little verbose but the data is there. >> >> >> -- >> 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 >> >> -- >> Med venlig hilsen >> >> Troels Hansen >> >> Systemkonsulent >> >> Casalogic A/S >> >> >> T (+45) 70 20 10 63 >> >> M (+45) 22 43 71 57 >> >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >> meget mere. >> >> -- >> 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 >> >> -- >> Med venlig hilsen >> >> Troels Hansen >> >> Systemkonsulent >> >> Casalogic A/S >> >> >> T (+45) 70 20 10 63 >> >> M (+45) 22 43 71 57 >> >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >> meget mere. > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From th at casalogic.dk Wed Feb 8 13:25:51 2017 From: th at casalogic.dk (Troels Hansen) Date: Wed, 8 Feb 2017 14:25:51 +0100 (CET) Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <859174878.1858332.1485939195647.JavaMail.zimbra@casalogic.dk> <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> <1359190682.1911254.1486367960580.JavaMail.zimbra@casalogic.dk> <1291496609.1940875.1486538822821.JavaMail.zimbra@casalogic.dk> Message-ID: <2146577764.1946080.1486560351510.JavaMail.zimbra@casalogic.dk> Cache is verified valid by looking at the cache files /var/lib/sss/db/ ldb files. Also, if I lookup the user on the IPA server I get a fast response. Looking up the user on a client which have a valid cache return the user within a few ms or secs. Invalidating the cache on the client with sss_cache results in the user being fetched from the IPA server. This takes about 15-20 seconds. This is acceptable. If I do a tcpdump of ldap traffic while this happens I only see traffic between sssd client and ipa server. Then I remove the cache files and restarts sssd on the client, simulating a newly joined client or a client that have cleaned up its ldb cache (ldap_purge_cache_timeout=0 only set on the server). At this point the IPA server still have a valid cache. Looking up the user while tcpdumping on IPA server I can see what looks like IPA fetches the entire information from AD. This is ~730 groups, mostly nested groups for this user. This takes 5-7 minutes........ The LDAP responds quickly, no CPU load, and I can do manual LDAP lookups then the user is fetched, so nothing that points to a busy LDAP. It doesn't matter if I do a lookup of the user or he logs in. Its the same behavior. Currently its very limited load, but this is going to scale up later on. ----- On Feb 8, 2017, at 2:12 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote: > Are you actually logging in or or just doing a lookup on a user? I remember > reading somewhere that groups are always re-evaluated at the point of login, > regardless of what is in the cache. I am not sure if this is accurate or the > implications of whether or not it is on the client, server or both, but this > could be what is happening. > > Also, how are verifying that the group in the cache on the server is valid? If > you do a lookup a user on the server after the mapped memory cache expires > (i.e. if you restart sssd), do you see a log entry that a valid cache entry has > been found and that entry is being returned (from memory it is in the nsss > logs)? It might help you to focus on the sysdb cache by setting a very low > timeout value for the in memory mapped cache and or negative cache timeouts. > Based on my experiencif a valid cache entry in the sysdb *NOT* found, a log > entry is not returned (just a lookup is performed), which for an untrained eye > makes it difficult to assess when timeouts are occurring in the sysdb cache. > > Also, five minutes is a ridiculously long time to have to wait, have you > inspected the performance of your 389 server? Is your environment large or > under large load? Based on experience and another thread from this list, I > have seen the 389ds threads get tied up due to extop operations because AD > lookups via SSSD eventually will be blocked sssd under high load. > > I had to significantly scale 389ds worker threads and processor cores to > accommodate large numbers of concurrent AD lookups, this improved the > performance of our environment and solved many issues. > > Dan > >> On Feb 8, 2017, at 1:27 AM, Troels Hansen wrote: >> >> No, ignore_group_members option is already set. >> Tried setting and removing it on the client but didn't make a huge different. >> >> Is a client have an completely empty cache, newly joined, empty /var/lig/sssd/db >> and mc cache or something, the IPA server ALWAYS asks the AD for group info, >> despite having a valid cache. >> >> This leads to a delay of up to, or even more 5 minutes before a user can login. >> Being denied access at first, but logging again later with success. >> >> If the client have a cache thats only expired its able to pull the account info >> from the cache on the IPA, without the IPA having to contact the AD. >> >> >> ----- On Feb 6, 2017, at 2:24 PM, Sullivan, Daniel [CRI] >> dsullivan2 at bsd.uchicago.edu wrote: >> >>> Have you looked at the ignore_group_members option? Maybe this is the problem >>> you are seeing? >>> >>> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ >>> >>> ==snip== >>> >>> ignore_group_members >>> Normally the most data-intensive operation is downloading the groups including >>> their members. Usually, we are interested in what groups a user is a member of >>> (id aduser at ad_domain) as the initial step rather than what members do specific >>> groups include (getent group adgroup at ad_domain). Setting the >>> ignore_group_members option to True makes all groups appear as empty, thus >>> downloading only information about the group objects themselves and not their >>> members, providing a significant performance boost. Please note that id >>> aduser at ad_domain would still return all the correct groups! >>> ==snip== >>> >>> >>> Dan >>> >>> On Feb 6, 2017, at 1:59 AM, Troels Hansen wrote: >>> >>> Hi >>> >>> I'm aware of the anatomy of how the lookup is done, but I would suppose a valid >>> cache on the IPA server would result in the cache from the IPA server being >>> used? >>> >>> I have been debugging this issue some more, and can confirm is the client have >>> its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid >>> cache, when the client asks for the user, the IPA server still asks the AD for >>> the entire group info? >>> >>> I can see, that even though the cache is refreshed the attribute >>> initgrExpireTimestamp (in the ldb cache) isn't updated. >>> I have been unable to find out exactly what this controls? >>> >>> lastUpdate and dataExpireTimestamp is updated to the time stamp of when the >>> refresh ran. >>> >>> >>> ----- On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI] >>> dsullivan2 at bsd.uchicago.edu wrote: >>> >>> Have you checked to see if the user is expired in the cache, or if it is >>> impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry >>> timeout is only 90 minutes and entry_cache_nowait_percentage default is 50. >>> >>> ldbsearch -H /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb > >>> ~/timestamps.txt >>> ldbsearch -H /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt >>> >>> Might be able to provide more info. >>> >>> Again, I?d really familiarize yourself with the anatomy of an sssd lookup, if >>> you get to know the diagram and steps 1-7 here it will be a big help to your >>> question(s). >>> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ >>> >>> Dan >>> >>> >>> On Feb 1, 2017, at 4:32 AM, Troels Hansen wrote: >>> >>> From looking af at TCP dump, I can see that if a client requests a AD user from >>> IPA, IPA does a full user lookup in AD, even though the IPA server have the >>> user in local cache? >>> >>> It looks like a single group generates a LOT of traffic to AD like: >>> client -> IPA >>> IPA -> client >>> IPA -> AD >>> AD -> IPA >>> IPA -> AD >>> IPA -> Second AD >>> Second AD -> IPA >>> IPA -> Second AD >>> IPA -> AD >>> AD -> IPA >>> IPA -> AD >>> IPA -> client >>> client -> IPA >>> IPA -> Client >>> >>> Something similar continues for every group the user has. >>> >>> Soo, I guess the question that I haven't been able to find documented anywhere. >>> Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd >>> client requests a user? >>> >>> >>> >>> ----- On Feb 1, 2017, at 9:53 AM, Troels Hansen th at casalogic.dk wrote: >>> >>> Hmm, suspect its happening on the server...... thous I haven't been able to >>> pinpoint a log entry that confirms my suspecting. >>> >>> I have pinpointed the timeout to happen after 58 seconds after completely >>> removing the SSSD cache and restaring SSSD, which leads me to think my issue is >>> related to ldap_enumaration_search_timeout which defaults to 60. >>> >>> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja >>> >>> However, I'm unable to crank it up on the server as it seems to be adjusted Down >>> to 60 Again? >>> >>> Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option >>> ldap_enumeration_search_timeout has value 120 >>> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >>> Option ldap_enumeration_search_timeout has value 60 >>> (Wed Feb 1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): >>> Option ldap_enumeration_search_timeout has value 60 >>> >>> LDAP seems speedy enough, not timeouts while querying it manually while a client >>> is doing a user lookup. >>> >>> ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] >>> dsullivan2 at bsd.uchicago.edu wrote: >>> >>> >>> If the timeout is occurring on the server, I would start by increasing one or >>> both of these values: >>> >>> ldap_opt_timeout >>> ldap_search_timeout >>> >>> If that doesn?t work I?d take look to see if the 389 server is under high load >>> when you are performing this operation. The easiest way I have found to do >>> this is to just execute an LDAP query directly against the IPA server when you >>> are performing an id lookup, for example: >>> >>> ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" >>> "(objectclass=*)? >>> >>> If the LDAP server is not responsive you probably need to increase the number of >>> worker threads for 389ds. Also, you might want to disable referrals, check out >>> the man pages for this; >>> >>> ldap_referrals = false >>> >>> Also, FWIW, if you crank up debug logging on the sssd client, you should be able >>> to see the amount of seconds of timeout assigned to the operation, and witness >>> the fact that the operation is actually timing out by inspecting the logs >>> themselves. The logs can get a little verbose but the data is there. >>> >>> >>> -- >>> 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 >>> >>> -- >>> Med venlig hilsen >>> >>> Troels Hansen >>> >>> Systemkonsulent >>> >>> Casalogic A/S >>> >>> >>> T (+45) 70 20 10 63 >>> >>> M (+45) 22 43 71 57 >>> >>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >>> meget mere. >>> >>> -- >>> 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 >>> >>> -- >>> Med venlig hilsen >>> >>> Troels Hansen >>> >>> Systemkonsulent >>> >>> Casalogic A/S >>> >>> >>> T (+45) 70 20 10 63 >>> >>> M (+45) 22 43 71 57 >>> >>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >>> meget mere. >> >> -- >> Med venlig hilsen >> >> Troels Hansen >> >> Systemkonsulent >> >> Casalogic A/S >> >> >> T (+45) 70 20 10 63 >> >> M (+45) 22 43 71 57 >> >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > > meget mere. -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From blanchet at abes.fr Wed Feb 8 15:03:54 2017 From: blanchet at abes.fr (=?UTF-8?Q?Nathana=c3=abl_Blanchet?=) Date: Wed, 8 Feb 2017 16:03:54 +0100 Subject: [Freeipa-users] sudo rules are not active immediatly In-Reply-To: References: <0b2a6168-88e1-fcef-e246-ca8af359a7ff@abes.fr> Message-ID: <39aa3788-2f0a-191d-4440-a817a863995e@abes.fr> Le 08/02/2017 ? 13:00, Pavel B?ezina a ?crit : > On 02/08/2017 11:59 AM, Nathana?l Blanchet wrote: >> Hello, >> on latest IPA, when adding a command to a rule or a sudo option for >> example, the change is not active on the user session. >> For example, after removing !authenticate option, I still can execute >> sudo commands without password. >> I tried to logout and relogin, but nothing changes, but on a new vm >> where never logeed in before it wroks. >> Is there a cache or somting to do so as to commands to be immediatly >> available? >> > > Hi, > sudo rules are cache on the client and refresh happens periodically. > We have several update mechanisms that deals with finding new rules, > deleting non-existent ones and updating expired but it cannot be > performed on desired at the moment. We have a ticket for that [1]. > Please see 'man sssd-sudo' to get better understanding how it works. > it's said that sssd-sudo has been created to be near of the local sudoers functionnment. So I suppose the three described mechanisms are intended to converge to a near realtime rule change. It's true that waiting for an undefinied time, rules become available... but is there an estimated time of availibility? Is it rather 15min or one hour (I suppose beyond is not usable) > It is possible to expired cached rules with sss_cache. This won't find > you newly added rules but it will fetch updated rules and removed > deleted ones. > > [1] https://fedorahosted.org/sssd/ticket/2884 > From armaan.esfahani at advancedopen.com Wed Feb 8 15:47:48 2017 From: armaan.esfahani at advancedopen.com (Armaan Esfahani) Date: Wed, 08 Feb 2017 10:47:48 -0500 Subject: [Freeipa-users] Where is SID stored after ipa-adtrust-install? Message-ID: I?ve been having issues with some of my IPA seemingly not getting SID?s after the install, even after running with the ?add-sids modifier. I was wondering where the SID values are located so that I can take a look at what?s happening/ -- Armaan Esfahani Advanced Open Systems m:(470) 377-2115 a:2440 Sandy Plains Rd. Marietta GA, 30062 Bldg 4 Ste D e:armaan.esfahani at advancedopen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 8 16:10:54 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Feb 2017 18:10:54 +0200 Subject: [Freeipa-users] Where is SID stored after ipa-adtrust-install? In-Reply-To: References: Message-ID: <20170208161054.x2psmnzokjufx5yn@redhat.com> On ke, 08 helmi 2017, Armaan Esfahani wrote: >I?ve been having issues with some of my IPA seemingly not getting SID?s >after the install, even after running with the ?add-sids modifier. I >was wondering where the SID values are located so that I can take a >look at what?s happening/ In the user object itself, ipaNTSecurityIdentifier attribute. If you have SIDs not generated, there are two potential issues that cause it: - sidgen plugin configuration looking at wrong basedn - ID ranges you have do not allow to map UID/GID to SID If you ran ipa-adtrust-install --add-sids and it generated nothing, look at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at least two lines: [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [0]. If there are any errors causing issues with SID generation, they will be in between these two lines. -- / Alexander Bokovoy From armaan.esfahani at advancedopen.com Wed Feb 8 16:19:37 2017 From: armaan.esfahani at advancedopen.com (Armaan Esfahani) Date: Wed, 08 Feb 2017 11:19:37 -0500 Subject: [Freeipa-users] Where is SID stored after ipa-adtrust-install? In-Reply-To: <20170208161054.x2psmnzokjufx5yn@redhat.com> References: <20170208161054.x2psmnzokjufx5yn@redhat.com> Message-ID: I have found the following. [08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [08/Feb/2017:11:14:38 -0500] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [755400050] into an unused SID. [08/Feb/2017:11:14:38 -0500] do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. I assume this is the second possibility you brought up, the ID ranges I have setup do not allow mapping of UID/GID to SID On 2/8/17, 11:10 AM, "Alexander Bokovoy" wrote: On ke, 08 helmi 2017, Armaan Esfahani wrote: >I?ve been having issues with some of my IPA seemingly not getting SID?s >after the install, even after running with the ?add-sids modifier. I >was wondering where the SID values are located so that I can take a >look at what?s happening/ In the user object itself, ipaNTSecurityIdentifier attribute. If you have SIDs not generated, there are two potential issues that cause it: - sidgen plugin configuration looking at wrong basedn - ID ranges you have do not allow to map UID/GID to SID If you ran ipa-adtrust-install --add-sids and it generated nothing, look at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at least two lines: [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [0]. If there are any errors causing issues with SID generation, they will be in between these two lines. -- / Alexander Bokovoy From jgoddard at emerlyn.com Wed Feb 8 16:21:31 2017 From: jgoddard at emerlyn.com (Jeff Goddard) Date: Wed, 8 Feb 2017 11:21:31 -0500 Subject: [Freeipa-users] Where is SID stored after ipa-adtrust-install? In-Reply-To: <20170208161054.x2psmnzokjufx5yn@redhat.com> References: <20170208161054.x2psmnzokjufx5yn@redhat.com> Message-ID: I had this same issue and the value was only added after a password change. Jeff On Wed, Feb 8, 2017 at 11:10 AM, Alexander Bokovoy wrote: > On ke, 08 helmi 2017, Armaan Esfahani wrote: > >> I?ve been having issues with some of my IPA seemingly not getting SID?s >> after the install, even after running with the ?add-sids modifier. I >> was wondering where the SID values are located so that I can take a >> look at what?s happening/ >> > In the user object itself, ipaNTSecurityIdentifier attribute. > > If you have SIDs not generated, there are two potential issues that > cause it: > - sidgen plugin configuration looking at wrong basedn > - ID ranges you have do not allow to map UID/GID to SID > > If you ran ipa-adtrust-install --add-sids and it generated nothing, look > at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at > least two lines: > > [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file > ipa_sidgen_task.c, line 194]: Sidgen task starts ... > [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file > ipa_sidgen_task.c, line 199]: Sidgen task finished [0]. > > If there are any errors causing issues with SID generation, they will be > in between these two lines. > > > -- > / 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From armaan.esfahani at advancedopen.com Wed Feb 8 16:55:43 2017 From: armaan.esfahani at advancedopen.com (Armaan Esfahani) Date: Wed, 08 Feb 2017 11:55:43 -0500 Subject: [Freeipa-users] Where is SID stored after ipa-adtrust-install? In-Reply-To: References: <20170208161054.x2psmnzokjufx5yn@redhat.com> Message-ID: Hey Jeff, that is also happening here, however only with users created after the ipa-adtrust-install. For example, the admin user fails to ever be authenticated despite numerous password resets, yet if I were to create a new account and reset it?s password it works fine. From: Jeff Goddard Date: Wednesday, February 8, 2017 at 11:21 AM To: Alexander Bokovoy Cc: Armaan Esfahani , Subject: Re: [Freeipa-users] Where is SID stored after ipa-adtrust-install? I had this same issue and the value was only added after a password change. Jeff On Wed, Feb 8, 2017 at 11:10 AM, Alexander Bokovoy wrote: On ke, 08 helmi 2017, Armaan Esfahani wrote: I?ve been having issues with some of my IPA seemingly not getting SID?s after the install, even after running with the ?add-sids modifier. I was wondering where the SID values are located so that I can take a look at what?s happening/ In the user object itself, ipaNTSecurityIdentifier attribute. If you have SIDs not generated, there are two potential issues that cause it: - sidgen plugin configuration looking at wrong basedn - ID ranges you have do not allow to map UID/GID to SID If you ran ipa-adtrust-install --add-sids and it generated nothing, look at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at least two lines: [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [0]. If there are any errors causing issues with SID generation, they will be in between these two lines. -- / 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 8 17:20:19 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Feb 2017 19:20:19 +0200 Subject: [Freeipa-users] Where is SID stored after ipa-adtrust-install? In-Reply-To: References: <20170208161054.x2psmnzokjufx5yn@redhat.com> Message-ID: <20170208172019.6t6qmlf2zglwkhht@redhat.com> On ke, 08 helmi 2017, Armaan Esfahani wrote: >I have found the following. > >[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... >[08/Feb/2017:11:14:38 -0500] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [755400050] into an unused SID. >[08/Feb/2017:11:14:38 -0500] do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. >[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. > >I assume this is the second possibility you brought up, the ID ranges I >have setup do not allow mapping of UID/GID to SID Yes. Check existing ID ranges to see if you have one that covers POSIX ID 755400050. If there is none, you need to create another ID range that covers those users. This typically comes from cases where POSIX IDs were assigned manually or from already existing source via migration. At this point FreeIPA would not have an ID range that covers these pre-allocated IDs. So you need to define several variables here: - base ID of the range - range size -- enough to cover those existing users and groups that are outside of IPA ID range - RID bases -- since we are building SIDs for the same domain, the RID base and secondary RID base should not be overlapping with existing IPA ID range For example, if you have 100 users starting around 755400000 and your default IPA ID range has 200000 entries (default range size), then mapping RID base above that one would be enough. ipa idrange-add MY.DOM.AIN-extra_id_range --base-id=755400000 --range-size=100 \ --rid-base=500000 --secondary-rid-base=500100 \ --type=ipa-local Adding this range would be enough -- there will not be any allocation of POSIX IDs in the range but sidgen plugin will be able to use the range to drive SID allocation. > >On 2/8/17, 11:10 AM, "Alexander Bokovoy" wrote: > > On ke, 08 helmi 2017, Armaan Esfahani wrote: > >I?ve been having issues with some of my IPA seemingly not getting SID?s > >after the install, even after running with the ?add-sids modifier. I > >was wondering where the SID values are located so that I can take a > >look at what?s happening/ > In the user object itself, ipaNTSecurityIdentifier attribute. > > If you have SIDs not generated, there are two potential issues that > cause it: > - sidgen plugin configuration looking at wrong basedn > - ID ranges you have do not allow to map UID/GID to SID > > If you ran ipa-adtrust-install --add-sids and it generated nothing, look > at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at > least two lines: > > [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... > [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [0]. > > If there are any errors causing issues with SID generation, they will be > in between these two lines. > > > -- > / 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 armaan.esfahani at advancedopen.com Wed Feb 8 17:48:15 2017 From: armaan.esfahani at advancedopen.com (Armaan Esfahani) Date: Wed, 08 Feb 2017 12:48:15 -0500 Subject: [Freeipa-users] Where is SID stored after ipa-adtrust-install? In-Reply-To: <20170208172019.6t6qmlf2zglwkhht@redhat.com> References: <20170208161054.x2psmnzokjufx5yn@redhat.com> <20170208172019.6t6qmlf2zglwkhht@redhat.com> Message-ID: <3D9E968F-6447-4327-82DC-E68BE8545DBB@advancedopen.com> It worked! Thanks so much for your help. On 2/8/17, 12:20 PM, "Alexander Bokovoy" wrote: On ke, 08 helmi 2017, Armaan Esfahani wrote: >I have found the following. > >[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... >[08/Feb/2017:11:14:38 -0500] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [755400050] into an unused SID. >[08/Feb/2017:11:14:38 -0500] do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. >[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. > >I assume this is the second possibility you brought up, the ID ranges I >have setup do not allow mapping of UID/GID to SID Yes. Check existing ID ranges to see if you have one that covers POSIX ID 755400050. If there is none, you need to create another ID range that covers those users. This typically comes from cases where POSIX IDs were assigned manually or from already existing source via migration. At this point FreeIPA would not have an ID range that covers these pre-allocated IDs. So you need to define several variables here: - base ID of the range - range size -- enough to cover those existing users and groups that are outside of IPA ID range - RID bases -- since we are building SIDs for the same domain, the RID base and secondary RID base should not be overlapping with existing IPA ID range For example, if you have 100 users starting around 755400000 and your default IPA ID range has 200000 entries (default range size), then mapping RID base above that one would be enough. ipa idrange-add MY.DOM.AIN-extra_id_range --base-id=755400000 --range-size=100 \ --rid-base=500000 --secondary-rid-base=500100 \ --type=ipa-local Adding this range would be enough -- there will not be any allocation of POSIX IDs in the range but sidgen plugin will be able to use the range to drive SID allocation. > >On 2/8/17, 11:10 AM, "Alexander Bokovoy" wrote: > > On ke, 08 helmi 2017, Armaan Esfahani wrote: > >I?ve been having issues with some of my IPA seemingly not getting SID?s > >after the install, even after running with the ?add-sids modifier. I > >was wondering where the SID values are located so that I can take a > >look at what?s happening/ > In the user object itself, ipaNTSecurityIdentifier attribute. > > If you have SIDs not generated, there are two potential issues that > cause it: > - sidgen plugin configuration looking at wrong basedn > - ID ranges you have do not allow to map UID/GID to SID > > If you ran ipa-adtrust-install --add-sids and it generated nothing, look > at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at > least two lines: > > [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... > [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [0]. > > If there are any errors causing issues with SID generation, they will be > in between these two lines. > > > -- > / 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 me at benroberts.net Wed Feb 8 22:59:20 2017 From: me at benroberts.net (Ben Roberts) Date: Wed, 8 Feb 2017 22:59:20 +0000 Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records Message-ID: Hi all, This is a question more about bind-dyndb-ldap rather than freeipa, but I understand it's written/maintained by the freeipa project and so this might be the most appropriate place to ask. I have setup bind-dyndb-ldap to read some zones from openldap, with multiple nameservers acting as masters and one nameserver running as a slave via the usual notify/transfer mechanism. I'm not seeing any DS records transfer across to the slave nameserver, nor when I manually query the primaries with an AFXR request. This includes both the apex DS records, automatically generated by bind-dyndb-ldap, but more importantly the glue dSRecord objects for a delegated subdomain. I note that the dSRecord entries are present in /var/named/dyndb-ldap/$view/master/$zone/raw but not present in /var/named/dyndb-ldap/$view/master/$zone/signed. Example (domain name and ip addresses obfuscated, but all other fields are unmodified): $ dig +noall +answer DS subdomain.example.local @127.0.01 subdomain.example.local. 600 IN DS 38589 7 1 6C410EF5A47631FBA2C3BC295A90363EA86A1846 subdomain.example.local. 600 IN DS 38589 7 2 23E22A49BBF2AD0E3F4668CB4C0DB52EE60ACA4308C1DE002A47AD7B 99734334 $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | head -n 1 subdomain.example.local. 600 IN SOA ns1.example.local. hostmaster.example.local. 2016050416 43200 3600 1209600 3600 $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | grep '\bDS\b' $ This behaviour doesn't seem right to me. I would expect the DS records to be transferred to the slaves as normal so that any glue records are correctly present on all nameservers. I can't see any references in the bind-dyndb-ldap wiki/readme or code comments that would explain DS records being treated specially, but please do correct me if I'm wrong. Regards, Ben Roberts -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkrizek at redhat.com Thu Feb 9 09:26:21 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Thu, 9 Feb 2017 10:26:21 +0100 Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records In-Reply-To: References: Message-ID: On 02/08/2017 11:59 PM, Ben Roberts wrote: > Hi all, > > This is a question more about bind-dyndb-ldap rather than freeipa, but > I understand it's written/maintained by the freeipa project and so > this might be the most appropriate place to ask. I have setup > bind-dyndb-ldap to read some zones from openldap, with multiple > nameservers acting as masters and one nameserver running as a slave > via the usual notify/transfer mechanism. I'm not seeing any DS records > transfer across to the slave nameserver, nor when I manually query the > primaries with an AFXR request. This includes both the apex DS > records, automatically generated by bind-dyndb-ldap, but more > importantly the glue dSRecord objects for a delegated subdomain. > > I note that the dSRecord entries are present in > /var/named/dyndb-ldap/$view/master/$zone/raw but not present in > /var/named/dyndb-ldap/$view/master/$zone/signed. > > Example (domain name and ip addresses obfuscated, but all other fields > are unmodified): > $ dig +noall +answer DS subdomain.example.local @127.0.01 > subdomain.example.local. 600 IN DS 38589 7 1 > 6C410EF5A47631FBA2C3BC295A90363EA86A1846 > subdomain.example.local. 600 IN DS 38589 7 2 > 23E22A49BBF2AD0E3F4668CB4C0DB52EE60ACA4308C1DE002A47AD7B 99734334 > > $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 > | head -n 1 > subdomain.example.local. 600 IN SOA ns1.example.local. > hostmaster.example.local. 2016050416 43200 3600 1209600 3600 > > $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 > | grep '\bDS\b' > $ > > This behaviour doesn't seem right to me. I would expect the DS records > to be transferred to the slaves as normal so that any glue records are > correctly present on all nameservers. I can't see any references in > the bind-dyndb-ldap wiki/readme or code comments that would explain DS > records being treated specially, but please do correct me if I'm wrong. > > Regards, > Ben Roberts > > Hi, when I add a DS record to LDAP (without any DNSSEC configuration), it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1. I suppose you have DNSSEC configured. Could you be affected by the limitations mentioned in [1]? [1] - https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/OpenDNSSEC2BINDKeyStates#Limitationsmissingfeatures -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From pbrezina at redhat.com Thu Feb 9 09:51:54 2017 From: pbrezina at redhat.com (=?UTF-8?Q?Pavel_B=c5=99ezina?=) Date: Thu, 9 Feb 2017 10:51:54 +0100 Subject: [Freeipa-users] sudo rules are not active immediatly In-Reply-To: <39aa3788-2f0a-191d-4440-a817a863995e@abes.fr> References: <0b2a6168-88e1-fcef-e246-ca8af359a7ff@abes.fr> <39aa3788-2f0a-191d-4440-a817a863995e@abes.fr> Message-ID: <9ce7dbaa-bdab-3977-76d9-658ea5faa750@redhat.com> On 02/08/2017 04:03 PM, Nathana?l Blanchet wrote: > > > Le 08/02/2017 ? 13:00, Pavel B?ezina a ?crit : >> On 02/08/2017 11:59 AM, Nathana?l Blanchet wrote: >>> Hello, >>> on latest IPA, when adding a command to a rule or a sudo option for >>> example, the change is not active on the user session. >>> For example, after removing !authenticate option, I still can execute >>> sudo commands without password. >>> I tried to logout and relogin, but nothing changes, but on a new vm >>> where never logeed in before it wroks. >>> Is there a cache or somting to do so as to commands to be immediatly >>> available? >>> >> >> Hi, >> sudo rules are cache on the client and refresh happens periodically. >> We have several update mechanisms that deals with finding new rules, >> deleting non-existent ones and updating expired but it cannot be >> performed on desired at the moment. We have a ticket for that [1]. >> Please see 'man sssd-sudo' to get better understanding how it works. >> > it's said that sssd-sudo has been created to be near of the local > sudoers functionnment. So I suppose the three described mechanisms are > intended to converge to a near realtime rule change. > It's true that waiting for an undefinied time, rules become available... > but is there an estimated time of availibility? Is it rather 15min or > one hour (I suppose beyond is not usable) >> It is possible to expired cached rules with sss_cache. This won't find >> you newly added rules but it will fetch updated rules and removed >> deleted ones. >> >> [1] https://fedorahosted.org/sssd/ticket/2884 Depending on how often does your environment change, you can adjust sudo rules updates with following options: - entry_cache_sudo_timeout -- how long is the cache ruled valid, when the timeout is exceeded the rule is updated from ldap - ldap_sudo_smart_refresh_interval -- periodical update that fetches newly added or modified rules from the last lookup (uses modifyTimestamp/entryUSN operational attribute to do so) - ldap_sudo_full_refresh_interval -- periodical update that simply deletes current cached rules and downloads those stored in ldap From me at benroberts.net Thu Feb 9 09:53:38 2017 From: me at benroberts.net (Ben Roberts) Date: Thu, 9 Feb 2017 09:53:38 +0000 Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records In-Reply-To: References: Message-ID: Hi Tomas, > when I add a DS record to LDAP (without any DNSSEC configuration), > it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1. > > I suppose you have DNSSEC configured. Could you be affected by the > limitations mentioned in [1]? Yes, dnssec is otherwise fully configured (the only bit I don't yet have is the DS records for the "example.local" parent domain registered upstream, but that shouldn't have any impact here. I don't think the linked limitations apply, I'm not attempting to use the CDS or CDNSKEY record types, and am manually specifying the DS records for the child zone. This is with bind 9.11 and bind-dyndb-ldap 11.0. Regards, Ben Roberts From nick.piper at cgi.com Thu Feb 9 10:40:27 2017 From: nick.piper at cgi.com (Piper, Nick) Date: Thu, 9 Feb 2017 10:40:27 +0000 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA Message-ID: Hi FreeIPA-users, We're currently using FreeIPA 4.2.0, and we have two unrelated instances of IdM server. We'd like the user list which IPA maintains in one, to be a superset of the other; so we're looking for one way replication (of cn=users,cn=accounts,dc=realm, not necessarily of host entries etc.) We use a different 'dc' in each instance, and could use a different cn too if needed. So far we've found instructions on full mutual replication: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html and a one way sync from Active Directory: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree but not one way sync from IPA. I'm hoping that we can do this between two IPA instances, probably still using ipa-replica-manage, although oneWaySync only has options 'fromWindows' and 'toWindows' according to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree . Is there anything actually ActiveDirectory specific about this? We believe we need one way sync (including passwords) to be able to authenticate users which are mastered in the 'remote' IPA, even when the 'remote' IPA is offline. Another option we might explore is 'cross-forest trust', although I believe this would make authentication unavailable if the 'master' IPA is unavailable. Both are discussed at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect , but again in the context of AD/IPA rather than IPA/IPA. I'd welcome any pointers on trust or one-way replication between two IPA instances! Many thanks, Nick -- CGI IT UK Limited. A CGI Group Inc. Company Registered Office 250 Brook Drive, Green Park, Reading RG2 6UA, United Kingdom. Registered in England & Wales - Number 947968 From abokovoy at redhat.com Thu Feb 9 11:28:48 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Feb 2017 13:28:48 +0200 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA In-Reply-To: References: Message-ID: <20170209112848.i6pad2ye5jo6jbx6@redhat.com> On to, 09 helmi 2017, Piper, Nick wrote: >Hi FreeIPA-users, > >We're currently using FreeIPA 4.2.0, and we have two unrelated >instances of IdM server. We'd like the user list which IPA maintains >in one, to be a superset of the other; so we're looking for one way >replication (of cn=users,cn=accounts,dc=realm, not necessarily of host >entries etc.) > >We use a different 'dc' in each instance, and could use a different cn >too if needed. In short, there is no support for IPA-IPA trust or replication. There are many reasons for that, including some complex technical issues on how this could be reliably working. If you are after actual POSIX systems where users need to logon to use their services, you may try to configure SSSD with two different domains (for IPA1 and IPA2). You can look at discussion we had in 2014: https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html You are not necessarily need to enroll the machine in two different realms, any Kerberos principal would do instead of a host principal to authenticate against IPA LDAP (see sssd-ldap man page for details on ldap_sasl_authid). > >So far we've found instructions on full mutual replication: >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html This one is for generic 389-ds replication of IPA flat DIT. >and a one way sync from Active Directory: >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree This one is for synchronizing with the help of a special daemon running on Windows Server side. > >but not one way sync from IPA. > >I'm hoping that we can do this between two IPA instances, probably >still using ipa-replica-manage, although oneWaySync only has options >'fromWindows' and 'toWindows' according to >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree >. Is there anything actually ActiveDirectory specific about this? Yes, it depends on specific windows program that is running on Windows domain controllers and plugs into their infrastructure of user information updates. >We believe we need one way sync (including passwords) to be able to >authenticate users which are mastered in the 'remote' IPA, even when >the 'remote' IPA is offline. Another option we might explore is >'cross-forest trust', although I believe this would make >authentication unavailable if the 'master' IPA is unavailable. Both >are discussed at >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect >, but again in the context of AD/IPA rather than IPA/IPA. > >I'd welcome any pointers on trust or one-way replication between two >IPA instances! You are stuck, there is no such support between different IPA deployments. It would help to actually explain your real use case. So far you outlined above your approaches to solve a problem which is not really stated upfront. -- / Alexander Bokovoy From nick.piper at cgi.com Thu Feb 9 13:45:42 2017 From: nick.piper at cgi.com (Piper, Nick) Date: Thu, 9 Feb 2017 13:45:42 +0000 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA In-Reply-To: <20170209112848.i6pad2ye5jo6jbx6@redhat.com> References: , <20170209112848.i6pad2ye5jo6jbx6@redhat.com> Message-ID: Hi Alexander, Alexander Bokovoy wrote: >On to, 09 helmi 2017, Piper, Nick wrote: >>We're currently using FreeIPA 4.2.0, and we have two unrelated >>instances of IdM server. We'd like the user list which IPA maintains >>in one, to be a superset of the other; so we're looking for one way >>replication (of cn=users,cn=accounts,dc=realm, not necessarily of host >>entries etc.) >>We use a different 'dc' in each instance, and could use a different cn >>too if needed. >In short, there is no support for IPA-IPA trust or replication. There >are many reasons for that, including some complex technical issues on >how this could be reliably working. >If you are after actual POSIX systems where users need to logon to use >their services, you may try to configure SSSD with two different domains >(for IPA1 and IPA2). You can look at discussion we had in 2014: >https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html >You are not necessarily need to enroll the machine in two different >realms, any Kerberos principal would do instead of a host principal to >authenticate against IPA LDAP (see sssd-ldap man page for details on >ldap_sasl_authid). Thanks, so the idea here would be for SSSD (and any other software which uses krb or LDAP) to be configured to use both our IPA instances simultaneously. I'll ponder on this and check into if each of our applications has support for multiple LDAP servers. >>We believe we need one way sync (including passwords) to be able to >>authenticate users which are mastered in the 'remote' IPA, even when >>the 'remote' IPA is offline. Another option we might explore is >>'cross-forest trust', although I believe this would make >>authentication unavailable if the 'master' IPA is unavailable. Both >>are discussed at >>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect >>, but again in the context of AD/IPA rather than IPA/IPA. >>I'd welcome any pointers on trust or one-way replication between two >>IPA instances! >You are stuck, there is no such support between different IPA >deployments. >It would help to actually explain your real use case. So far you >outlined above your approaches to solve a problem which is not really >stated upfront. Thanks - I'll try to explain the wider picture: We have a Hadoop deployment which uses an instance of FreeIPA both for the Operating Systems (using SSSD) and applications which use LDAP (for authentication, authorisation and for directory search.) This FreeIPA (Project IPA) is intended to be authoritative for user accounts which are specific to the project, such as administrators, contractors, and so on. The project fits into a wider estate, which uses FreeIPA (call this Enterprise IPA) to manage general user accounts. For auditing and consistency purposes, the general users managed in Enterprise IPA should be able to run POSIX processes under their username (in this case YARN containers), log into project tools (which use LDAP to Project IPA - although this could be changed to SAML/Shibboleth which might avoid Project IPA having to validate credentials) and so on. +----------------------------------------------------------+ | | | +----------------------------------------------------+ | | | | | | | +-------+ +---------+ +--------+ +----------+ | | | | | IPA | |Linux OS | |Linux OS| | App using| | | | | | | | | | | | LDAP | | | | | +-------+ +---------+ +--------+ +----------+ | | | | | | | | ^ | | | |Project +-------------------------------------------- | +----------------------------------------------------+ | user1 can own | | processes here | | | | | | | | | +--------+ +---------+ +---------+ +------------+ | | | | | | | | | | | | | IPA | | Linux | | Linux | | App using | | | | | | OS | | OS | | LDAP | | | +--------+ +---------+ +---------+ +------------+ | | | | ^ | | | | | Wider Enterprise Estate | +--------|-------------------------------------------------+ | | user1 details mastered here If 'Enterprise' IPA was instead Active Directory, I believe the above could be achieved with a One way Trust? We have an additional aim to be able to set authorisation rules in the Project IPA (e.g., putting the Enterprise IPA users into groups where the groups are managed in Project IPA.) Thanks, Nick From abokovoy at redhat.com Thu Feb 9 14:20:02 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Feb 2017 16:20:02 +0200 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA In-Reply-To: References: <20170209112848.i6pad2ye5jo6jbx6@redhat.com> Message-ID: <20170209142002.jr2qgct7qiqaiaco@redhat.com> On to, 09 helmi 2017, Piper, Nick wrote: >Hi Alexander, > >Alexander Bokovoy wrote: >>On to, 09 helmi 2017, Piper, Nick wrote: > >>>We're currently using FreeIPA 4.2.0, and we have two unrelated >>>instances of IdM server. We'd like the user list which IPA maintains >>>in one, to be a superset of the other; so we're looking for one way >>>replication (of cn=users,cn=accounts,dc=realm, not necessarily of host >>>entries etc.) > >>>We use a different 'dc' in each instance, and could use a different cn >>>too if needed. > >>In short, there is no support for IPA-IPA trust or replication. There >>are many reasons for that, including some complex technical issues on >>how this could be reliably working. > >>If you are after actual POSIX systems where users need to logon to use >>their services, you may try to configure SSSD with two different domains >>(for IPA1 and IPA2). You can look at discussion we had in 2014: >>https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html >>You are not necessarily need to enroll the machine in two different >>realms, any Kerberos principal would do instead of a host principal to >>authenticate against IPA LDAP (see sssd-ldap man page for details on >>ldap_sasl_authid). > >Thanks, so the idea here would be for SSSD (and any other software >which uses krb or LDAP) to be configured to use both our IPA instances >simultaneously. I'll ponder on this and check into if each of our >applications has support for multiple LDAP servers. > >>>We believe we need one way sync (including passwords) to be able to >>>authenticate users which are mastered in the 'remote' IPA, even when >>>the 'remote' IPA is offline. Another option we might explore is >>>'cross-forest trust', although I believe this would make >>>authentication unavailable if the 'master' IPA is unavailable. Both >>>are discussed at >>>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect >>>, but again in the context of AD/IPA rather than IPA/IPA. > >>>I'd welcome any pointers on trust or one-way replication between two >>>IPA instances! > >>You are stuck, there is no such support between different IPA >>deployments. > >>It would help to actually explain your real use case. So far you >>outlined above your approaches to solve a problem which is not really >>stated upfront. > >Thanks - I'll try to explain the wider picture: > >We have a Hadoop deployment which uses an instance of FreeIPA both for >the Operating Systems (using SSSD) and applications which use LDAP >(for authentication, authorisation and for directory search.) This >FreeIPA (Project IPA) is intended to be authoritative for user >accounts which are specific to the project, such as administrators, >contractors, and so on. The project fits into a wider estate, which >uses FreeIPA (call this Enterprise IPA) to manage general user >accounts. > >For auditing and consistency purposes, the general users managed in >Enterprise IPA should be able to run POSIX processes under their >username (in this case YARN containers), log into project tools (which >use LDAP to Project IPA - although this could be changed to >SAML/Shibboleth which might avoid Project IPA having to validate >credentials) and so on. > > >+----------------------------------------------------------+ >| | >| +----------------------------------------------------+ | >| | | | >| | +-------+ +---------+ +--------+ +----------+ | | >| | | IPA | |Linux OS | |Linux OS| | App using| | | >| | | | | | | | | LDAP | | | >| | +-------+ +---------+ +--------+ +----------+ | | >| | | | >| | ^ | | >| |Project +-------------------------------------------- >| +----------------------------------------------------+ | user1 can own >| | processes here >| | >| | >| | >| | >| +--------+ +---------+ +---------+ +------------+ | >| | | | | | | | | | >| | IPA | | Linux | | Linux | | App using | | >| | | | OS | | OS | | LDAP | | >| +--------+ +---------+ +---------+ +------------+ | >| | >| ^ | >| | | >| Wider Enterprise Estate | >+--------|-------------------------------------------------+ > | > | > user1 details mastered here > > >If 'Enterprise' IPA was instead Active Directory, I believe the above >could be achieved with a One way Trust? Yes, that's what would be supported now by FreeIPA. >We have an additional aim to be able to set authorisation rules in the >Project IPA (e.g., putting the Enterprise IPA users into groups where >the groups are managed in Project IPA.) Understood. Unfortunately, we are still far away from making IPA-IPA trust a reality. We need to implement several features until we get to the point that practical IPA-IPA trust is possible. -- / Alexander Bokovoy From guillermo.fuentes at modernizingmedicine.com Thu Feb 9 14:29:14 2017 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Thu, 9 Feb 2017 09:29:14 -0500 Subject: [Freeipa-users] CA not found? Message-ID: Hi list, I'm trying to sign a service certificate but it's failing with "CA not found". The CA does exist but for some reason the ipa cert-request can't find it: $ ipa ca-show ipa Name: ipa Description: IPA CA Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c Subject DN: CN=Certificate Authority,O=EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM This was working in previous versions of freeipa but in our current environment isn't working: Cluster of four FreeIPA servers CentOS Linux release 7.3.1611 (Core) ipa-client-common-4.4.0-14.el7.centos.4.noarch ipa-client-4.4.0-14.el7.centos.4.x86_64 ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64 ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64 ipa-server-4.4.0-14.el7.centos.4.x86_64 ipa-admintools-4.4.0-14.el7.centos.4.noarch ipa-server-common-4.4.0-14.el7.centos.4.noarch ipa-common-4.4.0-14.el7.centos.4.noarch ipa-server-dns-4.4.0-14.el7.centos.4.noarch ipa-python-compat-4.4.0-14.el7.centos.4.noarch 389-ds-base-1.3.5.10-15.el7_3.x86_64 389-ds-base-libs-1.3.5.10-15.el7_3.x86_64 389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64 pki-base-java-10.3.3-16.el7_3.noarch pki-base-10.3.3-16.el7_3.noarch pki-server-10.3.3-16.el7_3.noarch pki-ca-10.3.3-16.el7_3.noarch pki-symkey-10.3.3-16.el7_3.x86_64 pki-kra-10.3.3-16.el7_3.noarch pki-tools-10.3.3-16.el7_3.x86_64 krb5-libs-1.14.1-27.el7_3.x86_64 python-krbV-1.0.90-8.el7.x86_64 pam_krb5-2.4.8-6.el7.x86_64 krb5-workstation-1.14.1-27.el7_3.x86_64 krb5-pkinit-1.14.1-27.el7_3.x86_64 sssd-krb5-common-1.14.0-43.el7_3.11.x86_64 krb5-server-1.14.1-27.el7_3.x86_64 sssd-krb5-1.14.0-43.el7_3.11.x86_64 *********** This is the error (same result in all four servers): $ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c) *********** >From /var/log/pki/pki-tomcat/ca/debug: [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet::service() param name='xml' value='true' [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet::service() param name='profileId' value='caIPAserviceCert' [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet::service() param name='authorityId' value='0cb513ea-6084-4144-a61c-7a0a8368d25c' [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet::service() param name='cert_request' value='(sensitive)' [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet::service() param name='cert_request_type' value='pkcs10' [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: caProfileSubmitSSLClient start to service. [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: ProfileSubmitServlet: isRenewal false [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: ProfileSubmitServlet: profile: caIPAserviceCert CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c at com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: ProfileSubmitServlet: error in processing request: CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: curDate=Tue Feb 07 23:45:49 EST 2017 id=caProfileSubmitSSLClient time=8 *************** Any idea why this is happening? It's using the caIPAserviceCert certificate profile which should be fine. I also checked and "played" with the hosts_services_caIPAserviceCert CA ACL with the same results. Thanks in advance! Guillermo From nick.piper at cgi.com Thu Feb 9 15:03:43 2017 From: nick.piper at cgi.com (Piper, Nick) Date: Thu, 9 Feb 2017 15:03:43 +0000 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA In-Reply-To: <20170209142002.jr2qgct7qiqaiaco@redhat.com> References: <20170209112848.i6pad2ye5jo6jbx6@redhat.com> , <20170209142002.jr2qgct7qiqaiaco@redhat.com> Message-ID: Alexander Bokovoy wrote: >Unfortunately, we are still far away from making IPA-IPA trust a >reality. We need to implement several features until we get to the point >that practical IPA-IPA trust is possible. Ok, thank you for clarifying - we'll consider how to work around - potentially replacing one of the IPA instances with AD for now. Regards, Nick From ftweedal at redhat.com Thu Feb 9 22:06:22 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 10 Feb 2017 08:06:22 +1000 Subject: [Freeipa-users] CA not found? In-Reply-To: References: Message-ID: <20170209220622.GE3557@dhcp-40-8.bne.redhat.com> On Thu, Feb 09, 2017 at 09:29:14AM -0500, Guillermo Fuentes wrote: > Hi list, > > I'm trying to sign a service certificate but it's failing with "CA not found". > The CA does exist but for some reason the ipa cert-request can't find it: > $ ipa ca-show ipa > Name: ipa > Description: IPA CA > Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c > Subject DN: CN=Certificate Authority,O=EXAMPLE.COM > Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM > > This was working in previous versions of freeipa but in our current > environment isn't working: > Cluster of four FreeIPA servers > CentOS Linux release 7.3.1611 (Core) > ipa-client-common-4.4.0-14.el7.centos.4.noarch > ipa-client-4.4.0-14.el7.centos.4.x86_64 > ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64 > ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64 > ipa-server-4.4.0-14.el7.centos.4.x86_64 > ipa-admintools-4.4.0-14.el7.centos.4.noarch > ipa-server-common-4.4.0-14.el7.centos.4.noarch > ipa-common-4.4.0-14.el7.centos.4.noarch > ipa-server-dns-4.4.0-14.el7.centos.4.noarch > ipa-python-compat-4.4.0-14.el7.centos.4.noarch > 389-ds-base-1.3.5.10-15.el7_3.x86_64 > 389-ds-base-libs-1.3.5.10-15.el7_3.x86_64 > 389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64 > 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64 > pki-base-java-10.3.3-16.el7_3.noarch > pki-base-10.3.3-16.el7_3.noarch > pki-server-10.3.3-16.el7_3.noarch > pki-ca-10.3.3-16.el7_3.noarch > pki-symkey-10.3.3-16.el7_3.x86_64 > pki-kra-10.3.3-16.el7_3.noarch > pki-tools-10.3.3-16.el7_3.x86_64 > krb5-libs-1.14.1-27.el7_3.x86_64 > python-krbV-1.0.90-8.el7.x86_64 > pam_krb5-2.4.8-6.el7.x86_64 > krb5-workstation-1.14.1-27.el7_3.x86_64 > krb5-pkinit-1.14.1-27.el7_3.x86_64 > sssd-krb5-common-1.14.0-43.el7_3.11.x86_64 > krb5-server-1.14.1-27.el7_3.x86_64 > sssd-krb5-1.14.0-43.el7_3.11.x86_64 > > *********** > This is the error (same result in all four servers): > $ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr > ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not > found: 0cb513ea-6084-4144-a61c-7a0a8368d25c) > > *********** > >From /var/log/pki/pki-tomcat/ca/debug: > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > CMSServlet::service() param name='xml' value='true' > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > CMSServlet::service() param name='profileId' value='caIPAserviceCert' > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > CMSServlet::service() param name='authorityId' > value='0cb513ea-6084-4144-a61c-7a0a8368d25c' > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > CMSServlet::service() param name='cert_request' value='(sensitive)' > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > CMSServlet::service() param name='cert_request_type' value='pkcs10' > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: > caProfileSubmitSSLClient start to service. > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > ProfileSubmitServlet: isRenewal false > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to > ccMode, authorization for servlet: caProfileSubmit is LDAP based, not > XML {1}, use default authz mgr: {2}. > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > ProfileSubmitServlet: profile: caIPAserviceCert > CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c > at com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239) > at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128) > at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) > at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) > at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) > at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297) > at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) > at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) > at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) > at java.security.AccessController.doPrivileged(Native Method) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) > at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) > at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) > at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) > at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) > at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) > at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) > at java.security.AccessController.doPrivileged(Native Method) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436) > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:745) > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > ProfileSubmitServlet: error in processing request: CA not found: > 0cb513ea-6084-4144-a61c-7a0a8368d25c > [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: > curDate=Tue Feb 07 23:45:49 EST 2017 id=caProfileSubmitSSLClient > time=8 > *************** > > Any idea why this is happening? > It's using the caIPAserviceCert certificate profile which should be > fine. I also checked and "played" with the > hosts_services_caIPAserviceCert CA ACL with the same results. > > Thanks in advance! > > Guillermo > Was the server upgraded/migrated from an older release, or a new installation? Could you please `ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca' and provide output? Thanks, Fraser From fedora at josemaas.net Thu Feb 9 22:10:21 2017 From: fedora at josemaas.net (Joseph Vandermaas) Date: Thu, 09 Feb 2017 17:10:21 -0500 Subject: [Freeipa-users] pki-tomcat will not start after certificate renewal Message-ID: <589ce8cd.JHznaGVVLmX1uW8t%fedora@josemaas.net> All I have been experiencing some issues with a FreeIPA instance that I maintain. More specifically pki-tomcat has not started since around the time it?s certificate renewed. I submitted this bug report https://fedorahosted.org/freeipa/ticket/6521, however a solution has yet to be found. This installation does have one instresting issue that I believe may be causing it to fail. There are two certificates under cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid CA certificates and when I run openssl verify with ether of them as the CA and the new subsystem certificate I get an OK message. I also believe that this issue is causing me not to be able to do a ipa-certupdate on the broken IPA server. Is there a way to to clean this up, should I try renewing the CA certificate and get rid of the old LDAP entries? From ian.munoz at cgrb.oregonstate.edu Thu Feb 9 22:27:28 2017 From: ian.munoz at cgrb.oregonstate.edu (Munoz, Ian A) Date: Thu, 9 Feb 2017 22:27:28 +0000 Subject: [Freeipa-users] Cross domain or pass through authentication v4.4 Message-ID: Hello, I can't seem to set up or find decent documentation on either cross-domain or pass through authentication. I have tried kerberos cross realm, and saslauthd. I have two different scenarios I would like to potentially accomplish. 1. FreeIPA domain of a.example.tld pass through authentication to FreeIPA domain b.example.tld 2. FreeIPA a.example.tld needs to pass through authentication to our enterprise ldap What is the correct documentation to be following? Should I be trying to achieve this via an openldap pass through or a kerberos cross realm trust? Any thoughts or wisdom would be appreciated. Thanks, -Ian Mu?oz Computational Scientist Oregon State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 9 22:31:55 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 9 Feb 2017 17:31:55 -0500 Subject: [Freeipa-users] pki-tomcat will not start after certificate renewal In-Reply-To: <589ce8cd.JHznaGVVLmX1uW8t%fedora@josemaas.net> References: <589ce8cd.JHznaGVVLmX1uW8t%fedora@josemaas.net> Message-ID: Joseph Vandermaas wrote: > All > I have been experiencing some issues with a FreeIPA instance that I maintain. More specifically pki-tomcat has not started since around the time it?s certificate renewed. I submitted this bug report https://fedorahosted.org/freeipa/ticket/6521, however a solution has yet to be found. > This installation does have one instresting issue that I believe may be causing it to fail. There are two certificates under cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid CA certificates and when I run openssl verify with ether of them as the CA and the new subsystem certificate I get an OK message. I also believe that this issue is causing me not to be able to do a ipa-certupdate on the broken IPA server. Is there a way to to clean this up, should I try renewing the CA certificate and get rid of the old LDAP entries? > What did you do, as exactly as you can remember, to get the certificates renewed? rob From guillermo.fuentes at modernizingmedicine.com Thu Feb 9 23:27:12 2017 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Thu, 9 Feb 2017 18:27:12 -0500 Subject: [Freeipa-users] CA not found? In-Reply-To: <20170209220622.GE3557@dhcp-40-8.bne.redhat.com> References: <20170209220622.GE3557@dhcp-40-8.bne.redhat.com> Message-ID: Hi Fraser, The cluster was migrated from FreeIPA 3 (CentOS 6) to FreeIPA 4 (CentOS 7) a year ago. - Output of 'ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca': SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: - Output providing GSSAPI mechanism: $ ldapsearch -Y GSSAPI -s sub -b ou=authorities,ou=ca,o=ipaca SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/localhost at EXAMPLE.COM not found in Kerberos database) - Output providing user credentials: $ ldapsearch -D "uid=user1,cn=users,cn=accounts,dc=example,dc=com" -W -H ldaps://`hostname` -s sub -b ou=authorities,ou=ca,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Thanks for your help! Guillermo On Thu, Feb 9, 2017 at 5:06 PM, Fraser Tweedale wrote: > On Thu, Feb 09, 2017 at 09:29:14AM -0500, Guillermo Fuentes wrote: >> Hi list, >> >> I'm trying to sign a service certificate but it's failing with "CA not found". >> The CA does exist but for some reason the ipa cert-request can't find it: >> $ ipa ca-show ipa >> Name: ipa >> Description: IPA CA >> Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c >> Subject DN: CN=Certificate Authority,O=EXAMPLE.COM >> Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM >> >> This was working in previous versions of freeipa but in our current >> environment isn't working: >> Cluster of four FreeIPA servers >> CentOS Linux release 7.3.1611 (Core) >> ipa-client-common-4.4.0-14.el7.centos.4.noarch >> ipa-client-4.4.0-14.el7.centos.4.x86_64 >> ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64 >> ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64 >> ipa-server-4.4.0-14.el7.centos.4.x86_64 >> ipa-admintools-4.4.0-14.el7.centos.4.noarch >> ipa-server-common-4.4.0-14.el7.centos.4.noarch >> ipa-common-4.4.0-14.el7.centos.4.noarch >> ipa-server-dns-4.4.0-14.el7.centos.4.noarch >> ipa-python-compat-4.4.0-14.el7.centos.4.noarch >> 389-ds-base-1.3.5.10-15.el7_3.x86_64 >> 389-ds-base-libs-1.3.5.10-15.el7_3.x86_64 >> 389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64 >> 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64 >> pki-base-java-10.3.3-16.el7_3.noarch >> pki-base-10.3.3-16.el7_3.noarch >> pki-server-10.3.3-16.el7_3.noarch >> pki-ca-10.3.3-16.el7_3.noarch >> pki-symkey-10.3.3-16.el7_3.x86_64 >> pki-kra-10.3.3-16.el7_3.noarch >> pki-tools-10.3.3-16.el7_3.x86_64 >> krb5-libs-1.14.1-27.el7_3.x86_64 >> python-krbV-1.0.90-8.el7.x86_64 >> pam_krb5-2.4.8-6.el7.x86_64 >> krb5-workstation-1.14.1-27.el7_3.x86_64 >> krb5-pkinit-1.14.1-27.el7_3.x86_64 >> sssd-krb5-common-1.14.0-43.el7_3.11.x86_64 >> krb5-server-1.14.1-27.el7_3.x86_64 >> sssd-krb5-1.14.0-43.el7_3.11.x86_64 >> >> *********** >> This is the error (same result in all four servers): >> $ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr >> ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not >> found: 0cb513ea-6084-4144-a61c-7a0a8368d25c) >> >> *********** >> >From /var/log/pki/pki-tomcat/ca/debug: >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> CMSServlet::service() param name='xml' value='true' >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> CMSServlet::service() param name='profileId' value='caIPAserviceCert' >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> CMSServlet::service() param name='authorityId' >> value='0cb513ea-6084-4144-a61c-7a0a8368d25c' >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> CMSServlet::service() param name='cert_request' value='(sensitive)' >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> CMSServlet::service() param name='cert_request_type' value='pkcs10' >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: >> caProfileSubmitSSLClient start to service. >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> ProfileSubmitServlet: isRenewal false >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to >> ccMode, authorization for servlet: caProfileSubmit is LDAP based, not >> XML {1}, use default authz mgr: {2}. >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> ProfileSubmitServlet: profile: caIPAserviceCert >> CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c >> at com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239) >> at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128) >> at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) >> at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) >> at java.security.AccessController.doPrivileged(Native Method) >> at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) >> at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) >> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) >> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297) >> at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) >> at java.security.AccessController.doPrivileged(Native Method) >> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) >> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) >> at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) >> at java.security.AccessController.doPrivileged(Native Method) >> at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) >> at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) >> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260) >> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) >> at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) >> at java.security.AccessController.doPrivileged(Native Method) >> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) >> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) >> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) >> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) >> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) >> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) >> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956) >> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) >> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436) >> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) >> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625) >> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) >> at java.lang.Thread.run(Thread.java:745) >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: >> ProfileSubmitServlet: error in processing request: CA not found: >> 0cb513ea-6084-4144-a61c-7a0a8368d25c >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: >> curDate=Tue Feb 07 23:45:49 EST 2017 id=caProfileSubmitSSLClient >> time=8 >> *************** >> >> Any idea why this is happening? >> It's using the caIPAserviceCert certificate profile which should be >> fine. I also checked and "played" with the >> hosts_services_caIPAserviceCert CA ACL with the same results. >> >> Thanks in advance! >> >> Guillermo >> > Was the server upgraded/migrated from an older release, or a new > installation? > > Could you please `ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca' > and provide output? > > Thanks, > Fraser -- GUILLERMO FUENTES SENIOR SYSTEMS ADMINISTRATOR T: 561-880-2998 x1337 E: ?guillermo.fuentes at modmed.com From ftweedal at redhat.com Thu Feb 9 23:52:14 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 10 Feb 2017 09:52:14 +1000 Subject: [Freeipa-users] CA not found? In-Reply-To: References: <20170209220622.GE3557@dhcp-40-8.bne.redhat.com> Message-ID: <20170209235214.GF3557@dhcp-40-8.bne.redhat.com> On Thu, Feb 09, 2017 at 06:27:12PM -0500, Guillermo Fuentes wrote: > Hi Fraser, > > The cluster was migrated from FreeIPA 3 (CentOS 6) to FreeIPA 4 > (CentOS 7) a year ago. > > - Output of 'ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca': > SASL/EXTERNAL authentication started > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: > > - Output providing GSSAPI mechanism: > $ ldapsearch -Y GSSAPI -s sub -b ou=authorities,ou=ca,o=ipaca > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (Server > ldap/localhost at EXAMPLE.COM not found in Kerberos database) > > - Output providing user credentials: > $ ldapsearch -D "uid=user1,cn=users,cn=accounts,dc=example,dc=com" -W > -H ldaps://`hostname` -s sub -b ou=authorities,ou=ca,o=ipaca > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > > Thanks for your help! > Guillermo > What happens when you run the ldapsearch as Directory Manager, i.e.: ldapsearch -D "cn=Directory Manager" -w \ -s sub -b ou=authorities,ou=ca,o=ipaca Could you run `ipa-server-upgrade` and send log file /var/log/ipaupgrade.log ? Could you please restart the server and attach the resulting portion of log file /var/log/pki/pki-tomcat/ca/debug ? Thanks, Fraser > On Thu, Feb 9, 2017 at 5:06 PM, Fraser Tweedale wrote: > > On Thu, Feb 09, 2017 at 09:29:14AM -0500, Guillermo Fuentes wrote: > >> Hi list, > >> > >> I'm trying to sign a service certificate but it's failing with "CA not found". > >> The CA does exist but for some reason the ipa cert-request can't find it: > >> $ ipa ca-show ipa > >> Name: ipa > >> Description: IPA CA > >> Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c > >> Subject DN: CN=Certificate Authority,O=EXAMPLE.COM > >> Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM > >> > >> This was working in previous versions of freeipa but in our current > >> environment isn't working: > >> Cluster of four FreeIPA servers > >> CentOS Linux release 7.3.1611 (Core) > >> ipa-client-common-4.4.0-14.el7.centos.4.noarch > >> ipa-client-4.4.0-14.el7.centos.4.x86_64 > >> ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64 > >> ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64 > >> ipa-server-4.4.0-14.el7.centos.4.x86_64 > >> ipa-admintools-4.4.0-14.el7.centos.4.noarch > >> ipa-server-common-4.4.0-14.el7.centos.4.noarch > >> ipa-common-4.4.0-14.el7.centos.4.noarch > >> ipa-server-dns-4.4.0-14.el7.centos.4.noarch > >> ipa-python-compat-4.4.0-14.el7.centos.4.noarch > >> 389-ds-base-1.3.5.10-15.el7_3.x86_64 > >> 389-ds-base-libs-1.3.5.10-15.el7_3.x86_64 > >> 389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64 > >> 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64 > >> pki-base-java-10.3.3-16.el7_3.noarch > >> pki-base-10.3.3-16.el7_3.noarch > >> pki-server-10.3.3-16.el7_3.noarch > >> pki-ca-10.3.3-16.el7_3.noarch > >> pki-symkey-10.3.3-16.el7_3.x86_64 > >> pki-kra-10.3.3-16.el7_3.noarch > >> pki-tools-10.3.3-16.el7_3.x86_64 > >> krb5-libs-1.14.1-27.el7_3.x86_64 > >> python-krbV-1.0.90-8.el7.x86_64 > >> pam_krb5-2.4.8-6.el7.x86_64 > >> krb5-workstation-1.14.1-27.el7_3.x86_64 > >> krb5-pkinit-1.14.1-27.el7_3.x86_64 > >> sssd-krb5-common-1.14.0-43.el7_3.11.x86_64 > >> krb5-server-1.14.1-27.el7_3.x86_64 > >> sssd-krb5-1.14.0-43.el7_3.11.x86_64 > >> > >> *********** > >> This is the error (same result in all four servers): > >> $ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr > >> ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not > >> found: 0cb513ea-6084-4144-a61c-7a0a8368d25c) > >> > >> *********** > >> >From /var/log/pki/pki-tomcat/ca/debug: > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> CMSServlet::service() param name='xml' value='true' > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> CMSServlet::service() param name='profileId' value='caIPAserviceCert' > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> CMSServlet::service() param name='authorityId' > >> value='0cb513ea-6084-4144-a61c-7a0a8368d25c' > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> CMSServlet::service() param name='cert_request' value='(sensitive)' > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> CMSServlet::service() param name='cert_request_type' value='pkcs10' > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: > >> caProfileSubmitSSLClient start to service. > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> ProfileSubmitServlet: isRenewal false > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to > >> ccMode, authorization for servlet: caProfileSubmit is LDAP based, not > >> XML {1}, use default authz mgr: {2}. > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> ProfileSubmitServlet: profile: caIPAserviceCert > >> CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c > >> at com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239) > >> at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128) > >> at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515) > >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) > >> at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:498) > >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) > >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > >> at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) > >> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) > >> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297) > >> at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) > >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) > >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) > >> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > >> at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:498) > >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) > >> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > >> at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) > >> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260) > >> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) > >> at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) > >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) > >> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) > >> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > >> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > >> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) > >> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) > >> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) > >> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956) > >> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > >> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436) > >> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) > >> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625) > >> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) > >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > >> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > >> at java.lang.Thread.run(Thread.java:745) > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: > >> ProfileSubmitServlet: error in processing request: CA not found: > >> 0cb513ea-6084-4144-a61c-7a0a8368d25c > >> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet: > >> curDate=Tue Feb 07 23:45:49 EST 2017 id=caProfileSubmitSSLClient > >> time=8 > >> *************** > >> > >> Any idea why this is happening? > >> It's using the caIPAserviceCert certificate profile which should be > >> fine. I also checked and "played" with the > >> hosts_services_caIPAserviceCert CA ACL with the same results. > >> > >> Thanks in advance! > >> > >> Guillermo > >> > > Was the server upgraded/migrated from an older release, or a new > > installation? > > > > Could you please `ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca' > > and provide output? > > > > Thanks, > > Fraser > > > > -- > GUILLERMO FUENTES > SENIOR SYSTEMS ADMINISTRATOR > > T: 561-880-2998 x1337 > > E: ?guillermo.fuentes at modmed.com From guillermo.fuentes at modernizingmedicine.com Fri Feb 10 02:01:01 2017 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Thu, 9 Feb 2017 21:01:01 -0500 Subject: [Freeipa-users] CA not found? In-Reply-To: <20170209235214.GF3557@dhcp-40-8.bne.redhat.com> References: <20170209220622.GE3557@dhcp-40-8.bne.redhat.com> <20170209235214.GF3557@dhcp-40-8.bne.redhat.com> Message-ID: As we're enforcing encryption, here is via ldaps: $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager" -W -s sub -b ou=authorities,ou=ca,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # authorities, ca, ipaca dn: ou=authorities,ou=ca,o=ipaca objectClass: top objectClass: organizationalUnit ou: authorities # 0af769bd-a7ed-4f3a-8859-a877724ea8f2, authorities, ca, ipaca dn: cn=0af769bd-a7ed-4f3a-8859-a877724ea8f2,ou=authorities,ou=ca,o=ipaca objectClass: authority objectClass: top cn: 0af769bd-a7ed-4f3a-8859-a877724ea8f2 authorityID: 0af769bd-a7ed-4f3a-8859-a877724ea8f2 authorityKeyNickname: caSigningCert cert-pki-ca authorityEnabled: TRUE authorityDN: CN=Certificate Authority,O=EXAMPLE.COM description: Host authority # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 I'll attach the log files soon. From abokovoy at redhat.com Fri Feb 10 06:13:42 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Feb 2017 08:13:42 +0200 Subject: [Freeipa-users] Cross domain or pass through authentication v4.4 In-Reply-To: References: Message-ID: <20170210061342.6zlo2a2kfq7zceef@redhat.com> On to, 09 helmi 2017, Munoz, Ian A wrote: >Hello, > >I can't seem to set up or find decent documentation on either >cross-domain or pass through authentication. I have tried kerberos >cross realm, and saslauthd. > >I have two different scenarios I would like to potentially accomplish. > >1. FreeIPA domain of a.example.tld pass through authentication to FreeIPA domain b.example.tld There is no support for IPA-IPA trust currently. >2. FreeIPA a.example.tld needs to pass through authentication to our >enterprise ldap There is no support for this either. > >What is the correct documentation to be following? Should I be trying >to achieve this via an openldap pass through or a kerberos cross realm >trust? The only supported configuration for authenticating externally defined users is when they are part of Active Directory domain. In such case establishing forest trust to Active Directory is the right thing to do. Please note that it is not just a Kerberos cross realm trust, so don't try that option on Active Directory side, it will not work against FreeIPA. -- / Alexander Bokovoy From mbasti at redhat.com Fri Feb 10 06:51:21 2017 From: mbasti at redhat.com (Martin Basti) Date: Fri, 10 Feb 2017 01:51:21 -0500 (EST) Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records In-Reply-To: References: Message-ID: <461679326.20722033.1486709481115.JavaMail.zimbra@redhat.com> Hello, I'm not sure how your DNS data are structured, but usually (properly) DS record is located in parent zone, so AXFR for subdomain.exmale.com should not return DS record, but AXFR for example.com should return DS record of subdomain.example.com. Martin ----- Original Message ----- From: "Ben Roberts" To: "Tomas Krizek" Cc: freeipa-users at redhat.com Sent: Thursday, February 9, 2017 10:53:38 AM Subject: Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records Hi Tomas, > when I add a DS record to LDAP (without any DNSSEC configuration), > it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1. > > I suppose you have DNSSEC configured. Could you be affected by the > limitations mentioned in [1]? Yes, dnssec is otherwise fully configured (the only bit I don't yet have is the DS records for the "example.local" parent domain registered upstream, but that shouldn't have any impact here. I don't think the linked limitations apply, I'm not attempting to use the CDS or CDNSKEY record types, and am manually specifying the DS records for the child zone. This is with bind 9.11 and bind-dyndb-ldap 11.0. Regards, Ben Roberts -- 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 me at benroberts.net Fri Feb 10 07:42:08 2017 From: me at benroberts.net (Ben Roberts) Date: Fri, 10 Feb 2017 07:42:08 +0000 Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records In-Reply-To: <461679326.20722033.1486709481115.JavaMail.zimbra@redhat.com> References: <461679326.20722033.1486709481115.JavaMail.zimbra@redhat.com> Message-ID: Hi Martin, > I'm not sure how your DNS data are structured, but usually (properly) > DS record is located in parent zone, so AXFR for > subdomain.exmale.com should not return DS record, but AXFR > for example.com should return DS record of > subdomain.example.com. Herein lies the problem. The nameservers are authoritative for both the parent and child zones, and both are replicated from the primaries to the secondary nameserver. The DS glue records for the child zone contained within the parent zone are not being replicated across to the secondary via AXFR. Thus there is a complete chain for DNSSEC trust when queries are directed at the primaries, but not when queries are directed at the secondary nameserver. This affects both the DS glue records, and also the apex DS records which don't need to be present, but which bind-dyndb-ldap makes available automatically anyway. I raise this not because it's needed, but it might be relevant to identifying where the root cause is. Regards, Ben Roberts From dkupka at redhat.com Fri Feb 10 08:34:24 2017 From: dkupka at redhat.com (David Kupka) Date: Fri, 10 Feb 2017 09:34:24 +0100 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA In-Reply-To: References: <20170209112848.i6pad2ye5jo6jbx6@redhat.com> Message-ID: <20170210083423.GA3637@dkupka.usersys.redhat.com> On Thu, Feb 09, 2017 at 01:45:42PM +0000, Piper, Nick wrote: > Hi Alexander, > > Alexander Bokovoy wrote: > >On to, 09 helmi 2017, Piper, Nick wrote: > > >>We're currently using FreeIPA 4.2.0, and we have two unrelated > >>instances of IdM server. We'd like the user list which IPA maintains > >>in one, to be a superset of the other; so we're looking for one way > >>replication (of cn=users,cn=accounts,dc=realm, not necessarily of host > >>entries etc.) > > >>We use a different 'dc' in each instance, and could use a different cn > >>too if needed. > > >In short, there is no support for IPA-IPA trust or replication. There > >are many reasons for that, including some complex technical issues on > >how this could be reliably working. > > >If you are after actual POSIX systems where users need to logon to use > >their services, you may try to configure SSSD with two different domains > >(for IPA1 and IPA2). You can look at discussion we had in 2014: > >https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html > >You are not necessarily need to enroll the machine in two different > >realms, any Kerberos principal would do instead of a host principal to > >authenticate against IPA LDAP (see sssd-ldap man page for details on > >ldap_sasl_authid). > > Thanks, so the idea here would be for SSSD (and any other software > which uses krb or LDAP) to be configured to use both our IPA instances > simultaneously. I'll ponder on this and check into if each of our > applications has support for multiple LDAP servers. > > >>We believe we need one way sync (including passwords) to be able to > >>authenticate users which are mastered in the 'remote' IPA, even when > >>the 'remote' IPA is offline. Another option we might explore is > >>'cross-forest trust', although I believe this would make > >>authentication unavailable if the 'master' IPA is unavailable. Both > >>are discussed at > >>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect > >>, but again in the context of AD/IPA rather than IPA/IPA. > > >>I'd welcome any pointers on trust or one-way replication between two > >>IPA instances! > > >You are stuck, there is no such support between different IPA > >deployments. > > >It would help to actually explain your real use case. So far you > >outlined above your approaches to solve a problem which is not really > >stated upfront. > > Thanks - I'll try to explain the wider picture: > > We have a Hadoop deployment which uses an instance of FreeIPA both for > the Operating Systems (using SSSD) and applications which use LDAP > (for authentication, authorisation and for directory search.) This > FreeIPA (Project IPA) is intended to be authoritative for user > accounts which are specific to the project, such as administrators, > contractors, and so on. The project fits into a wider estate, which > uses FreeIPA (call this Enterprise IPA) to manage general user > accounts. > > For auditing and consistency purposes, the general users managed in > Enterprise IPA should be able to run POSIX processes under their > username (in this case YARN containers), log into project tools (which > use LDAP to Project IPA - although this could be changed to > SAML/Shibboleth which might avoid Project IPA having to validate > credentials) and so on. > > > +----------------------------------------------------------+ > | | > | +----------------------------------------------------+ | > | | | | > | | +-------+ +---------+ +--------+ +----------+ | | > | | | IPA | |Linux OS | |Linux OS| | App using| | | > | | | | | | | | | LDAP | | | > | | +-------+ +---------+ +--------+ +----------+ | | > | | | | > | | ^ | | > | |Project +-------------------------------------------- > | +----------------------------------------------------+ | user1 can own > | | processes here > | | > | | > | | > | | > | +--------+ +---------+ +---------+ +------------+ | > | | | | | | | | | | > | | IPA | | Linux | | Linux | | App using | | > | | | | OS | | OS | | LDAP | | > | +--------+ +---------+ +---------+ +------------+ | > | | > | ^ | > | | | > | Wider Enterprise Estate | > +--------|-------------------------------------------------+ > | > | > user1 details mastered here > > > If 'Enterprise' IPA was instead Active Directory, I believe the above > could be achieved with a One way Trust? > > We have an additional aim to be able to set authorisation rules in the > Project IPA (e.g., putting the Enterprise IPA users into groups where > the groups are managed in Project IPA.) > > Thanks, > > Nick > > -- > 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 Hi Nick, I might be missing something but I would say that the Project IPA is not necessary in the desribed scenario. You can create accounts for all the users involved in Project in Enterprise IPA and assign them to Project group. You can also enroll all Project hosts to Enterprise IPA and add them to Project hostgroup. Then you can use HBAC rules [1] to: * disable the default allow_all rule * allow everyone in Project IPA to acces Project hostgroup * allow all but Project group to access Any host Employees that are also part of other group will be still able to access everything. Contractors will be only in Project group and won't be able to access your Enterprise environment. Of course, unless this is against your company policy... [1] http://www.freeipa.org/page/Howto/HBAC_and_allow_all -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From tkrizek at redhat.com Fri Feb 10 08:58:12 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 10 Feb 2017 09:58:12 +0100 Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records In-Reply-To: References: <461679326.20722033.1486709481115.JavaMail.zimbra@redhat.com> Message-ID: <15f033b8-276d-22ef-d510-c4dc166fc148@redhat.com> On 02/10/2017 08:42 AM, Ben Roberts wrote: > Hi Martin, > >> I'm not sure how your DNS data are structured, but usually (properly) >> DS record is located in parent zone, so AXFR for >> subdomain.exmale.com should not return DS record, but AXFR >> for example.com should return DS record of >> subdomain.example.com. > Herein lies the problem. The nameservers are authoritative for both > the parent and child zones, and both are replicated from the primaries > to the secondary nameserver. The DS glue records for the child zone > contained within the parent zone are not being replicated across to > the secondary via AXFR. Thus there is a complete chain for DNSSEC > trust when queries are directed at the primaries, but not when queries > are directed at the secondary nameserver. > > This affects both the DS glue records, and also the apex DS records > which don't need to be present, but which bind-dyndb-ldap makes > available automatically anyway. I raise this not because it's needed, > but it might be relevant to identifying where the root cause is. > > Regards, > Ben Roberts If I understand you correctly, the primary server is filled with data using bind-dyndb-ldap from an LDAP backend. Then the DS records are present on the primary server. At this point, bind-dyndb-ldap's work should be done, since it only serves as the backend LDAP driver for BIND. The issue happens when you try to replicate the zone to the secondary nameserver using AXFR. This leads me to believe that this might be some issue in the BIND component itself. Perhaps some special configuration is required. It might help you if you'd test the setup without bind-dyndb-ldap with some mock data directly in BIND. If the AXFR doesn't contain the DS records then, it's related to BIND. Perhaps the BIND users (bind-users at lists.isc.org) list might be able to assist you. -- Tomas Krizek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ftweedal at redhat.com Fri Feb 10 10:03:08 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 10 Feb 2017 20:03:08 +1000 Subject: [Freeipa-users] CA not found? In-Reply-To: References: <20170209220622.GE3557@dhcp-40-8.bne.redhat.com> <20170209235214.GF3557@dhcp-40-8.bne.redhat.com> Message-ID: <20170210100308.GJ3557@dhcp-40-8.bne.redhat.com> On Thu, Feb 09, 2017 at 09:01:01PM -0500, Guillermo Fuentes wrote: > As we're enforcing encryption, here is via ldaps: > $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager" -W -s > sub -b ou=authorities,ou=ca,o=ipaca Enter LDAP > Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # authorities, ca, ipaca > dn: ou=authorities,ou=ca,o=ipaca > objectClass: top > objectClass: organizationalUnit > ou: authorities > > # 0af769bd-a7ed-4f3a-8859-a877724ea8f2, authorities, ca, ipaca > dn: cn=0af769bd-a7ed-4f3a-8859-a877724ea8f2,ou=authorities,ou=ca,o=ipaca > objectClass: authority > objectClass: top > cn: 0af769bd-a7ed-4f3a-8859-a877724ea8f2 > authorityID: 0af769bd-a7ed-4f3a-8859-a877724ea8f2 > authorityKeyNickname: caSigningCert cert-pki-ca > authorityEnabled: TRUE > authorityDN: CN=Certificate Authority,O=EXAMPLE.COM > description: Host authority > > # search result > search: 2 > result: 0 Success > > # numResponses: 3 > # numEntries: 2 > > I'll attach the log files soon. > Hi Guillermo, Thanks for the files. At a glance, everything looks normal in ipa upgrade and server startup. There is a discrepancy between the authority record in Dogtag (in the ldapsearch output above) and the corresponding entry in FreeIPA: >> $ ipa ca-show ipa >> Name: ipa >> Description: IPA CA >> Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c >> Subject DN: CN=Certificate Authority,O=EXAMPLE.COM >> Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM If these are indeed different (not a result of substitutions you performed in releasing the data), this is a problem I have not seen before (can you think of anything that might have caused this e.g. deletion of the authority entry from Dogtag?). To resolve, change the 'ipacaid' attribute of cn=ipa,cn=cas,cn=ca,dc=ipa,dc=local to '0af769bd-a7ed-4f3a-8859-a877724ea8f2' HTH, Fraser P.S. I am away next week, so please help Guillermo if he's still having trouble. From peljasz at yahoo.co.uk Fri Feb 10 12:29:37 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Fri, 10 Feb 2017 12:29:37 +0000 Subject: [Freeipa-users] replica install - Insufficient 'add' privilege ? Message-ID: <640b2285-8f1f-7b79-8e2a-b5db0afbb01e@yahoo.co.uk> hi everyone, I'm trying something mundane(can't think why, how my setup would be special/different) - replica installation - but I hit this: [42/44]: activating extdom plugin [43/44]: tuning directory server [44/44]: configuring directory to start on boot Done configuring directory server (dirsrv). Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR Insufficient access: Insufficient 'add' privilege to add the entry 'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'. ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information $and logs tail: 2017-02-10T12:20:46Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-WHALE-PRIVATE.socket conn= 2017-02-10T12:20:47Z DEBUG Destroyed connection context.ldap2_84192272 2017-02-10T12:20:47Z 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/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 310, in run self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 332, in execute for nothing in self._executor(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 586, in _configure next(executor) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1714, in main promote(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 364, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1425, in promote remote_api.env.realm) File "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", line 43, in ntp_ldap_enable ntp.ldap_enable('NTP', fqdn, None, base_dn) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 512, in ldap_enable self.admin_conn.add_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1492, in add_entry self.conn.add_s(str(entry.dn), list(attrs.items())) 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 971, in error_handler raise errors.ACIError(info=info) 2017-02-10T12:20:47Z DEBUG The ipa-replica-install command failed, exception: ACIError: Insufficient access: Insufficient 'add' privilege to add the entry 'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'. 2017-02-10T12:20:47Z ERROR Insufficient access: Insufficient 'add' privilege to add the entry 'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'. 2017-02-10T12:20:47Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information would you share some thoughts? many thanks, L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Fri Feb 10 12:45:49 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 10 Feb 2017 13:45:49 +0100 Subject: [Freeipa-users] replica install - Insufficient 'add' privilege ? In-Reply-To: <640b2285-8f1f-7b79-8e2a-b5db0afbb01e@yahoo.co.uk> References: <640b2285-8f1f-7b79-8e2a-b5db0afbb01e@yahoo.co.uk> Message-ID: <877c5502-3f67-b71a-d328-140736f2d392@redhat.com> On 02/10/2017 01:29 PM, lejeczek wrote: > hi everyone, > > I'm trying something mundane(can't think why, how my setup would be > special/different) - replica installation - but I hit this: > > [42/44]: activating extdom plugin > [43/44]: tuning directory server > [44/44]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROR Insufficient > access: Insufficient 'add' privilege to add the entry > 'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'. > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See /var/log/ipareplica-install.log > for more information > > $and logs tail: > > 2017-02-10T12:20:46Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-WHALE-PRIVATE.socket > conn= > 2017-02-10T12:20:47Z DEBUG Destroyed connection context.ldap2_84192272 > 2017-02-10T12:20:47Z 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/ipapython/install/cli.py", line > 318, in run > cfgr.run() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 310, in run > self.execute() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 332, in execute > for nothing in self._executor(): > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 586, in _configure > next(executor) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 63, in _install > for nothing in self._installer(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1714, in main > promote(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 364, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1425, in promote > remote_api.env.realm) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", > line 43, in ntp_ldap_enable > ntp.ldap_enable('NTP', fqdn, None, base_dn) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 512, in ldap_enable > self.admin_conn.add_entry(entry) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1492, in add_entry > self.conn.add_s(str(entry.dn), list(attrs.items())) > 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 > 971, in error_handler > raise errors.ACIError(info=info) > > 2017-02-10T12:20:47Z DEBUG The ipa-replica-install command failed, > exception: ACIError: Insufficient access: Insufficient 'add' privilege > to add the entry > 'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'. > 2017-02-10T12:20:47Z ERROR Insufficient access: Insufficient 'add' > privilege to add the entry > 'cn=NTP,cn=work3.whale.private,cn=masters,cn=ipa,cn=etc,dc=whale,dc=private'. > 2017-02-10T12:20:47Z ERROR The ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > would you share some thoughts? > many thanks, > L. > > We need to know more details about the replica installation, is it domain level 0? Domain level 1? In domain level 1, do you enroll as admin user or using a privileged host account? Did you re-run the installation? Maybe there is some stale ccache present on your system. -- Martin^3 Babinsky From harald.dunkel at aixigo.de Fri Feb 10 13:03:48 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 10 Feb 2017 14:03:48 +0100 Subject: [Freeipa-users] Jenkins integration? Message-ID: Hi folks, did anybody succeed in using Freeipa for Jenkins' LDAP module? I can't make it work :-(. On the command line the jenkins user appears to have read access to the LDAP database. The config UI for Jenkin's LDAP plugin doesn't complain, either. Jenkins System Log appears to be fine. But if a "freeipa user" tries to login in Jenkins, then he gets an "invalid login information". For Confluence (both are Java Webapps) there was no such problem. Every helpful hint is highly appreciated. Harri From tomek at pipebreaker.pl Fri Feb 10 14:07:04 2017 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Fri, 10 Feb 2017 15:07:04 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: References: Message-ID: <20170210140704.GB114812@mother.pipebreaker.pl> On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: > Hi folks, > > did anybody succeed in using Freeipa for Jenkins' LDAP module? > I can't make it work :-(. I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. I have Jenkins set to PAM authentication, which in turn goes thru SSSD. It works fine, groups are resolved correctly, too. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzichubg at chrome.pl Your routes will be aggreggated. -- Alex Yuriev From guillermo.fuentes at modernizingmedicine.com Fri Feb 10 15:05:14 2017 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Fri, 10 Feb 2017 10:05:14 -0500 Subject: [Freeipa-users] [SOLVED] CA not found? Message-ID: Hi Fraser, Although I modified the ids to release the data, I made sure to use consistent ids where they appeared. As you noted, there was a discrepancy and changing the 'ipacaid' attribute of cn=ipa,cn=cas,cn=ca,dc=ipa,dc=local to match the authorityID from Dogtag fixed the issue. We're now able to sign certificates as before. Yay!!! As of what could have cause this discrepancy, the only thing I can think of is that, back when we migrated the cluster, there were a few times where the cloning of the CA from 3.x to 4.x failed. Thank you very much for your help with this! I really appreciate it! Have a great time off! Guillermo On Fri, Feb 10, 2017 at 5:03 AM, Fraser Tweedale wrote: > On Thu, Feb 09, 2017 at 09:01:01PM -0500, Guillermo Fuentes wrote: >> As we're enforcing encryption, here is via ldaps: >> $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager" -W -s >> sub -b ou=authorities,ou=ca,o=ipaca Enter LDAP >> Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # authorities, ca, ipaca >> dn: ou=authorities,ou=ca,o=ipaca >> objectClass: top >> objectClass: organizationalUnit >> ou: authorities >> >> # 0af769bd-a7ed-4f3a-8859-a877724ea8f2, authorities, ca, ipaca >> dn: cn=0af769bd-a7ed-4f3a-8859-a877724ea8f2,ou=authorities,ou=ca,o=ipaca >> objectClass: authority >> objectClass: top >> cn: 0af769bd-a7ed-4f3a-8859-a877724ea8f2 >> authorityID: 0af769bd-a7ed-4f3a-8859-a877724ea8f2 >> authorityKeyNickname: caSigningCert cert-pki-ca >> authorityEnabled: TRUE >> authorityDN: CN=Certificate Authority,O=EXAMPLE.COM >> description: Host authority >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 3 >> # numEntries: 2 >> >> I'll attach the log files soon. >> > Hi Guillermo, > > Thanks for the files. At a glance, everything looks normal in ipa > upgrade and server startup. > > There is a discrepancy between the authority record in Dogtag > (in the ldapsearch output above) and the corresponding entry in > FreeIPA: > >>> $ ipa ca-show ipa >>> Name: ipa >>> Description: IPA CA >>> Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c >>> Subject DN: CN=Certificate Authority,O=EXAMPLE.COM >>> Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM > > If these are indeed different (not a result of substitutions you > performed in releasing the data), this is a problem I have not seen > before (can you think of anything that might have caused this e.g. > deletion of the authority entry from Dogtag?). To resolve, change > the 'ipacaid' attribute of cn=ipa,cn=cas,cn=ca,dc=ipa,dc=local to > '0af769bd-a7ed-4f3a-8859-a877724ea8f2' > > HTH, > Fraser > > P.S. I am away next week, so please help Guillermo if he's still > having trouble. -- GUILLERMO FUENTES SENIOR SYSTEMS ADMINISTRATOR T: 561-880-2998 x1337 E: ?guillermo.fuentes at modmed.com From me at benroberts.net Fri Feb 10 20:33:27 2017 From: me at benroberts.net (Ben Roberts) Date: Fri, 10 Feb 2017 20:33:27 +0000 Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records In-Reply-To: <15f033b8-276d-22ef-d510-c4dc166fc148@redhat.com> References: <461679326.20722033.1486709481115.JavaMail.zimbra@redhat.com> <15f033b8-276d-22ef-d510-c4dc166fc148@redhat.com> Message-ID: Hi Tomas, > If I understand you correctly, the primary server is filled with data > using bind-dyndb-ldap from an LDAP backend. Then the DS records are > present on the primary server. At this point, bind-dyndb-ldap's work > should be done, since it only serves as the backend LDAP driver for BIND. You understand correctly. > The issue happens when you try to replicate the zone to the secondary > nameserver using AXFR. This leads me to believe that this might be some > issue in the BIND component itself. Perhaps some special configuration > is required. I've not found any documentation that suggests special configuration is required. I spoke to some of the people in #bind before posting to this list, they were also surprised it wasn't working. > It might help you if you'd test the setup without bind-dyndb-ldap with > some mock data directly in BIND. If the AXFR doesn't contain the DS > records then, it's related to BIND. Perhaps the BIND users > (bind-users at lists.isc.org) list might be able to assist you. I've setup the test case directly on one of the primary nameservers with a couple of domains and do see the DS glue records included in the AXFR, so the missing records seem to only be happening when the zonefile is backed by bind-dyndb-ldap. Regards, Ben Roberts From harald.dunkel at aixigo.de Sat Feb 11 06:53:51 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Sat, 11 Feb 2017 07:53:51 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170210140704.GB114812@mother.pipebreaker.pl> References: <20170210140704.GB114812@mother.pipebreaker.pl> Message-ID: <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> On 02/10/17 15:07, Tomasz Torcz wrote: > On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: >> Hi folks, >> >> did anybody succeed in using Freeipa for Jenkins' LDAP module? >> I can't make it work :-(. > > I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. > I have Jenkins set to PAM authentication, which in turn goes thru SSSD. > It works fine, groups are resolved correctly, too. > Thats plan B. Its good to know that this works, but I don't give up that easy. My major problem ist that jenkins doesn't write propper log files. Java is as awkward as it was 20 years ago. Thanx Harri From michael at stroeder.com Sat Feb 11 10:17:57 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Feb 2017 11:17:57 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> Message-ID: <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> Harald Dunkel wrote: > On 02/10/17 15:07, Tomasz Torcz wrote: >> On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: >>> did anybody succeed in using Freeipa for Jenkins' LDAP module? >>> I can't make it work :-(. >> >> I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. >> I have Jenkins set to PAM authentication, which in turn goes thru SSSD. >> It works fine, groups are resolved correctly, too. > > Thats plan B. Its good to know that this works, but I > don't give up that easy. Jenkins' LDAP integration is pretty good and flexible. I made it work with various LDAP servers in customer projects. I did not have do that with FreeIPA yet but I'd be very surprised if it doesn't work. (Personally I'd avoid going through PAM.) Being in your position I'd try to analyze 389-DS' logs to see whether Jenkins contacts your LDAP server and which queries it sends. Most times it's a trivial config item missing. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From abokovoy at redhat.com Sat Feb 11 10:57:40 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 11 Feb 2017 12:57:40 +0200 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> Message-ID: <20170211105740.hhw34i4blkhtvzyv@redhat.com> On la, 11 helmi 2017, Michael Str?der wrote: >Harald Dunkel wrote: >> On 02/10/17 15:07, Tomasz Torcz wrote: >>> On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: >>>> did anybody succeed in using Freeipa for Jenkins' LDAP module? >>>> I can't make it work :-(. >>> >>> I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. >>> I have Jenkins set to PAM authentication, which in turn goes thru SSSD. >>> It works fine, groups are resolved correctly, too. >> >> Thats plan B. Its good to know that this works, but I >> don't give up that easy. > >Jenkins' LDAP integration is pretty good and flexible. I made it work with various LDAP >servers in customer projects. I did not have do that with FreeIPA yet but I'd be very >surprised if it doesn't work. > >(Personally I'd avoid going through PAM.) Any specific reason for not using pam_sss? Remember, with SSSD involved you get also authentication for trusted users from Active Directory realms. You don't get that with generic LDAP way. Also, you'd be more efficient in terms of utilising LDAP connections. -- / Alexander Bokovoy From michael at stroeder.com Sat Feb 11 12:28:42 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Feb 2017 13:28:42 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170211105740.hhw34i4blkhtvzyv@redhat.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> Message-ID: <896f2a1f-8f90-4c81-c7d4-2c1ffa0256a1@stroeder.com> Alexander Bokovoy wrote: > On la, 11 helmi 2017, Michael Str?der wrote: >> Harald Dunkel wrote: >>> On 02/10/17 15:07, Tomasz Torcz wrote: >>>> On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: >>>>> did anybody succeed in using Freeipa for Jenkins' LDAP module? >>>>> I can't make it work :-(. >>>> >>>> I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. >>>> I have Jenkins set to PAM authentication, which in turn goes thru SSSD. >>>> It works fine, groups are resolved correctly, too. >>> >>> Thats plan B. Its good to know that this works, but I >>> don't give up that easy. >> >> Jenkins' LDAP integration is pretty good and flexible. I made it work with various >> LDAP servers in customer projects. I did not have do that with FreeIPA yet but I'd >> be very surprised if it doesn't work. >> >> (Personally I'd avoid going through PAM.) > > Any specific reason for not using pam_sss? At the end it's a matter of personal taste. In my deployments PAM logins have most times nothing to do with the services running on a host which might even use a completely different LDAP service. > Remember, with SSSD involved you get also authentication for trusted users from Active > Directory realms. You don't get that with generic LDAP way. This might be a use-case for which to prefer going through pam_sss. As usual your mileage may vary. But we both know next to nothing about the original posters infrastructure. > Also, you'd be more efficient in terms of utilising LDAP connections. Hmm, IMHO this depends very much on the client software used. Modern Java software has decent LDAP connection pooling. Ciao, Michael. (not a Java fan though) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From harald.dunkel at aixigo.de Sat Feb 11 12:50:30 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Sat, 11 Feb 2017 13:50:30 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170211105740.hhw34i4blkhtvzyv@redhat.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> Message-ID: On 02/11/17 11:57, Alexander Bokovoy wrote: > On la, 11 helmi 2017, Michael Str?der wrote: >> >> (Personally I'd avoid going through PAM.) > Any specific reason for not using pam_sss? Remember, with SSSD involved > you get also authentication for trusted users from Active Directory > realms. You don't get that with generic LDAP way. Also, you'd be more > efficient in terms of utilising LDAP connections. > I would prefer if the users are not allowed to login into a shell on the Jenkins server. Surely this restriction can be implemented with pam as well. Regards Harri From abokovoy at redhat.com Sat Feb 11 13:06:12 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 11 Feb 2017 15:06:12 +0200 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> Message-ID: <20170211130612.vyytog6wmgz23ufw@redhat.com> On la, 11 helmi 2017, Harald Dunkel wrote: >On 02/11/17 11:57, Alexander Bokovoy wrote: >> On la, 11 helmi 2017, Michael Str?der wrote: >>> >>> (Personally I'd avoid going through PAM.) >> Any specific reason for not using pam_sss? Remember, with SSSD involved >> you get also authentication for trusted users from Active Directory >> realms. You don't get that with generic LDAP way. Also, you'd be more >> efficient in terms of utilising LDAP connections. >> > >I would prefer if the users are not allowed to login into a >shell on the Jenkins server. Surely this restriction can be >implemented with pam as well. Yes, you can use HBAC rules to prevent them from access to the host. -- / Alexander Bokovoy From michael at stroeder.com Sat Feb 11 13:18:03 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Feb 2017 14:18:03 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170211130612.vyytog6wmgz23ufw@redhat.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> Message-ID: <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> Alexander Bokovoy wrote: > On la, 11 helmi 2017, Harald Dunkel wrote: >> On 02/11/17 11:57, Alexander Bokovoy wrote: >>> On la, 11 helmi 2017, Michael Str?der wrote: >>>> >>>> (Personally I'd avoid going through PAM.) >>> Any specific reason for not using pam_sss? Remember, with SSSD involved >>> you get also authentication for trusted users from Active Directory >>> realms. You don't get that with generic LDAP way. Also, you'd be more >>> efficient in terms of utilising LDAP connections. >>> >> >> I would prefer if the users are not allowed to login into a >> shell on the Jenkins server. Surely this restriction can be >> implemented with pam as well. > > Yes, you can use HBAC rules to prevent them from access to the host. But this introduces a hard dependency on host system administration which I personally always try to avoid. As said: Your mileage may vary. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From abokovoy at redhat.com Sat Feb 11 15:11:39 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 11 Feb 2017 17:11:39 +0200 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> Message-ID: <20170211151139.sxoqupkh6i7corpp@redhat.com> On la, 11 helmi 2017, Michael Str?der wrote: >Alexander Bokovoy wrote: >> On la, 11 helmi 2017, Harald Dunkel wrote: >>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>>> On la, 11 helmi 2017, Michael Str?der wrote: >>>>> >>>>> (Personally I'd avoid going through PAM.) >>>> Any specific reason for not using pam_sss? Remember, with SSSD involved >>>> you get also authentication for trusted users from Active Directory >>>> realms. You don't get that with generic LDAP way. Also, you'd be more >>>> efficient in terms of utilising LDAP connections. >>>> >>> >>> I would prefer if the users are not allowed to login into a >>> shell on the Jenkins server. Surely this restriction can be >>> implemented with pam as well. >> >> Yes, you can use HBAC rules to prevent them from access to the host. > >But this introduces a hard dependency on host system administration which I personally >always try to avoid. > >As said: Your mileage may vary. So we are talking about FreeIPA and a system enrolled to FreeIPA. This system is already managed in FreeIPA. Your mileage may vary, indeed, but I'd rather re-use what is available to you than implement a parallel infrastructure, including reliability aspects. Anyway, I think we are distancing away from the original topic. -- / Alexander Bokovoy From michael at stroeder.com Sat Feb 11 15:28:55 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Feb 2017 16:28:55 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170211151139.sxoqupkh6i7corpp@redhat.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> Message-ID: <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> Alexander Bokovoy wrote: > On la, 11 helmi 2017, Michael Str?der wrote: >> Alexander Bokovoy wrote: >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>>>> On la, 11 helmi 2017, Michael Str?der wrote: >>>>>> >>>>>> (Personally I'd avoid going through PAM.) >>>>> Any specific reason for not using pam_sss? Remember, with SSSD involved >>>>> you get also authentication for trusted users from Active Directory >>>>> realms. You don't get that with generic LDAP way. Also, you'd be more >>>>> efficient in terms of utilising LDAP connections. >>>>> >>>> >>>> I would prefer if the users are not allowed to login into a >>>> shell on the Jenkins server. Surely this restriction can be >>>> implemented with pam as well. >>> >>> Yes, you can use HBAC rules to prevent them from access to the host. >> >> But this introduces a hard dependency on host system administration which I personally >> always try to avoid. >> >> As said: Your mileage may vary. > > So we are talking about FreeIPA and a system enrolled to FreeIPA. This > system is already managed in FreeIPA. Please don't get me wrong. Of course I assume that the original poster wants to integrate Jenkins with FreeIPA and make use of users and their group membership already maintained therein. Let's further assume that the service (here Jenkins) might be operated by another team than the system - not so unusual case at my customers' sites - relying on defining HBAC rules for the system's sssd might not be feasible. > Your mileage may vary, indeed, but I'd rather re-use what is available > to you than implement a parallel infrastructure, including reliability > aspects. Of course we both agree on the benefits of using what's already available. > Anyway, I think we are distancing away from the original topic. Especially since we both can only make rough assumptions about requirements and operational constraints of the original poster. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ayoung at marketfactory.com Mon Feb 13 21:12:55 2017 From: ayoung at marketfactory.com (Aaron Young) Date: Mon, 13 Feb 2017 16:12:55 -0500 Subject: [Freeipa-users] lost master master and soa Message-ID: hello So, I recently took over this site and a couple days into it, the first ipa server died because of disk corruption. Right now, I've built another ipa server to step into the topology as a replica, but I keep getting strange dns errors during update Looking at it closer, it appears that when nsupdate runs, it fails updating looking closer, I notice that the SOA comes back with the name of the missing server So, it seems like I should change that. So far I've been unable to I get messages back from nsupdate like "response to SOA query was unsuccessful" I'm not sure what information I should send to help with this My main question is, is there a way to force the change of the SOA? aaron -- Aaron Young MarketFactory, Manager of Site Reliability Engineering 425 Broadway, 3FL New York, NY 10013 Office: +1 212 625 9988 Direct +1 646 779 3710 US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Mon Feb 13 22:08:02 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 13 Feb 2017 23:08:02 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate Message-ID: Hi Guys, I'm trying to install a 3rd party certificate using: http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA When I run the install command for the certificate itself: ]# ipa-server-certinstall -w -d mydomain_com.key mydomain_com_bundle.crt Directory Manager password: Enter private key unlock password: list index out of range The ipa-server-certinstall command failed. If I do a #ipa-certupdate the Server-Cert is removed from /etc/httpd/alias and the install fails because of this. What can I do to solve this ? Thanks, Matt From dsullivan2 at bsd.uchicago.edu Tue Feb 14 01:18:56 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Tue, 14 Feb 2017 01:18:56 +0000 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: Message-ID: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> Is the chain in mydomain_com_bundle.crt? Have you tried it with the cert only (disclaimer: I?ve never done this). Dan > On Feb 13, 2017, at 4:08 PM, Matt . wrote: > > Hi Guys, > > I'm trying to install a 3rd party certificate using: > > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA > > When I run the install command for the certificate itself: > > ]# ipa-server-certinstall -w -d mydomain_com.key mydomain_com_bundle.crt > Directory Manager password: > > Enter private key unlock password: > > list index out of range > The ipa-server-certinstall command failed. > > > If I do a #ipa-certupdate the Server-Cert is removed from > /etc/httpd/alias and the install fails because of this. > > What can I do to solve this ? > > Thanks, > > Matt > > -- > 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 mbabinsk at redhat.com Tue Feb 14 07:18:49 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 14 Feb 2017 08:18:49 +0100 Subject: [Freeipa-users] lost master master and soa In-Reply-To: References: Message-ID: <4785748a-fda6-6842-b5ef-199da553e1e9@redhat.com> On 02/13/2017 10:12 PM, Aaron Young wrote: > hello > > So, I recently took over this site and a couple days into it, the first > ipa server died because of disk corruption. > > Right now, I've built another ipa server to step into the topology as a > replica, but I keep getting strange dns errors during update > > Looking at it closer, it appears that when nsupdate runs, it fails updating > > looking closer, I notice that the SOA comes back with the name of the > missing server > > So, it seems like I should change that. So far I've been unable to > > I get messages back from nsupdate like > > "response to SOA query was unsuccessful" > > I'm not sure what information I should send to help with this > > My main question is, is there a way to force the change of the SOA? > > aaron > -- > Aaron Young > MarketFactory, Manager of Site Reliability Engineering > 425 Broadway, 3FL > New York, NY 10013 > Office: +1 212 625 9988 > Direct +1 646 779 3710 > US Support: +1 (212) 625-0688 | UK > Support: +44 (0) 203 695-7997 > > Hi Aaron, there may be some stale NS record on other IPA masters which serve your DNS zone. you can verify this by running: # ipa dnsrecord-show @ and check the list of nameservers returned. To remove the record of the old master run # ipa dnsrecord-del @ --ns-rec Also, make sure you cleaned up old agreements, services, etc. of the old master by running `ipa-replica-manage del --force --cleanup ` on some other IPA master. You will also probably have to stand-up a new CA renewal/CRL master[1] on one of remaining replicas if the first server died and you have CA configured. [1] http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master Hope this helps -- Martin^3 Babinsky From jamesaharrisonuk at yahoo.co.uk Tue Feb 14 10:13:08 2017 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Tue, 14 Feb 2017 10:13:08 +0000 (UTC) Subject: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1 In-Reply-To: <716767681.2300239.1483975110100@mail.yahoo.com> References: <1588224621.467679.1483623416628.ref@mail.yahoo.com> <1588224621.467679.1483623416628@mail.yahoo.com> <1302294420.1935936.1483722924050@mail.yahoo.com> <20170107153359.GA29848@10.4.128.1> <265350268.2066535.1483965848725@mail.yahoo.com> <20170109130931.GF24255@10.4.128.1> <716767681.2300239.1483975110100@mail.yahoo.com> Message-ID: <377624627.6979526.1487067188154@mail.yahoo.com> Hi,Was there any out-come to this? I running: sudo1.8.12-1ubuntu3, which is well behind up to date releases. Many thanks,James Harrison From: James Harrison To: "freeipa-users at redhat.com" ; "pbrezina at redhat.com" Cc: "pbrezina at redhat.com" Sent: Monday, 9 January 2017, 15:18 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1 Hi All,I have attached three files from running sudo -i on the same machine enrolled into Free IPA. They have the output from various versions of sudo. tail -f sudo_debug, syslog, auth.log and sssd/*.log from /var/log to show chronological order of events. The attached files are: sudo-1.8.19-1.txt???? --- from Debian sudo-1.8.16-0ubuntu1.2.txt?? --- Current released Xenial sudo sudo1.8.12-1ubuntu3.txt --- Previous sudo from "wily" https://launchpad.net/ubuntu/wily/amd64/sudo/1.8.12-1ubuntu3 The machine's /etc/sudo.conf has:Debug sudo /var/log/sudo_debug all at debug Debug sudoers.so /var/log/sudo_debug all at debug Plugin sudoers_policy sudoers.so Plugin sudoers_io sudoers.so Hope this helps. Regards,James Harrison From: Lukas Slebodnik To: James Harrison Cc: "freeipa-users at redhat.com" ; pbrezina at redhat.com Sent: Monday, 9 January 2017, 13:09 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1 On (09/01/17 12:44), James Harrison wrote: >All,debian 1.8.19-1 doesnt work, but Ubuntu 1.8.12-1ubuntu3 does. > Could you provide sudo logs with 1.8.19-1 https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO sssd log files will be helpfull as well. LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Feb 14 10:15:53 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 14 Feb 2017 11:15:53 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> Message-ID: Hi Dan, Ues i have tried that and I get the message that it misses the full chain for the certificate. My issue is more, why is the Server-Cert being removed on a certupdate ? Cheers, Matt 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] : > Is the chain in mydomain_com_bundle.crt? Have you tried it with the cert only (disclaimer: I?ve never done this). > > Dan > >> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >> >> Hi Guys, >> >> I'm trying to install a 3rd party certificate using: >> >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >> >> When I run the install command for the certificate itself: >> >> ]# ipa-server-certinstall -w -d mydomain_com.key mydomain_com_bundle.crt >> Directory Manager password: >> >> Enter private key unlock password: >> >> list index out of range >> The ipa-server-certinstall command failed. >> >> >> If I do a #ipa-certupdate the Server-Cert is removed from >> /etc/httpd/alias and the install fails because of this. >> >> What can I do to solve this ? >> >> Thanks, >> >> Matt >> >> -- >> 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 ipa at border.nuneshiggs.com Tue Feb 14 13:00:40 2017 From: ipa at border.nuneshiggs.com (Nuno Higgs) Date: Tue, 14 Feb 2017 13:00:40 -0000 Subject: [Freeipa-users] Cannot login after patching on LXC Container Message-ID: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> Hello All, I have a LXC container running Centos7, fully patched that i can't login into in a standard IPA usage configuration: Feb 13 19:42:07 lxc1 sshd[1536]: pam_sss(sshd:account): Access denied for user nuno 4 (System error) Feb 13 19:42:07 lxc1 sshd[1536]: Failed password for nuno from 172.16.0.10 port 54461 ssh2 Feb 13 19:42:07 lxc1 sshd[1536]: fatal: Access denied for user nuno by PAM account configuration [preauth] Feb 13 19:43:42 lxc1 sshd[1553]: Connection closed by 172.16.3.253 [preauth] Feb 13 19:53:04 lxc1 sshd[1635]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.3.253 user=nuno Feb 13 19:53:04 lxc1 sshd[1635]: pam_sss(sshd:account): Access denied for user nuno: 4 (System error) Feb 13 19:53:04 lxc1 sshd[1632]: error: PAM: User account has expired for nuno from 172.16.3.253 Before the patching I was able to login without any issue with this user. The user or password are not expired, and continue to work perfectly on other systems Centos7 without the patch. This only appears on LXC systems. I've tried to install a fresh centos7 on KVM and it works perfectly. I've done a fresh LXC deployment, and the issue remains. The workaround I found is to comment out the following line on /etc/pam.d/password-auth: #account [default=bad success=ok user_unknown=ignore] pam_sss.so Without this line I am able to login perfectly. The versions are on the client side: Centos7 python2-ipalib-4.4.0-14.el7.centos.4.noarch sssd-ipa-1.14.0-43.el7_3.11.x86_64 python-iniparse-0.4-9.el7.noarch python-libipa_hbac-1.14.0-43.el7_3.11.x86_64 ipa-common-4.4.0-14.el7.centos.4.noarch ipa-client-common-4.4.0-14.el7.centos.4.noarch python2-ipaclient-4.4.0-14.el7.centos.4.noarch libipa_hbac-1.14.0-43.el7_3.11.x86_64 ipa-client-4.4.0-14.el7.centos.4.x86_64 ipa-python-compat-4.4.0-14.el7.centos.4.noarch python-ipaddress-1.0.16-2.el7.noarch On the IPA server: Centos7 python-libipa_hbac-1.14.0-43.el7_3.4.x86_64 python-iniparse-0.4-9.el7.noarch sssd-ipa-1.14.0-43.el7_3.4.x86_64 ipa-client-4.4.0-14.el7.centos.x86_64 ipa-admintools-4.4.0-14.el7.centos.noarch ipa-server-4.4.0-14.el7.centos.x86_64 ipa-client-common-4.4.0-14.el7.centos.noarch python-ipaddress-1.0.16-2.el7.noarch python2-ipaclient-4.4.0-14.el7.centos.noarch python2-ipaserver-4.4.0-14.el7.centos.noarch python2-ipalib-4.4.0-14.el7.centos.noarch ipa-server-common-4.4.0-14.el7.centos.noarch ipa-server-dns-4.4.0-14.el7.centos.noarch ipa-python-compat-4.4.0-14.el7.centos.noarch libipa_hbac-1.14.0-43.el7_3.4.x86_64 ipa-common-4.4.0-14.el7.centos.noarch I think it might be lxc permissions related. I am using the lxc template for Centos7: lxc.cap.drop = sys_nice sys_pacct sys_rawio What am I missing? Thanks for your help. Nuno -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.timmerman at ugent.be Tue Feb 14 13:32:03 2017 From: jens.timmerman at ugent.be (Jens Timmerman) Date: Tue, 14 Feb 2017 14:32:03 +0100 Subject: [Freeipa-users] ipa-replica-install: Certificate operation cannot be completed: Unable to communicate with CMS (503) Message-ID: Hi all, I'm trying to setup a freeipa masterserver and a replica, on a fresh install of CentOS 7.3 after running ipa-server-install on the master and running ipa-client-install on the replica the ipa-replica-install command fails to restart the directory server. Turns out this is because the DS Certificate was never received. It fails with status: CA_UNREACHABLE and I can't figure out why this is failing. Could someone give me some pointers? on the replica: /var/log/ipareplica-install.log 2017-02-14T12:21:20Z DEBUG certmonger request is in state dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) 2017-02-14T12:21:25Z DEBUG certmonger request is in state dbus.String(u'CA_UNREACHABLE', variant_level=1) 2017-02-14T12:21:25Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-MY-REALM.socket from SchemaCache 2017-02-14T12:21:25Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-REALM.socket conn= 2017-02-14T12:21:25Z DEBUG duration: 5 seconds 2017-02-14T12:21:25Z DEBUG [28/44]: restarting directory server # getcert list Number of certificates and requests being tracked: 1. Request ID '20170214122119': status: CA_UNREACHABLE ca-error: Server at https:///ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (503)). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MY_REALM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MY_REALM//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MY_REALM',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes # certutil -L -d /etc/dirsrv/slapd-MY_REALM/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI MY_REALM IPA CA CT,C,C # certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI cacert CTu,Cu,Cu beta u,pu,u alpha u,pu,u Server-Cert u,u,u # curl --negotiate -u : https://ipa-server/ipa/xml --referer https://ipa-server/ipa/xml -I HTTP/1.1 401 Unauthorized Date: Tue, 14 Feb 2017 12:07:02 GMT Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 WWW-Authenticate: Negotiate X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none' Last-Modified: Tue, 17 Jan 2017 17:34:23 GMT Accept-Ranges: bytes Content-Length: 1474 Content-Type: text/html; charset=UTF-8 HTTP/1.1 200 Success Date: Tue, 14 Feb 2017 12:07:02 GMT Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 Set-Cookie: ipa_session= WWW-Authenticate: Negotiate X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none' Vary: Accept-Encoding Content-Type: text/xml; charset=utf-8 On the ipa-server: /var/log/pki/pki-tomcat/ca/debug [14/Feb/2017:13:20:15][Timer-0]: SessionTimer: run() [14/Feb/2017:13:20:15][Timer-0]: LDAPSecurityDomainSessionTable: getSessionIds() [14/Feb/2017:13:20:15][Timer-0]: LDAPSecurityDomainSessionTable: searching ou=sessions,ou=Security Domain,o=ipaca [14/Feb/2017:13:20:15][Timer-0]: In LdapBoundConnFactory::getConn() [14/Feb/2017:13:20:15][Timer-0]: masterConn is connected: true [14/Feb/2017:13:20:15][Timer-0]: getConn: conn is connected true [14/Feb/2017:13:20:15][Timer-0]: getConn: mNumConns now 2 [14/Feb/2017:13:20:15][Timer-0]: SecurityDomainSessionTable: No active sessions. [14/Feb/2017:13:20:15][Timer-0]: returnConn: mNumConns now 3 [14/Feb/2017:13:25:15][Timer-0]: SessionTimer: run() [14/Feb/2017:13:25:15][Timer-0]: LDAPSecurityDomainSessionTable: getSessionIds() [14/Feb/2017:13:25:15][Timer-0]: LDAPSecurityDomainSessionTable: searching ou=sessions,ou=Security Domain,o=ipaca [14/Feb/2017:13:25:15][Timer-0]: In LdapBoundConnFactory::getConn() [14/Feb/2017:13:25:15][Timer-0]: masterConn is connected: true [14/Feb/2017:13:25:15][Timer-0]: getConn: conn is connected true [14/Feb/2017:13:25:15][Timer-0]: getConn: mNumConns now 2 [14/Feb/2017:13:25:15][Timer-0]: SecurityDomainSessionTable: No active sessions. [14/Feb/2017:13:25:15][Timer-0]: returnConn: mNumConns now 3 (so nothing at 13:21:14) ==> /var/log/pki/pki-tomcat/ca/selftests.log <== 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] CAPresence: CA is present 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] SystemCertsVerification: system certs verification success 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] SelfTestSubsystem: All CRITICAL self test plugins ran SUCCESSFULLY at startup! and /var/log/pki/pki-tomcat/localhost.2017-02-14.log is filled with these exceptions that aren't pointing me to anywhere. SEVERE: Servlet.service() for servlet [Resteasy] in context with path [/ca] threw exception org.jboss.resteasy.spi.UnhandledException: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: com.netscape.certsrv.base.PKIException$Data of media type: application/x-www-form-urlencoded at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:157) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) at java.security.AccessController.doPrivileged(Native Method) ... # getcert list Number of certificates and requests being tracked: 8. Request ID '20170214084423': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MY-REALM subject: CN=CA Audit,O=MY-REALM expires: 2019-02-04 08:42:52 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170214084425': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MY-REALM subject: CN=OCSP Subsystem,O=MY-REALM expires: 2019-02-04 08:42:48 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170214084428': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MY-REALM subject: CN=CA Subsystem,O=MY-REALM expires: 2019-02-04 08:42:51 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170214084431': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MY-REALM subject: CN=Certificate Authority,O=MY-REALM expires: 2037-02-14 08:42:43 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170214084434': 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-ca-renew-agent issuer: CN=Certificate Authority,O=MY-REALM subject: CN=IPA RA,O=MY-REALM expires: 2019-02-04 08:44:09 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20170214084436': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MY-REALM subject: CN=ipa-server,O=MY-REALM expires: 2019-02-04 08:42:49 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca" track: yes auto-renew: yes Request ID '20170214084646': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MY-REALM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MY-REALM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MY-REALM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MY-REALM subject: CN=ipa-server,O=MY-REALM expires: 2019-02-15 08:46:45 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv MY-REALM track: yes auto-renew: yes Request ID '20170214085151': 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=MY-REALM subject: CN=ipa-server,O=MY-REALM expires: 2019-02-15 08:51:50 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes # systemctl status pki-tomcatd at pki-tomcat.service ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled; vendor preset: disabled) Active: active (running) since Tue 2017-02-14 10:19:32 CET; 3h 40min ago Main PID: 1300 (java) CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd at pki-tomcat.service ??1300 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java -DRESTEASY_LIB=/usr/share/java/resteasy-base -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/... Feb 14 10:19:57ipa-server server[1300]: SSLAuthenticatorWithFallback: Creating SSL authenticator with fallback Feb 14 10:19:57ipa-server server[1300]: SSLAuthenticatorWithFallback: Setting container Feb 14 10:20:07ipa-server server[1300]: SSLAuthenticatorWithFallback: Initializing authenticators Feb 14 10:20:07ipa-server server[1300]: SSLAuthenticatorWithFallback: Starting authenticators Feb 14 10:20:10ipa-server server[1300]: CMSEngine.initializePasswordStore() begins Feb 14 10:20:10ipa-server server[1300]: CMSEngine.initializePasswordStore(): tag=internaldb Feb 14 10:20:10ipa-server server[1300]: CMSEngine.initializePasswordStore(): tag=replicationdb Feb 14 10:20:15ipa-server server[1300]: CA is started. Feb 14 10:20:26ipa-server server[1300]: PKIListener: org.apache.catalina.core.StandardServer[after_start] Feb 14 10:20:26ipa-server server[1300]: PKIListener: Subsystem CA is running. Regards, Jens Timmerman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From yamakasi.014 at gmail.com Tue Feb 14 13:54:36 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 14 Feb 2017 14:54:36 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> Message-ID: Certs are valid, I will check what you mentioned. I'm also no fan of bundles, more the seperate files but this doesn't seem to work always. At least for the CAroot a bundle was required. Matt 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] : > Have you validated the cert (and dumped the contents) from the command line using the openssl tools? I?ve seen the message you are seeing before, for some reason I seem to remember that it has to do with either a missing or an extra - at either the -----BEGIN CERTIFICATE---- or -----END CERTIFICATE---- (an error from copy and pasting and not copying the actual file). > > I?ve never used certupdate so if what is described above doesn?t help somebody else will have to chime in. > > Dan > >> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >> >> Hi Dan, >> >> Ues i have tried that and I get the message that it misses the full >> chain for the certificate. >> >> My issue is more, why is the Server-Cert being removed on a certupdate ? >> >> Cheers, >> >> Matt >> >> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] : >>> Is the chain in mydomain_com_bundle.crt? Have you tried it with the cert only (disclaimer: I?ve never done this). >>> >>> Dan >>> >>>> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >>>> >>>> Hi Guys, >>>> >>>> I'm trying to install a 3rd party certificate using: >>>> >>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>> >>>> When I run the install command for the certificate itself: >>>> >>>> ]# ipa-server-certinstall -w -d mydomain_com.key mydomain_com_bundle.crt >>>> Directory Manager password: >>>> >>>> Enter private key unlock password: >>>> >>>> list index out of range >>>> The ipa-server-certinstall command failed. >>>> >>>> >>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>> /etc/httpd/alias and the install fails because of this. >>>> >>>> What can I do to solve this ? >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> -- >>>> 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 r3pek at r3pek.org Tue Feb 14 14:11:02 2017 From: r3pek at r3pek.org (Carlos Silva) Date: Tue, 14 Feb 2017 14:11:02 +0000 Subject: [Freeipa-users] ipa-replica-install: Certificate operation cannot be completed: Unable to communicate with CMS (503) In-Reply-To: References: Message-ID: It should be this problem: https://fedorahosted.org/freeipa/ticket/6613 On Tue, Feb 14, 2017 at 1:32 PM, Jens Timmerman wrote: > Hi all, > > > I'm trying to setup a freeipa masterserver and a replica, on a fresh > install of CentOS 7.3 > > after running ipa-server-install on the master and running > ipa-client-install on the replica the ipa-replica-install command fails > to restart the directory server. > > Turns out this is because the DS Certificate was never received. It > fails with status: CA_UNREACHABLE and I can't figure out why this is > failing. > > Could someone give me some pointers? > > on the replica: > > > /var/log/ipareplica-install.log > 2017-02-14T12:21:20Z DEBUG certmonger request is in state > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) > 2017-02-14T12:21:25Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > 2017-02-14T12:21:25Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-MY-REALM.socket from SchemaCache > 2017-02-14T12:21:25Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-MY-REALM.socket > conn= > 2017-02-14T12:21:25Z DEBUG duration: 5 seconds > 2017-02-14T12:21:25Z DEBUG [28/44]: restarting directory server > > > > > # getcert list > Number of certificates and requests being tracked: 1. > Request ID '20170214122119': > status: CA_UNREACHABLE > ca-error: Server at https:///ipa/xml failed request, > will retry: 4301 (RPC failed at server. Certificate operation cannot be > completed: Unable to communicate with CMS (503)). > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-MY_REALM', > nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-MY_REALM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-MY_REALM',nickname='Server-Cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > > # certutil -L -d /etc/dirsrv/slapd-MY_REALM/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > MY_REALM IPA CA CT,C,C > > > # certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > cacert CTu,Cu,Cu > beta u,pu,u > alpha u,pu,u > Server-Cert u,u,u > > > > > # curl --negotiate -u : https://ipa-server/ipa/xml --referer > https://ipa-server/ipa/xml -I > HTTP/1.1 401 Unauthorized > Date: Tue, 14 Feb 2017 12:07:02 GMT > Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 > NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 > WWW-Authenticate: Negotiate > X-Frame-Options: DENY > Content-Security-Policy: frame-ancestors 'none' > Last-Modified: Tue, 17 Jan 2017 17:34:23 GMT > Accept-Ranges: bytes > Content-Length: 1474 > Content-Type: text/html; charset=UTF-8 > > HTTP/1.1 200 Success > Date: Tue, 14 Feb 2017 12:07:02 GMT > Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 > NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 > Set-Cookie: ipa_session= > WWW-Authenticate: Negotiate > X-Frame-Options: DENY > Content-Security-Policy: frame-ancestors 'none' > Vary: Accept-Encoding > Content-Type: text/xml; charset=utf-8 > > > On the ipa-server: > > /var/log/pki/pki-tomcat/ca/debug > > > [14/Feb/2017:13:20:15][Timer-0]: SessionTimer: run() > [14/Feb/2017:13:20:15][Timer-0]: LDAPSecurityDomainSessionTable: > getSessionIds() > [14/Feb/2017:13:20:15][Timer-0]: LDAPSecurityDomainSessionTable: > searching ou=sessions,ou=Security Domain,o=ipaca > [14/Feb/2017:13:20:15][Timer-0]: In LdapBoundConnFactory::getConn() > [14/Feb/2017:13:20:15][Timer-0]: masterConn is connected: true > [14/Feb/2017:13:20:15][Timer-0]: getConn: conn is connected true > [14/Feb/2017:13:20:15][Timer-0]: getConn: mNumConns now 2 > [14/Feb/2017:13:20:15][Timer-0]: SecurityDomainSessionTable: No active > sessions. > [14/Feb/2017:13:20:15][Timer-0]: returnConn: mNumConns now 3 > [14/Feb/2017:13:25:15][Timer-0]: SessionTimer: run() > [14/Feb/2017:13:25:15][Timer-0]: LDAPSecurityDomainSessionTable: > getSessionIds() > [14/Feb/2017:13:25:15][Timer-0]: LDAPSecurityDomainSessionTable: > searching ou=sessions,ou=Security Domain,o=ipaca > [14/Feb/2017:13:25:15][Timer-0]: In LdapBoundConnFactory::getConn() > [14/Feb/2017:13:25:15][Timer-0]: masterConn is connected: true > [14/Feb/2017:13:25:15][Timer-0]: getConn: conn is connected true > [14/Feb/2017:13:25:15][Timer-0]: getConn: mNumConns now 2 > [14/Feb/2017:13:25:15][Timer-0]: SecurityDomainSessionTable: No active > sessions. > [14/Feb/2017:13:25:15][Timer-0]: returnConn: mNumConns now 3 > > > (so nothing at 13:21:14) > > > > ==> /var/log/pki/pki-tomcat/ca/selftests.log <== > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading all self test plugin logger parameters > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading all self test plugin instances > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading all self test plugin instance parameters > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading self test plugins in on-demand order > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading self test plugins in startup order > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: Self test plugins have been successfully loaded! > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > SelfTestSubsystem: Running self test plugins specified to be executed at > startup: > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > CAPresence: CA is present > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > SystemCertsVerification: system certs verification success > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > SelfTestSubsystem: All CRITICAL self test plugins ran SUCCESSFULLY at > startup! > > > and /var/log/pki/pki-tomcat/localhost.2017-02-14.log is filled with > these exceptions that aren't pointing me to anywhere. > > SEVERE: Servlet.service() for servlet [Resteasy] in context with path > [/ca] threw exception > org.jboss.resteasy.spi.UnhandledException: > org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find > MessageBodyWriter for response object of type: > com.netscape.certsrv.base.PKIException$Data of media type: > application/x-www-form-urlencoded > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException( > SynchronousDispatcher.java:157) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke( > SynchronousDispatcher.java:372) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke( > SynchronousDispatcher.java:179) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher. > service(ServletContainerDispatcher.java:220) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service( > HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service( > HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) > at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) > at java.security.AccessController.doPrivileged(Native Method) > > ... > > > # getcert list > Number of certificates and requests being tracked: 8. > Request ID '20170214084423': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=CA Audit,O=MY-REALM > expires: 2019-02-04 08:42:52 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084425': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=OCSP Subsystem,O=MY-REALM > expires: 2019-02-04 08:42:48 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > eku: id-kp-OCSPSigning > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084428': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=CA Subsystem,O=MY-REALM > expires: 2019-02-04 08:42:51 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084431': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=Certificate Authority,O=MY-REALM > expires: 2037-02-14 08:42:43 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "caSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084434': > 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-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=IPA RA,O=MY-REALM > expires: 2019-02-04 08:44:09 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre > post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20170214084436': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=ipa-server,O=MY-REALM > expires: 2019-02-04 08:42:49 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "Server-Cert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084646': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-MY-REALM', > nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-MY-REALM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-MY-REALM', > nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=ipa-server,O=MY-REALM > expires: 2019-02-15 08:46:45 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv MY-REALM > track: yes > auto-renew: yes > Request ID '20170214085151': > 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=MY-REALM > subject: CN=ipa-server,O=MY-REALM > expires: 2019-02-15 08:51:50 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > # systemctl status pki-tomcatd at pki-tomcat.service > ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat > Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled; > vendor preset: disabled) > Active: active (running) since Tue 2017-02-14 10:19:32 CET; 3h 40min ago > Main PID: 1300 (java) > CGroup: > /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd at pki-tomcat.service > ??1300 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java > -DRESTEASY_LIB=/usr/share/java/resteasy-base > -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath > /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/... > > Feb 14 10:19:57ipa-server server[1300]: SSLAuthenticatorWithFallback: > Creating SSL authenticator with fallback > Feb 14 10:19:57ipa-server server[1300]: SSLAuthenticatorWithFallback: > Setting container > Feb 14 10:20:07ipa-server server[1300]: SSLAuthenticatorWithFallback: > Initializing authenticators > Feb 14 10:20:07ipa-server server[1300]: SSLAuthenticatorWithFallback: > Starting authenticators > Feb 14 10:20:10ipa-server server[1300]: > CMSEngine.initializePasswordStore() begins > Feb 14 10:20:10ipa-server server[1300]: > CMSEngine.initializePasswordStore(): tag=internaldb > Feb 14 10:20:10ipa-server server[1300]: > CMSEngine.initializePasswordStore(): tag=replicationdb > Feb 14 10:20:15ipa-server server[1300]: CA is started. > Feb 14 10:20:26ipa-server server[1300]: PKIListener: > org.apache.catalina.core.StandardServer[after_start] > Feb 14 10:20:26ipa-server server[1300]: PKIListener: Subsystem CA is > running. > > > > Regards, > Jens Timmerman > > > > > -- > 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 lslebodn at redhat.com Tue Feb 14 14:55:00 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 14 Feb 2017 15:55:00 +0100 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> Message-ID: <20170214145500.GA17562@10.4.128.1> On (14/02/17 13:00), Nuno Higgs wrote: >Hello All, > > > >I have a LXC container running Centos7, fully patched that i can't login >into in a standard IPA usage configuration: > > >Feb 13 19:42:07 lxc1 sshd[1536]: pam_sss(sshd:account): Access denied for >user nuno 4 (System error) > System error means unexpected state for sssd. I would recommend to follow sssd troubleshooting wiki https://fedorahosted.org/sssd/wiki/Troubleshooting#TroubleshootingAuthenticationPasswordChangeandAccessControl >Feb 13 19:42:07 lxc1 sshd[1536]: Failed password for nuno from 172.16.0.10 >port 54461 ssh2 > >Feb 13 19:42:07 lxc1 sshd[1536]: fatal: Access denied for user nuno by PAM >account configuration [preauth] > >Feb 13 19:43:42 lxc1 sshd[1553]: Connection closed by 172.16.3.253 [preauth] > >Feb 13 19:53:04 lxc1 sshd[1635]: pam_sss(sshd:auth): authentication success; >logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.3.253 user=nuno > >Feb 13 19:53:04 lxc1 sshd[1632]: error: PAM: User account has expired for >nuno from 172.16.3.253 > This error is little bit later but I think it is clear enough. The account is expired. LS From jens.timmerman at ugent.be Tue Feb 14 15:01:36 2017 From: jens.timmerman at ugent.be (Jens Timmerman) Date: Tue, 14 Feb 2017 16:01:36 +0100 Subject: [Freeipa-users] ipa-replica-install: Certificate operation cannot be completed: Unable to communicate with CMS (503) In-Reply-To: References: Message-ID: <8096dfe8-a847-65fe-3a44-d6eb43cb3762@ugent.be> Hi Carlos, On 14/02/2017 15:11, Carlos Silva wrote: > It should be this problem: https://fedorahosted.org/freeipa/ticket/6613 Indeed this was the issue, changing in /etc/hosts ::1 localhost6.localdomain6 localhost6 to ::1 localhost localhost.localdomain localhost6.localdomain6 localhost6 made the ipa-replica-install work. Thank you very much! I could have spent a long time further debugging this. Regards Jens Timmerman > > On Tue, Feb 14, 2017 at 1:32 PM, Jens Timmerman > > wrote: > > Hi all, > > > I'm trying to setup a freeipa masterserver and a replica, on a fresh > install of CentOS 7.3 > > after running ipa-server-install on the master and running > ipa-client-install on the replica the ipa-replica-install command > fails > to restart the directory server. > > Turns out this is because the DS Certificate was never received. It > fails with status: CA_UNREACHABLE and I can't figure out why this is > failing. > > Could someone give me some pointers? > > on the replica: > > > /var/log/ipareplica-install.log > 2017-02-14T12:21:20Z DEBUG certmonger request is in state > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) > 2017-02-14T12:21:25Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > 2017-02-14T12:21:25Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-MY-REALM.socket from SchemaCache > 2017-02-14T12:21:25Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-MY-REALM.socket > conn= > 2017-02-14T12:21:25Z DEBUG duration: 5 seconds > 2017-02-14T12:21:25Z DEBUG [28/44]: restarting directory server > > > > > # getcert list > Number of certificates and requests being tracked: 1. > Request ID '20170214122119': > status: CA_UNREACHABLE > ca-error: Server at https:///ipa/xml failed request, > will retry: 4301 (RPC failed at server. Certificate operation > cannot be > completed: Unable to communicate with CMS (503)). > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-MY_REALM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-MY_REALM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-MY_REALM',nickname='Server-Cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > > # certutil -L -d /etc/dirsrv/slapd-MY_REALM/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > MY_REALM IPA CA CT,C,C > > > # certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > cacert CTu,Cu,Cu > beta u,pu,u > alpha u,pu,u > Server-Cert u,u,u > > > > > # curl --negotiate -u : https://ipa-server/ipa/xml --referer > https://ipa-server/ipa/xml -I > HTTP/1.1 401 Unauthorized > Date: Tue, 14 Feb 2017 12:07:02 GMT > Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 > NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 > WWW-Authenticate: Negotiate > X-Frame-Options: DENY > Content-Security-Policy: frame-ancestors 'none' > Last-Modified: Tue, 17 Jan 2017 17:34:23 GMT > Accept-Ranges: bytes > Content-Length: 1474 > Content-Type: text/html; charset=UTF-8 > > HTTP/1.1 200 Success > Date: Tue, 14 Feb 2017 12:07:02 GMT > Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 > NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 > Set-Cookie: ipa_session= > WWW-Authenticate: Negotiate > X-Frame-Options: DENY > Content-Security-Policy: frame-ancestors 'none' > Vary: Accept-Encoding > Content-Type: text/xml; charset=utf-8 > > > On the ipa-server: > > /var/log/pki/pki-tomcat/ca/debug > > > [14/Feb/2017:13:20:15][Timer-0]: SessionTimer: run() > [14/Feb/2017:13:20:15][Timer-0]: LDAPSecurityDomainSessionTable: > getSessionIds() > [14/Feb/2017:13:20:15][Timer-0]: LDAPSecurityDomainSessionTable: > searching ou=sessions,ou=Security Domain,o=ipaca > [14/Feb/2017:13:20:15][Timer-0]: In LdapBoundConnFactory::getConn() > [14/Feb/2017:13:20:15][Timer-0]: masterConn is connected: true > [14/Feb/2017:13:20:15][Timer-0]: getConn: conn is connected true > [14/Feb/2017:13:20:15][Timer-0]: getConn: mNumConns now 2 > [14/Feb/2017:13:20:15][Timer-0]: SecurityDomainSessionTable: No active > sessions. > [14/Feb/2017:13:20:15][Timer-0]: returnConn: mNumConns now 3 > [14/Feb/2017:13:25:15][Timer-0]: SessionTimer: run() > [14/Feb/2017:13:25:15][Timer-0]: LDAPSecurityDomainSessionTable: > getSessionIds() > [14/Feb/2017:13:25:15][Timer-0]: LDAPSecurityDomainSessionTable: > searching ou=sessions,ou=Security Domain,o=ipaca > [14/Feb/2017:13:25:15][Timer-0]: In LdapBoundConnFactory::getConn() > [14/Feb/2017:13:25:15][Timer-0]: masterConn is connected: true > [14/Feb/2017:13:25:15][Timer-0]: getConn: conn is connected true > [14/Feb/2017:13:25:15][Timer-0]: getConn: mNumConns now 2 > [14/Feb/2017:13:25:15][Timer-0]: SecurityDomainSessionTable: No active > sessions. > [14/Feb/2017:13:25:15][Timer-0]: returnConn: mNumConns now 3 > > > (so nothing at 13:21:14) > > > > ==> /var/log/pki/pki-tomcat/ca/selftests.log <== > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading all self test plugin logger parameters > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading all self test plugin instances > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading all self test plugin instance parameters > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading self test plugins in on-demand order > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: loading self test plugins in startup order > 0.localhost-startStop-1 - [14/Feb/2017:10:20:14 CET] [20] [1] > SelfTestSubsystem: Self test plugins have been successfully loaded! > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > SelfTestSubsystem: Running self test plugins specified to be > executed at > startup: > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > CAPresence: CA is present > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > SystemCertsVerification: system certs verification success > 0.localhost-startStop-1 - [14/Feb/2017:10:20:15 CET] [20] [1] > SelfTestSubsystem: All CRITICAL self test plugins ran SUCCESSFULLY at > startup! > > > and /var/log/pki/pki-tomcat/localhost.2017-02-14.log is filled with > these exceptions that aren't pointing me to anywhere. > > SEVERE: Servlet.service() for servlet [Resteasy] in context with path > [/ca] threw exception > org.jboss.resteasy.spi.UnhandledException: > org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not > find > MessageBodyWriter for response object of type: > com.netscape.certsrv.base.PKIException$Data of media type: > application/x-www-form-urlencoded > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:157) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:731) > at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) > at java.security.AccessController.doPrivileged(Native Method) > > ... > > > # getcert list > Number of certificates and requests being tracked: 8. > Request ID '20170214084423': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=CA Audit,O=MY-REALM > expires: 2019-02-04 08:42:52 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084425': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=OCSP Subsystem,O=MY-REALM > expires: 2019-02-04 08:42:48 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > eku: id-kp-OCSPSigning > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084428': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=CA Subsystem,O=MY-REALM > expires: 2019-02-04 08:42:51 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084431': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=Certificate Authority,O=MY-REALM > expires: 2037-02-14 08:42:43 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "caSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084434': > 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-ca-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=IPA RA,O=MY-REALM > expires: 2019-02-04 08:44:09 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre > post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20170214084436': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=ipa-server,O=MY-REALM > expires: 2019-02-04 08:42:49 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "Server-Cert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20170214084646': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-MY-REALM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-MY-REALM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-MY-REALM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MY-REALM > subject: CN=ipa-server,O=MY-REALM > expires: 2019-02-15 08:46:45 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv > MY-REALM > track: yes > auto-renew: yes > Request ID '20170214085151': > 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=MY-REALM > subject: CN=ipa-server,O=MY-REALM > expires: 2019-02-15 08:51:50 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > # systemctl status pki-tomcatd at pki-tomcat.service > ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat > Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled; > vendor preset: disabled) > Active: active (running) since Tue 2017-02-14 10:19:32 CET; 3h > 40min ago > Main PID: 1300 (java) > CGroup: > /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd at pki-tomcat.service > ??1300 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java > -DRESTEASY_LIB=/usr/share/java/resteasy-base > -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath > /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/... > > Feb 14 10:19:57ipa-server server[1300]: SSLAuthenticatorWithFallback: > Creating SSL authenticator with fallback > Feb 14 10:19:57ipa-server server[1300]: SSLAuthenticatorWithFallback: > Setting container > Feb 14 10:20:07ipa-server server[1300]: SSLAuthenticatorWithFallback: > Initializing authenticators > Feb 14 10:20:07ipa-server server[1300]: SSLAuthenticatorWithFallback: > Starting authenticators > Feb 14 10:20:10ipa-server server[1300]: > CMSEngine.initializePasswordStore() begins > Feb 14 10:20:10ipa-server server[1300]: > CMSEngine.initializePasswordStore(): tag=internaldb > Feb 14 10:20:10ipa-server server[1300]: > CMSEngine.initializePasswordStore(): tag=replicationdb > Feb 14 10:20:15ipa-server server[1300]: CA is started. > Feb 14 10:20:26ipa-server server[1300]: PKIListener: > org.apache.catalina.core.StandardServer[after_start] > Feb 14 10:20:26ipa-server server[1300]: PKIListener: Subsystem CA is > running. > > > > Regards, > Jens Timmerman > > > > > -- > 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: 819 bytes Desc: OpenPGP digital signature URL: From ipa at border.nuneshiggs.com Tue Feb 14 15:14:28 2017 From: ipa at border.nuneshiggs.com (Nuno Higgs) Date: Tue, 14 Feb 2017 15:14:28 -0000 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <20170214145500.GA17562@10.4.128.1> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> Message-ID: <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> Hello Lucas, No, the account is neither locked nor expired. That's the weird part. On other Centos7 / RHEL7 I can login without any issues. [root at ipa2 ~]# ipa user-status nuno ----------------------- Account disabled: False ----------------------- Server: ipa1 Failed logins: 0 Last successful authentication: 20170214150453Z Last failed authentication: 20170213170252Z Time now: 2017-02-14T15:06:21Z Server: ipa2 Failed logins: 0 Last successful authentication: 20170214150047Z Last failed authentication: 20170214124638Z Time now: 2017-02-14T15:06:23Z ---------------------------- Number of entries returned 2 ---------------------------- I've also enabled the sssd. There is no evidence of where the problem is: (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: domain.com (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno at domain.com (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.0.10 (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 9475 (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: nuno (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][domain.com] (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 68 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100): entering pam_cmd_acct_mgmt (Tue Feb 14 15:11:55 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'nuno' matched without domain, user is nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.0.10 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 9475 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [nuno at domain.com] (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [nuno at domain.com@domain.com] (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is nuno at domain.com (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: domain.com (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno at domain.com (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.0.10 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 9475 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Feb 14 15:11:56 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][domain.com] (Tue Feb 14 15:11:56 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Tue Feb 14 15:11:56 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 25 (Tue Feb 14 15:11:56 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! Also remember that this configuration works perfectly if it is a KVM or a LXC. Thanks. Nuno -----Original Message----- From: Lukas Slebodnik [mailto:lslebodn at redhat.com] Sent: ter?a-feira, 14 de fevereiro de 2017 14:55 To: Nuno Higgs Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cannot login after patching on LXC Container On (14/02/17 13:00), Nuno Higgs wrote: >Hello All, > > > >I have a LXC container running Centos7, fully patched that i can't >login into in a standard IPA usage configuration: > > >Feb 13 19:42:07 lxc1 sshd[1536]: pam_sss(sshd:account): Access denied >for user nuno 4 (System error) > System error means unexpected state for sssd. I would recommend to follow sssd troubleshooting wiki https://fedorahosted.org/sssd/wiki/Troubleshooting#TroubleshootingAuthenticationPasswordChangeandAccessControl >Feb 13 19:42:07 lxc1 sshd[1536]: Failed password for nuno from >172.16.0.10 port 54461 ssh2 > >Feb 13 19:42:07 lxc1 sshd[1536]: fatal: Access denied for user nuno by >PAM account configuration [preauth] > >Feb 13 19:43:42 lxc1 sshd[1553]: Connection closed by 172.16.3.253 >[preauth] > >Feb 13 19:53:04 lxc1 sshd[1635]: pam_sss(sshd:auth): authentication >success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.3.253 >user=nuno > >Feb 13 19:53:04 lxc1 sshd[1632]: error: PAM: User account has expired >for nuno from 172.16.3.253 > This error is little bit later but I think it is clear enough. The account is expired. LS From abokovoy at redhat.com Tue Feb 14 15:22:40 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Feb 2017 17:22:40 +0200 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> Message-ID: <20170214152240.dhfu6celfoqeyfaz@redhat.com> On ti, 14 helmi 2017, Nuno Higgs wrote: >Hello Lucas, > >No, the account is neither locked nor expired. That's the weird part. >On other Centos7 / RHEL7 I can login without any issues. > > >[root at ipa2 ~]# ipa user-status nuno >----------------------- >Account disabled: False >----------------------- > Server: ipa1 > Failed logins: 0 > Last successful authentication: 20170214150453Z > Last failed authentication: 20170213170252Z > Time now: 2017-02-14T15:06:21Z > > Server: ipa2 > Failed logins: 0 > Last successful authentication: 20170214150047Z > Last failed authentication: 20170214124638Z > Time now: 2017-02-14T15:06:23Z >---------------------------- >Number of entries returned 2 >---------------------------- > >I've also enabled the sssd. There is no evidence of where the problem is: > >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: domain.com >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno at domain.com >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.0.10 >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 9475 >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: nuno >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][domain.com] >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 68 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100): entering pam_cmd_acct_mgmt >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'nuno' matched without domain, user is nuno >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not set >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.0.10 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 9475 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: nuno >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [nuno at domain.com] >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [nuno at domain.com@domain.com] >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is nuno at domain.com >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: domain.com >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno at domain.com >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.0.10 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 9475 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: nuno >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 >(Tue Feb 14 15:11:56 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][domain.com] >(Tue Feb 14 15:11:56 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. Domain log will have details on what has happened at account PAM stage. Please provide that log, correlated by time with pam log (15:11:55-15:11:56). -- / Alexander Bokovoy From ipa at border.nuneshiggs.com Tue Feb 14 15:34:50 2017 From: ipa at border.nuneshiggs.com (Nuno Higgs) Date: Tue, 14 Feb 2017 15:34:50 -0000 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <20170214152240.dhfu6celfoqeyfaz@redhat.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> Message-ID: <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> Hello Alexander, Here are the logs. I have regenerated the error, because at the first time I hadn't the debug enabled on the domain part of the sssd.conf. After enabling the only thing reported on the sssd_domain.log on the time of the failure is: (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_eval_user_element] (0x1000): Added group [openvpn_home_users] for user [nuno] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): [< hbac_evaluate() (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): ALLOWED by rule [perimetro_ssh_allow]. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): hbac_evaluate() >] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [perimetro_ssh_allow] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_done] (0x0400): DP Request [PAM Account #4]: Request handler finished [0]: Success (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [_dp_req_recv] (0x0400): DP Request [PAM Account #4]: Receiving request data. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] (0x0400): DP Request [PAM Account #4]: Request removed. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_attach_req] (0x0400): DP Request [PAM SELinux #5]: New request. Flags [0000]. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=net,dc=xpto]. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaMigrationEnabled] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=ipaConfig,cn=etc,dc=net,dc=xpto]. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_selinux_get_maps_next] (0x0400): Trying to fetch SELinux maps with following parameters: [2][(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=n et,dc=xpto] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=net, dc=xpto]. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [seeAlso] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUser] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaEnabledFlag] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [selinux_child_done] (0x0020): selinux_child_parse_response failed: [22][Invalid argument] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_done] (0x0400): DP Request [PAM SELinux #5]: Request handler finished [0]: Success (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [_dp_req_recv] (0x0400): DP Request [PAM SELinux #5]: Receiving request data. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] (0x0400): DP Request [PAM SELinux #5]: Request removed. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #4]: Sending result [4][net.xpto] (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [child_sig_handler] (0x1000): Waiting for child [10326]. (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [child_sig_handler] (0x0020): child [10326] failed with status [1]. Thanks, Nuno -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: ter?a-feira, 14 de fevereiro de 2017 15:23 To: Nuno Higgs Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cannot login after patching on LXC Container On ti, 14 helmi 2017, Nuno Higgs wrote: >Hello Lucas, > >No, the account is neither locked nor expired. That's the weird part. >On other Centos7 / RHEL7 I can login without any issues. > > >[root at ipa2 ~]# ipa user-status nuno >----------------------- >Account disabled: False >----------------------- > Server: ipa1 > Failed logins: 0 > Last successful authentication: 20170214150453Z > Last failed authentication: 20170213170252Z > Time now: 2017-02-14T15:06:21Z > > Server: ipa2 > Failed logins: 0 > Last successful authentication: 20170214150047Z > Last failed authentication: 20170214124638Z > Time now: 2017-02-14T15:06:23Z >---------------------------- >Number of entries returned 2 >---------------------------- > >I've also enabled the sssd. There is no evidence of where the problem is: > >(Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): >command: SSS_PAM_AUTHENTICATE (Tue Feb 14 15:11:54 2017) [sssd[pam]] >[pam_print_data] (0x0100): domain: domain.com (Tue Feb 14 15:11:54 >2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno at domain.com (Tue >Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): service: >sshd (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): >tty: ssh (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] >(0x0100): ruser: not set (Tue Feb 14 15:11:54 2017) [sssd[pam]] >[pam_print_data] (0x0100): rhost: 172.16.0.10 (Tue Feb 14 15:11:54 >2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Tue Feb >14 15:11:54 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok >type: 0 (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_print_data] >(0x0100): priv: 1 (Tue Feb 14 15:11:54 2017) [sssd[pam]] >[pam_print_data] (0x0100): cli_pid: 9475 (Tue Feb 14 15:11:54 2017) >[sssd[pam]] [pam_print_data] (0x0100): logon name: nuno (Tue Feb 14 15:11:54 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][domain.com] (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 68 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100): >entering pam_cmd_acct_mgmt (Tue Feb 14 15:11:55 2017) [sssd[pam]] >[sss_parse_name_for_domains] (0x0200): name 'nuno' matched without >domain, user is nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] >[pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT (Tue Feb 14 >15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not set >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): user: >nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): >service: sshd (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] >(0x0100): tty: ssh (Tue Feb 14 15:11:55 2017) [sssd[pam]] >[pam_print_data] (0x0100): ruser: not set (Tue Feb 14 15:11:55 2017) >[sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.0.10 (Tue Feb 14 >15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): >newauthtok type: 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] >[pam_print_data] (0x0100): priv: 1 (Tue Feb 14 15:11:55 2017) >[sssd[pam]] [pam_print_data] (0x0100): cli_pid: 9475 (Tue Feb 14 >15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [nuno at domain.com] (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [nuno at domain.com@domain.com] (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is nuno at domain.com (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: >(Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): >command: SSS_PAM_ACCT_MGMT (Tue Feb 14 15:11:55 2017) [sssd[pam]] >[pam_print_data] (0x0100): domain: domain.com (Tue Feb 14 15:11:55 >2017) [sssd[pam]] [pam_print_data] (0x0100): user: nuno at domain.com (Tue >Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): service: >sshd (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): >tty: ssh (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] >(0x0100): ruser: not set (Tue Feb 14 15:11:55 2017) [sssd[pam]] >[pam_print_data] (0x0100): rhost: 172.16.0.10 (Tue Feb 14 15:11:55 >2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Feb >14 15:11:55 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok >type: 0 (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_print_data] >(0x0100): priv: 1 (Tue Feb 14 15:11:55 2017) [sssd[pam]] >[pam_print_data] (0x0100): cli_pid: 9475 (Tue Feb 14 15:11:55 2017) >[sssd[pam]] [pam_print_data] (0x0100): logon name: nuno (Tue Feb 14 15:11:55 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Feb 14 15:11:56 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][domain.com] (Tue Feb 14 15:11:56 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. Domain log will have details on what has happened at account PAM stage. Please provide that log, correlated by time with pam log (15:11:55-15:11:56). -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd.tar.gz Type: application/x-gzip Size: 17468 bytes Desc: not available URL: From abokovoy at redhat.com Tue Feb 14 16:01:52 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Feb 2017 18:01:52 +0200 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> Message-ID: <20170214160152.hiimiggd7bkhvrzy@redhat.com> On ti, 14 helmi 2017, Nuno Higgs wrote: >Hello Alexander, > >Here are the logs. I have regenerated the error, because at the first time I >hadn't the debug enabled on the domain part of the sssd.conf. >After enabling the only thing reported on the sssd_domain.log on the time of >the failure is: > >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_eval_user_element] >(0x1000): Added group [openvpn_home_users] for user [nuno] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): [< >hbac_evaluate() >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): >ALLOWED by rule [perimetro_ssh_allow]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): >hbac_evaluate() >] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_hbac_evaluate_rules] >(0x0080): Access granted by HBAC rule [perimetro_ssh_allow] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_done] (0x0400): DP >Request [PAM Account #4]: Request handler finished [0]: Success >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [_dp_req_recv] (0x0400): DP >Request [PAM Account #4]: Receiving request data. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] >(0x0400): DP Request [PAM Account #4]: Request removed. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] >(0x0400): Number of active DP request: 0 >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_attach_req] (0x0400): DP >Request [PAM SELinux #5]: New request. Flags [0000]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_attach_req] (0x0400): >Number of active DP request: 1 >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_get_selinux_send] >(0x0400): Retrieving SELinux user mapping >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x0400): calling ldap_search_ext with >[(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=net,dc=xpto]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaMigrationEnabled] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_parse_entry] (0x1000): >OriginalDN: [cn=ipaConfig,cn=etc,dc=net,dc=xpto]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no >errmsg set >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_selinux_get_maps_next] >(0x0400): Trying to fetch SELinux maps with following parameters: >[2][(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=n >et,dc=xpto] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x0400): calling ldap_search_ext with >[(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=net, >dc=xpto]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [objectClass] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [cn] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [memberUser] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [memberHost] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [seeAlso] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaSELinuxUser] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaEnabledFlag] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [userCategory] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [hostCategory] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaUniqueID] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no >errmsg set >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_selinux_get_maps_done] >(0x0400): No SELinux user maps found! >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sysdb_delete_entry] >(0x0080): sysdb_delete_ts_entry failed: 0 >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [write_pipe_handler] >(0x0400): All data has been sent! >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [read_pipe_handler] >(0x0400): EOF received, client finished >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [selinux_child_done] >(0x0020): selinux_child_parse_response failed: [22][Invalid argument] ^^ this is the issue. There was a change in behavior in libselinux that caused the library to fail every time it is run in an environment where it cannot identify whether SELinux is enabled or not. You can disable SELinux processing in your sssd.conf: [domain/...] selinux_provider = none -- / Alexander Bokovoy From ipa at border.nuneshiggs.com Tue Feb 14 16:19:10 2017 From: ipa at border.nuneshiggs.com (Nuno Higgs) Date: Tue, 14 Feb 2017 16:19:10 -0000 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <20170214160152.hiimiggd7bkhvrzy@redhat.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> Message-ID: <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> Hello, It worked perfecty. I am wondering why this just popped up now with this patch update. Almost none of our containers hosts (and by inherence the containers) have SELINUX enabled for they are primary for testing, and they are on a secure network. With this version of ipa-client, the host has to have SE enabled for the container to inherit the definitions and policies of it? Again thanks for your help! Nuno -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: ter?a-feira, 14 de fevereiro de 2017 16:02 To: Nuno Higgs Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cannot login after patching on LXC Container On ti, 14 helmi 2017, Nuno Higgs wrote: >Hello Alexander, > >Here are the logs. I have regenerated the error, because at the first >time I hadn't the debug enabled on the domain part of the sssd.conf. >After enabling the only thing reported on the sssd_domain.log on the >time of the failure is: > >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[hbac_eval_user_element] >(0x1000): Added group [openvpn_home_users] for user [nuno] (Tue Feb 14 >15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): [< >hbac_evaluate() >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): >ALLOWED by rule [perimetro_ssh_allow]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [hbac_evaluate] (0x0100): >hbac_evaluate() >] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[ipa_hbac_evaluate_rules] >(0x0080): Access granted by HBAC rule [perimetro_ssh_allow] (Tue Feb 14 >15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_done] (0x0400): DP Request >[PAM Account #4]: Request handler finished [0]: Success (Tue Feb 14 >15:24:52 2017) [sssd[be[net.xpto]]] [_dp_req_recv] (0x0400): DP Request >[PAM Account #4]: Receiving request data. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] >(0x0400): DP Request [PAM Account #4]: Request removed. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_req_destructor] >(0x0400): Number of active DP request: 0 (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [dp_attach_req] (0x0400): DP Request [PAM SELinux >#5]: New request. Flags [0000]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [dp_attach_req] (0x0400): >Number of active DP request: 1 >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [ipa_get_selinux_send] >(0x0400): Retrieving SELinux user mapping (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x0400): calling ldap_search_ext with >[(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=net,dc=xpto]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaMigrationEnabled] (Tue Feb 14 15:24:52 >2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] (Tue Feb 14 >15:24:52 2017) [sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] (Tue Feb 14 >15:24:52 2017) [sssd[be[net.xpto]]] [sdap_parse_entry] (0x1000): >OriginalDN: [cn=ipaConfig,cn=etc,dc=net,dc=xpto]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no >errmsg set (Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[ipa_selinux_get_maps_next] >(0x0400): Trying to fetch SELinux maps with following parameters: >[2][(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux >,dc=n >et,dc=xpto] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_ext_step] >(0x0400): calling ldap_search_ext with >[(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc >=net, >dc=xpto]. >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [objectClass] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [cn] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [memberUser] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [memberHost] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [seeAlso] >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] >[sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaSELinuxUser] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaEnabledFlag] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [userCategory] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [hostCategory] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_ext_step] >(0x1000): Requesting attrs: [ipaUniqueID] (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [sdap_get_generic_op_finished] (0x0400): Search >result: Success(0), no errmsg set (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [ipa_selinux_get_maps_done] >(0x0400): No SELinux user maps found! >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [sysdb_delete_entry] >(0x0080): sysdb_delete_ts_entry failed: 0 (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [write_pipe_handler] >(0x0400): All data has been sent! >(Tue Feb 14 15:24:52 2017) [sssd[be[net.xpto]]] [read_pipe_handler] >(0x0400): EOF received, client finished (Tue Feb 14 15:24:52 2017) >[sssd[be[net.xpto]]] [selinux_child_done] >(0x0020): selinux_child_parse_response failed: [22][Invalid argument] ^^ this is the issue. There was a change in behavior in libselinux that caused the library to fail every time it is run in an environment where it cannot identify whether SELinux is enabled or not. You can disable SELinux processing in your sssd.conf: [domain/...] selinux_provider = none -- / Alexander Bokovoy From flo at redhat.com Tue Feb 14 16:24:17 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 14 Feb 2017 17:24:17 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> Message-ID: <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> On 02/14/2017 02:54 PM, Matt . wrote: > Certs are valid, I will check what you mentioned. > > I'm also no fan of bundles, more the seperate files but this doesn't > seem to work always. At least for the CAroot a bundle was required. > Hi Matt, if your certificate was provided by an intermediate CA, you need to add each CA before running ipa-server-certinstall (start from the top-level CA with ipa-cacert-manage install, then run ipa-certupdate, then the intermediate CA with ipa-cacert-manage install, then ipa-certupdate etc...) There is also a known issue with ipa-certupdate and SELinux in enforcing mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). Flo. > Matt > > 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] : >> Have you validated the cert (and dumped the contents) from the command line using the openssl tools? I?ve seen the message you are seeing before, for some reason I seem to remember that it has to do with either a missing or an extra - at either the -----BEGIN CERTIFICATE---- or -----END CERTIFICATE---- (an error from copy and pasting and not copying the actual file). >> >> I?ve never used certupdate so if what is described above doesn?t help somebody else will have to chime in. >> >> Dan >> >>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>> >>> Hi Dan, >>> >>> Ues i have tried that and I get the message that it misses the full >>> chain for the certificate. >>> >>> My issue is more, why is the Server-Cert being removed on a certupdate ? >>> >>> Cheers, >>> >>> Matt >>> >>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] : >>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with the cert only (disclaimer: I?ve never done this). >>>> >>>> Dan >>>> >>>>> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >>>>> >>>>> Hi Guys, >>>>> >>>>> I'm trying to install a 3rd party certificate using: >>>>> >>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>> >>>>> When I run the install command for the certificate itself: >>>>> >>>>> ]# ipa-server-certinstall -w -d mydomain_com.key mydomain_com_bundle.crt >>>>> Directory Manager password: >>>>> >>>>> Enter private key unlock password: >>>>> >>>>> list index out of range >>>>> The ipa-server-certinstall command failed. >>>>> >>>>> >>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>> /etc/httpd/alias and the install fails because of this. >>>>> >>>>> What can I do to solve this ? >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> -- >>>>> 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 Tue Feb 14 16:28:11 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Feb 2017 18:28:11 +0200 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> Message-ID: <20170214162811.z6vwtqzi5pade6pj@redhat.com> On ti, 14 helmi 2017, Nuno Higgs wrote: >Hello, > >It worked perfecty. >I am wondering why this just popped up now with this patch update. Almost >none of our containers hosts (and by inherence the containers) have SELINUX >enabled for they are primary for testing, and they are on a secure network. >With this version of ipa-client, the host has to have SE enabled for the >container to inherit the definitions and policies of it? As I said, this was an update in SELinux-related libraries and change of behavior there, not in SSSD. It is reproducible in other environments as well, see, f.e. https://bugzilla.redhat.com/show_bug.cgi?id=1415167 The workaround is to disable selinux provider in the environment where SELinux is not used until SELinux libraries are fixed. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Tue Feb 14 16:43:26 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 14 Feb 2017 17:43:26 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> Message-ID: Hi Florance, Thanks for your update, good to see some good into about it. For Comodo I have install all these: AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt Where COMODORSADomainValidationSecureServerCA.crt is not needed as far as I know but the same issues still exist, the Server-Cert is removed again on ipa-certupdate and fails. I have tried this with setenforce 0 Cheers, Matt 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : > On 02/14/2017 02:54 PM, Matt . wrote: >> >> Certs are valid, I will check what you mentioned. >> >> I'm also no fan of bundles, more the seperate files but this doesn't >> seem to work always. At least for the CAroot a bundle was required. >> > Hi Matt, > > if your certificate was provided by an intermediate CA, you need to add each > CA before running ipa-server-certinstall (start from the top-level CA with > ipa-cacert-manage install, then run ipa-certupdate, then the intermediate CA > with ipa-cacert-manage install, then ipa-certupdate etc...) > > There is also a known issue with ipa-certupdate and SELinux in enforcing > mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). > > Flo. > > >> Matt >> >> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >> : >>> >>> Have you validated the cert (and dumped the contents) from the command >>> line using the openssl tools? I?ve seen the message you are seeing before, >>> for some reason I seem to remember that it has to do with either a missing >>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>> CERTIFICATE---- (an error from copy and pasting and not copying the actual >>> file). >>> >>> I?ve never used certupdate so if what is described above doesn?t help >>> somebody else will have to chime in. >>> >>> Dan >>> >>>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>>> >>>> Hi Dan, >>>> >>>> Ues i have tried that and I get the message that it misses the full >>>> chain for the certificate. >>>> >>>> My issue is more, why is the Server-Cert being removed on a certupdate ? >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>> : >>>>> >>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with the >>>>> cert only (disclaimer: I?ve never done this). >>>>> >>>>> Dan >>>>> >>>>>> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >>>>>> >>>>>> Hi Guys, >>>>>> >>>>>> I'm trying to install a 3rd party certificate using: >>>>>> >>>>>> >>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>> >>>>>> When I run the install command for the certificate itself: >>>>>> >>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>> mydomain_com_bundle.crt >>>>>> Directory Manager password: >>>>>> >>>>>> Enter private key unlock password: >>>>>> >>>>>> list index out of range >>>>>> The ipa-server-certinstall command failed. >>>>>> >>>>>> >>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>> /etc/httpd/alias and the install fails because of this. >>>>>> >>>>>> What can I do to solve this ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> -- >>>>>> 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 flo at redhat.com Tue Feb 14 16:54:09 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 14 Feb 2017 17:54:09 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> Message-ID: On 02/14/2017 05:43 PM, Matt . wrote: > Hi Florance, > > Thanks for your update, good to see some good into about it. For > Comodo I have install all these: > > AddTrustExternalCARoot.crt > COMODORSAAddTrustCA.crt > COMODORSADomainValidationSecureServerCA.crt > > Where COMODORSADomainValidationSecureServerCA.crt is not needed as > far as I know but the same issues still exist, the Server-Cert is > removed again on ipa-certupdate and fails. > > I have tried this with setenforce 0 > Hi Matt, can you provide more info in order to reproduce the issue? - which OS are you using - IPA version - how did you install ipa server (CA-less or with self-signed CA or with externally-signed CA?) Thanks, Flo. > Cheers, > > Matt > > 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >> On 02/14/2017 02:54 PM, Matt . wrote: >>> >>> Certs are valid, I will check what you mentioned. >>> >>> I'm also no fan of bundles, more the seperate files but this doesn't >>> seem to work always. At least for the CAroot a bundle was required. >>> >> Hi Matt, >> >> if your certificate was provided by an intermediate CA, you need to add each >> CA before running ipa-server-certinstall (start from the top-level CA with >> ipa-cacert-manage install, then run ipa-certupdate, then the intermediate CA >> with ipa-cacert-manage install, then ipa-certupdate etc...) >> >> There is also a known issue with ipa-certupdate and SELinux in enforcing >> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >> >> Flo. >> >> >>> Matt >>> >>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>> : >>>> >>>> Have you validated the cert (and dumped the contents) from the command >>>> line using the openssl tools? I?ve seen the message you are seeing before, >>>> for some reason I seem to remember that it has to do with either a missing >>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>> CERTIFICATE---- (an error from copy and pasting and not copying the actual >>>> file). >>>> >>>> I?ve never used certupdate so if what is described above doesn?t help >>>> somebody else will have to chime in. >>>> >>>> Dan >>>> >>>>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>>>> >>>>> Hi Dan, >>>>> >>>>> Ues i have tried that and I get the message that it misses the full >>>>> chain for the certificate. >>>>> >>>>> My issue is more, why is the Server-Cert being removed on a certupdate ? >>>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>> : >>>>>> >>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with the >>>>>> cert only (disclaimer: I?ve never done this). >>>>>> >>>>>> Dan >>>>>> >>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >>>>>>> >>>>>>> Hi Guys, >>>>>>> >>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>> >>>>>>> >>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>> >>>>>>> When I run the install command for the certificate itself: >>>>>>> >>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>> mydomain_com_bundle.crt >>>>>>> Directory Manager password: >>>>>>> >>>>>>> Enter private key unlock password: >>>>>>> >>>>>>> list index out of range >>>>>>> The ipa-server-certinstall command failed. >>>>>>> >>>>>>> >>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>> >>>>>>> What can I do to solve this ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> -- >>>>>>> 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 yamakasi.014 at gmail.com Tue Feb 14 16:59:49 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 14 Feb 2017 17:59:49 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> Message-ID: Hi Florance, Sure I can, here you go: Fedora 24 Freeipa VERSION: 4.4.2, API_VERSION: 2.215 I installed this server as self-signed CA Cheers, Matt 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : > On 02/14/2017 05:43 PM, Matt . wrote: >> >> Hi Florance, >> >> Thanks for your update, good to see some good into about it. For >> Comodo I have install all these: >> >> AddTrustExternalCARoot.crt >> COMODORSAAddTrustCA.crt >> COMODORSADomainValidationSecureServerCA.crt >> >> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >> far as I know but the same issues still exist, the Server-Cert is >> removed again on ipa-certupdate and fails. >> >> I have tried this with setenforce 0 >> > Hi Matt, > > can you provide more info in order to reproduce the issue? > - which OS are you using > - IPA version > - how did you install ipa server (CA-less or with self-signed CA or with > externally-signed CA?) > > Thanks, > Flo. > > >> Cheers, >> >> Matt >> >> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>> >>> On 02/14/2017 02:54 PM, Matt . wrote: >>>> >>>> >>>> Certs are valid, I will check what you mentioned. >>>> >>>> I'm also no fan of bundles, more the seperate files but this doesn't >>>> seem to work always. At least for the CAroot a bundle was required. >>>> >>> Hi Matt, >>> >>> if your certificate was provided by an intermediate CA, you need to add >>> each >>> CA before running ipa-server-certinstall (start from the top-level CA >>> with >>> ipa-cacert-manage install, then run ipa-certupdate, then the intermediate >>> CA >>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>> >>> There is also a known issue with ipa-certupdate and SELinux in enforcing >>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>> >>> Flo. >>> >>> >>>> Matt >>>> >>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>> : >>>>> >>>>> >>>>> Have you validated the cert (and dumped the contents) from the command >>>>> line using the openssl tools? I?ve seen the message you are seeing >>>>> before, >>>>> for some reason I seem to remember that it has to do with either a >>>>> missing >>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>> CERTIFICATE---- (an error from copy and pasting and not copying the >>>>> actual >>>>> file). >>>>> >>>>> I?ve never used certupdate so if what is described above doesn?t help >>>>> somebody else will have to chime in. >>>>> >>>>> Dan >>>>> >>>>>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>>>>> >>>>>> Hi Dan, >>>>>> >>>>>> Ues i have tried that and I get the message that it misses the full >>>>>> chain for the certificate. >>>>>> >>>>>> My issue is more, why is the Server-Cert being removed on a certupdate >>>>>> ? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>> : >>>>>>> >>>>>>> >>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with the >>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >>>>>>>> >>>>>>>> Hi Guys, >>>>>>>> >>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>> >>>>>>>> When I run the install command for the certificate itself: >>>>>>>> >>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>> mydomain_com_bundle.crt >>>>>>>> Directory Manager password: >>>>>>>> >>>>>>>> Enter private key unlock password: >>>>>>>> >>>>>>>> list index out of range >>>>>>>> The ipa-server-certinstall command failed. >>>>>>>> >>>>>>>> >>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>> >>>>>>>> What can I do to solve this ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> -- >>>>>>>> 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 lslebodn at redhat.com Tue Feb 14 17:52:33 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 14 Feb 2017 18:52:33 +0100 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <20170214162811.z6vwtqzi5pade6pj@redhat.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> <20170214162811.z6vwtqzi5pade6pj@redhat.com> Message-ID: <20170214175232.GB19720@10.4.128.1> On (14/02/17 18:28), Alexander Bokovoy wrote: >On ti, 14 helmi 2017, Nuno Higgs wrote: >> Hello, >> >> It worked perfecty. >> I am wondering why this just popped up now with this patch update. Almost >> none of our containers hosts (and by inherence the containers) have SELINUX >> enabled for they are primary for testing, and they are on a secure network. >> With this version of ipa-client, the host has to have SE enabled for the >> container to inherit the definitions and policies of it? >As I said, this was an update in SELinux-related libraries and change of >behavior there, not in SSSD. It is reproducible in other environments as >well, see, f.e. https://bugzilla.redhat.com/show_bug.cgi?id=1415167 > Sorry you are wrong. This is a different bug. https://bugzilla.redhat.com/show_bug.cgi?id=1412717 which is unfortunatelly private. Here is an upstream ticket https://fedorahosted.org/sssd/ticket/3308 The interesting is that some user reported that downgrade of ipa python packages fixed the bug as well. 12:23 < lfisher> lslebodn: well the problematic users seem to be ones that haven't been on the host before 12:23 < lfisher> I also noticed if I updated the package, so I did an ipa downgrade on the host (or version change) it started working temporarily 12:24 < lslebodn> which package? 12:25 < lslebodn> sssd? 12:25 < lslebodn> libsemanage? 12:27 < lfisher> well, the ipa-client package and everything that it depends on, so it's like 7 packages 12:27 < lfisher> which may have libsemanage in it, let me check 12:27 < lslebodn> ipa-client is just an installator 12:28 < lslebodn> all important things are done by sssd 12:29 < lfisher> lslebodn: Give me a sec and I'll pull the package list out ... 12:34 < lfisher> ipa-client, ipa-client-common, ipa-common, python2-ipalib, python2-ipaclient 12:34 < lfisher> a downgrade of those solved the problem tempoarily 12:40 < lslebodn> that's weird 12:41 < lslebodn> they are not used by sssd 12:41 < lslebodn> and they should not affect sssd 12:45 < lfisher> lslebodn: yeah, it didn't really make sense, but since even a restart sometimes solves the problem, it just probably kicked something LS From lslebodn at redhat.com Tue Feb 14 17:58:16 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 14 Feb 2017 18:58:16 +0100 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> Message-ID: <20170214175816.GC19720@10.4.128.1> On (14/02/17 16:19), Nuno Higgs wrote: >Hello, > >It worked perfecty. >I am wondering why this just popped up now with this patch update. Almost >none of our containers hosts (and by inherence the containers) have SELINUX >enabled for they are primary for testing, and they are on a secure network. >With this version of ipa-client, the host has to have SE enabled for the >container to inherit the definitions and policies of it? > Could you try to downdrade some packages and find you which package trigger this bug? Or could you provide a reliable reproducer with lxc contianers? LS From lslebodn at redhat.com Tue Feb 14 19:12:41 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 14 Feb 2017 20:12:41 +0100 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <20170214175232.GB19720@10.4.128.1> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> <20170214162811.z6vwtqzi5pade6pj@redhat.com> <20170214175232.GB19720@10.4.128.1> Message-ID: <20170214191240.GA26764@10.4.128.1> On (14/02/17 18:52), Lukas Slebodnik wrote: >On (14/02/17 18:28), Alexander Bokovoy wrote: >>On ti, 14 helmi 2017, Nuno Higgs wrote: >>> Hello, >>> >>> It worked perfecty. >>> I am wondering why this just popped up now with this patch update. Almost >>> none of our containers hosts (and by inherence the containers) have SELINUX >>> enabled for they are primary for testing, and they are on a secure network. >>> With this version of ipa-client, the host has to have SE enabled for the >>> container to inherit the definitions and policies of it? >>As I said, this was an update in SELinux-related libraries and change of >>behavior there, not in SSSD. It is reproducible in other environments as >>well, see, f.e. https://bugzilla.redhat.com/show_bug.cgi?id=1415167 >> >Sorry you are wrong. >This is a different bug. >https://bugzilla.redhat.com/show_bug.cgi?id=1412717 >which is unfortunatelly private. > I thought a little bit and I am not sure which bug is this case. What do "sestatus" inside container? LS From wgraboyes at cenic.org Tue Feb 14 19:17:51 2017 From: wgraboyes at cenic.org (William Graboyes) Date: Tue, 14 Feb 2017 11:17:51 -0800 Subject: [Freeipa-users] Yubikey 4 Usage Message-ID: Hello all, I am very lost at the moment, I cannot seem to get a yubikey 4 to work with freeipa. Server information: CentOS Linux Release 7.3.1611 ipa-server-4.4.0-14.el7.centos.4.x86_64 I installed the IPA admin tools on my laptop and joined it to IPA, and have successfully ran the otptoken-add-yubikey command, however when I go to sync the otp token, all I ever get is "The username, password or token codes are not correct", I am also unable to use the key as a login (which seems obvious to me since I cannot sync the key). Either way I have tried it as password+yubikey, yubikey, and yubikey+password. I am at a loss here, any help would be greatly appreciated. Thanks, Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ipa at border.nuneshiggs.com Tue Feb 14 20:06:58 2017 From: ipa at border.nuneshiggs.com (Nuno Higgs) Date: Tue, 14 Feb 2017 20:06:58 -0000 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <20170214191240.GA26764@10.4.128.1> References: <05c201d286c2$58454dc0$08cfe940$@border.nuneshiggs.com> <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> <20170214162811.z6vwtqzi5pade6pj@redhat.com> <20170214175232.GB19720@10.4.128.1> <20170214191240.GA26764@10.4.128.1> Message-ID: <067701d286fd$e57d07b0$b0771710$@border.nuneshiggs.com> Hello all, I will reproduce the issue tomorrow morning on a fresh LXC container. For the sestatus: # sestatus SELinux status: disabled That isn?t surprising for the host is not se-enabled, or even a RHEL/CentOS. The underlining distro supports apparmor profiles. The crappy part is before we did this patch update, everything worked perfectly, although with SE Disabled. I will keep you posted on the LXC test Thanks! Nuno -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Lukas Slebodnik Sent: ter?a-feira, 14 de fevereiro de 2017 19:13 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cannot login after patching on LXC Container On (14/02/17 18:52), Lukas Slebodnik wrote: >On (14/02/17 18:28), Alexander Bokovoy wrote: >>On ti, 14 helmi 2017, Nuno Higgs wrote: >>> Hello, >>> >>> It worked perfecty. >>> I am wondering why this just popped up now with this patch update. >>> Almost none of our containers hosts (and by inherence the >>> containers) have SELINUX enabled for they are primary for testing, and they are on a secure network. >>> With this version of ipa-client, the host has to have SE enabled for >>> the container to inherit the definitions and policies of it? >>As I said, this was an update in SELinux-related libraries and change >>of behavior there, not in SSSD. It is reproducible in other >>environments as well, see, f.e. >>https://bugzilla.redhat.com/show_bug.cgi?id=1415167 >> >Sorry you are wrong. >This is a different bug. >https://bugzilla.redhat.com/show_bug.cgi?id=1412717 >which is unfortunatelly private. > I thought a little bit and I am not sure which bug is this case. What do "sestatus" inside container? 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 lslebodn at redhat.com Wed Feb 15 09:15:58 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 15 Feb 2017 10:15:58 +0100 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <067701d286fd$e57d07b0$b0771710$@border.nuneshiggs.com> References: <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> <20170214162811.z6vwtqzi5pade6pj@redhat.com> <20170214175232.GB19720@10.4.128.1> <20170214191240.GA26764@10.4.128.1> <067701d286fd$e57d07b0$b0771710$@border.nuneshiggs.com> Message-ID: <20170215091558.GA23337@10.4.128.1> On (14/02/17 20:06), Nuno Higgs wrote: >Hello all, > >I will reproduce the issue tomorrow morning on a fresh LXC container. >For the sestatus: > ># sestatus >SELinux status: disabled > >That isn?t surprising for the host is not se-enabled, or even a RHEL/CentOS. >The underlining distro supports apparmor profiles. FYI: It is not about distribution but about kernel. >The crappy part is before we did this patch update, everything worked >perfectly, although with SE Disabled. > >I will keep you posted on the LXC test > It would be good to find out which package/update broke it. LS From dimitris.beletsiotis at gmail.com Wed Feb 15 09:57:30 2017 From: dimitris.beletsiotis at gmail.com (Dimitris Beletsiotis) Date: Wed, 15 Feb 2017 11:57:30 +0200 Subject: [Freeipa-users] Cannot enter $ character in "group name" of "user groups" Message-ID: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> Hello, Despite the documentation that says that we can use $ in "group names" the web gui does not allow it, pls see attached. Is there some option to enable this? Thanks, Dimitris Beletsiotis -------------- next part -------------- A non-text attachment was scrubbed... Name: 2017-02-15_114850.png Type: image/png Size: 22423 bytes Desc: not available URL: From th at casalogic.dk Wed Feb 15 10:04:47 2017 From: th at casalogic.dk (Troels Hansen) Date: Wed, 15 Feb 2017 11:04:47 +0100 (CET) Subject: [Freeipa-users] IPA and SSSD sudo Message-ID: <1127865287.2031429.1487153087937.JavaMail.zimbra@casalogic.dk> Hi there We have a strange problem....... We're trying to override options in sudo rules from IPA, in this case secure_path: sudo -ll reports: RunAsUsers: root Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate, secure_path=/bin:/usr/bin:/usr/local/bin Commands: stopinst /usr/local/bin/stopinst /usr/local/bin/startinst /bin/mount /rman /usr/bin/su - root /usr/local/bin is also in my local path: $ echo $PATH /usr/local/bin:/usr/bin:/usr/local/sbin.......... For easyness, stopinst is currently quite simple: $ cat /usr/local/bin/stopinst #!/bin/bash echo stopinst echo "Path: $PATH" I can execute the script a normal user, using full path or just the command: $ stopinst stopinst Path: /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin However, trying to execute the script using sudo fails: $ sudo stopinst [sudo] password for drextrha: sudo: stopinst: command not found Unless using full path: $ sudo /usr/local/bin/stopinst stopinst Path: /bin:/usr/bin:/usr/local/bin Secure path in sudoers is: # grep secure_path /etc/sudoers Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin If I change the secure_path in local sudoers to include /usr/local/bin: # grep secure_path /etc/sudoers Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin I can execute the command using sudo: $ sudo stopinst stopinst Path: /bin:/usr/bin:/usr/local/bin Soooo...... something gets overwritten somewhere that shouldn't??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmzgames.de at googlemail.com Wed Feb 15 10:28:11 2017 From: gmzgames.de at googlemail.com (Gerald Zabos) Date: Wed, 15 Feb 2017 11:28:11 +0100 Subject: [Freeipa-users] Delegation + visibility on users/user groups Message-ID: Hello all, after setting up a productive IPA 4.4 environment with eight nodes (master + replicas) on four different locations everything works well. Good job, guys. I am tinkering around with user management and prepared an example setup: - create one supervisor user (bob) - create four team users on bob's team (bridget, betty, bernard, bill) - create a user group (b-team) with bob, bridget, betty, bernard, bill as active users in that team Now i want to achieve the following: - supervisor (bob) can see his team members (bridget, betty, bernard, bill) -and only his team members- to handle administrative tasks within his team -and only his team- , e.g. reset their password, lock their account, change their information. Use case: external customer gets limited access and MUST NOT see our internal users and/or other external customers. Can someone please point me to the right documentation and/or give me hints on how to achieve this? Regards, Gerald -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 15 10:51:29 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Feb 2017 12:51:29 +0200 Subject: [Freeipa-users] Delegation + visibility on users/user groups In-Reply-To: References: Message-ID: <20170215105129.h2dy6jcbuadgmlxe@redhat.com> On ke, 15 helmi 2017, Gerald Zabos wrote: >Hello all, > >after setting up a productive IPA 4.4 environment with eight nodes (master >+ replicas) on four different locations everything works well. Good job, >guys. > >I am tinkering around with user management and prepared an example setup: > >- create one supervisor user (bob) >- create four team users on bob's team (bridget, betty, bernard, bill) >- create a user group (b-team) with bob, bridget, betty, bernard, bill as >active users in that team > >Now i want to achieve the following: > >- supervisor (bob) can see his team members (bridget, betty, bernard, bill) >-and only his team members- to handle administrative tasks within his team >-and only his team- , e.g. reset their password, lock their account, change >their information. > >Use case: external customer gets limited access and MUST NOT see our >internal users and/or other external customers. Not seeing other users or objects is no possible with FreeIPA design. It is also security through obscurity and doesn't really contribute anything. You should be looking at proper permissions/roles to confine what bob and others could actually do, not see. >Can someone please point me to the right documentation and/or give me hints >on how to achieve this? I have practical example in my blog, for hosts, not people: https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/ -- / Alexander Bokovoy From mbasti at redhat.com Wed Feb 15 11:27:08 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 15 Feb 2017 12:27:08 +0100 Subject: [Freeipa-users] Cannot enter $ character in "group name" of "user groups" In-Reply-To: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> References: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> Message-ID: On 15.02.2017 10:57, Dimitris Beletsiotis wrote: > Hello, > > Despite the documentation that says that we can use $ in "group names" > the web gui does not allow it, pls see attached. > Is there some option to enable this? > > Thanks, > Dimitris Beletsiotis > > Hello, I checked the code and '$' can be used only as the last character in group name, so error message is not quite exact PATTERN_GROUPUSER_NAME = '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$' Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmzgames.de at googlemail.com Wed Feb 15 11:31:06 2017 From: gmzgames.de at googlemail.com (Gerald Zabos) Date: Wed, 15 Feb 2017 12:31:06 +0100 Subject: [Freeipa-users] Delegation + visibility on users/user groups In-Reply-To: <20170215105129.h2dy6jcbuadgmlxe@redhat.com> References: <20170215105129.h2dy6jcbuadgmlxe@redhat.com> Message-ID: Hello Alexander, > Not seeing other users or objects is no possible with FreeIPA design. It is also security through obscurity and doesn't really contribute anything. > You should be looking at proper permissions/roles to confine what bob and others could actually do, not see. > I have practical example in my blog, for hosts, not people: https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/ Thanks for your answers. Your blog was already a good starting point for me in the past. This article is exactly why i got here with my question ;-) -- Regards, Gerald Zabos On Wed, Feb 15, 2017 at 11:51 AM, Alexander Bokovoy wrote: > On ke, 15 helmi 2017, Gerald Zabos wrote: >> >> Hello all, >> >> after setting up a productive IPA 4.4 environment with eight nodes (master >> + replicas) on four different locations everything works well. Good job, >> guys. >> >> I am tinkering around with user management and prepared an example setup: >> >> - create one supervisor user (bob) >> - create four team users on bob's team (bridget, betty, bernard, bill) >> - create a user group (b-team) with bob, bridget, betty, bernard, bill as >> active users in that team >> >> Now i want to achieve the following: >> >> - supervisor (bob) can see his team members (bridget, betty, bernard, >> bill) >> -and only his team members- to handle administrative tasks within his team >> -and only his team- , e.g. reset their password, lock their account, >> change >> their information. >> >> Use case: external customer gets limited access and MUST NOT see our >> internal users and/or other external customers. > > Not seeing other users or objects is no possible with FreeIPA design. It > is also security through obscurity and doesn't really contribute > anything. > > You should be looking at proper permissions/roles to confine what bob > and others could actually do, not see. > > >> Can someone please point me to the right documentation and/or give me >> hints >> on how to achieve this? > > I have practical example in my blog, for hosts, not people: > https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/ > > -- > / Alexander Bokovoy From ipa at border.nuneshiggs.com Wed Feb 15 11:32:07 2017 From: ipa at border.nuneshiggs.com (Nuno Higgs) Date: Wed, 15 Feb 2017 11:32:07 -0000 Subject: [Freeipa-users] Cannot login after patching on LXC Container In-Reply-To: <20170215091558.GA23337@10.4.128.1> References: <20170214145500.GA17562@10.4.128.1> <061401d286d5$093bdd80$1bb39880$@border.nuneshiggs.com> <20170214152240.dhfu6celfoqeyfaz@redhat.com> <061a01d286d7$e1a05f00$a4e11d00$@border.nuneshiggs.com> <20170214160152.hiimiggd7bkhvrzy@redhat.com> <062b01d286de$13469460$39d3bd20$@border.nuneshiggs.com> <20170214162811.z6vwtqzi5pade6pj@redhat.com> <20170214175232.GB19720@10.4.128.1> <20170214191240.GA26764@10.4.128.1> <067701d286fd$e57d07b0$b0771710$@border.nuneshiggs.com> <20170215091558.GA23337@10.4.128.1> Message-ID: <079501d2877f$23891b30$6a9b5190$@border.nuneshiggs.com> Hello, I've done a fresh install of a Centos7 container and the problem was seen again. The lxc build installed the files as described within the enclosed txt file. For versions: # yum --showduplicates list ipa-client ipa-client-common ipa-common python2-ipalib python2-ipaclient Installed Packages ipa-client.x86_64 4.4.0-14.el7.centos.4 @updates ipa-client-common.noarch 4.4.0-14.el7.centos.4 @updates ipa-common.noarch 4.4.0-14.el7.centos.4 @updates python2-ipaclient.noarch 4.4.0-14.el7.centos.4 @updates python2-ipalib.noarch 4.4.0-14.el7.centos.4 @updates Available Packages ipa-client.x86_64 4.4.0-12.el7.centos base ipa-client.x86_64 4.4.0-14.el7.centos updates ipa-client.x86_64 4.4.0-14.el7.centos.1.1 updates ipa-client.x86_64 4.4.0-14.el7.centos.4 updates ipa-client-common.noarch 4.4.0-12.el7.centos base ipa-client-common.noarch 4.4.0-14.el7.centos updates ipa-client-common.noarch 4.4.0-14.el7.centos.1.1 updates ipa-client-common.noarch 4.4.0-14.el7.centos.4 updates ipa-common.noarch 4.4.0-12.el7.centos base ipa-common.noarch 4.4.0-14.el7.centos updates ipa-common.noarch 4.4.0-14.el7.centos.1.1 updates ipa-common.noarch 4.4.0-14.el7.centos.4 updates python2-ipaclient.noarch 4.4.0-12.el7.centos base python2-ipaclient.noarch 4.4.0-14.el7.centos updates python2-ipaclient.noarch 4.4.0-14.el7.centos.1.1 updates python2-ipaclient.noarch 4.4.0-14.el7.centos.4 updates python2-ipalib.noarch 4.4.0-12.el7.centos base python2-ipalib.noarch 4.4.0-14.el7.centos updates python2-ipalib.noarch 4.4.0-14.el7.centos.1.1 updates python2-ipalib.noarch First downgrade: # yum downgrade ipa-client ipa-client-common ipa-common python2-ipalib python2-ipaclient Removed: ipa-client.x86_64 0:4.4.0-14.el7.centos.4 ipa-client-common.noarch 0:4.4.0-14.el7.centos.4 ipa-common.noarch 0:4.4.0-14.el7.centos.4 python2-ipaclient.noarch 0:4.4.0-14.el7.centos.4 python2-ipalib.noarch 0:4.4.0-14.el7.centos.4 Installed: ipa-client.x86_64 0:4.4.0-14.el7.centos.1.1 ipa-client-common.noarch 0:4.4.0-14.el7.centos.1.1 ipa-common.noarch 0:4.4.0-14.el7.centos.1.1 python2-ipaclient.noarch 0:4.4.0-14.el7.centos.1.1 python2-ipalib.noarch 0:4.4.0-14.el7.centos.1.1 Problem still present. Second downgrade: Removed: ipa-client.x86_64 0:4.4.0-14.el7.centos.1.1 ipa-client-common.noarch 0:4.4.0-14.el7.centos.1.1 ipa-common.noarch 0:4.4.0-14.el7.centos.1.1 python2-ipaclient.noarch 0:4.4.0-14.el7.centos.1.1 python2-ipalib.noarch 0:4.4.0-14.el7.centos.1.1 Installed: ipa-client.x86_64 0:4.4.0-14.el7.centos ipa-client-common.noarch 0:4.4.0-14.el7.centos ipa-common.noarch 0:4.4.0-14.el7.centos python2-ipaclient.noarch 0:4.4.0-14.el7.centos python2-ipalib.noarch 0:4.4.0-14.el7.centos Problem still present. Third downgrade: Removed: ipa-client.x86_64 0:4.4.0-14.el7.centos ipa-client-common.noarch 0:4.4.0-14.el7.centos ipa-common.noarch 0:4.4.0-14.el7.centos python2-ipaclient.noarch 0:4.4.0-14.el7.centos python2-ipalib.noarch 0:4.4.0-14.el7.centos Installed: ipa-client.x86_64 0:4.4.0-12.el7.centos ipa-client-common.noarch 0:4.4.0-12.el7.centos ipa-common.noarch 0:4.4.0-12.el7.centos python2-ipaclient.noarch 0:4.4.0-12.el7.centos python2-ipalib.noarch 0:4.4.0-12.el7.centos Problem still present. There is not any downgrade available on repo to go lower. The error is still the same. It would appear to be outside of the ipa package range. Feb 15 11:05:38 ipatest sshd[231]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.6 user=nuno Feb 15 11:05:39 ipatest sshd[231]: pam_sss(sshd:account): Access denied for user nuno: 4 (System error) Feb 15 11:05:39 ipatest sshd[229]: error: PAM: User account has expired for nuno from 172.16.0.6 Feb 15 11:05:42 ipatest sshd[229]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.6 user=nuno Feb 15 11:05:42 ipatest sshd[229]: Failed password for nuno from 172.16.0.6 port 54450 ssh2 Feb 15 11:05:42 ipatest sshd[229]: fatal: Access denied for user nuno by PAM account configuration [preauth] I tried to downgrade sssd but was unable to for lack of dependencies. Thanks. Nuno -----Original Message----- From: Lukas Slebodnik [mailto:lslebodn at redhat.com] Sent: quarta-feira, 15 de fevereiro de 2017 09:16 To: Nuno Higgs Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cannot login after patching on LXC Container On (14/02/17 20:06), Nuno Higgs wrote: >Hello all, > >I will reproduce the issue tomorrow morning on a fresh LXC container. >For the sestatus: > ># sestatus >SELinux status: disabled > >That isn?t surprising for the host is not se-enabled, or even a RHEL/CentOS. >The underlining distro supports apparmor profiles. FYI: It is not about distribution but about kernel. >The crappy part is before we did this patch update, everything worked >perfectly, although with SE Disabled. > >I will keep you posted on the LXC test > It would be good to find out which package/update broke it. LS From mbabinsk at redhat.com Wed Feb 15 11:42:48 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 15 Feb 2017 12:42:48 +0100 Subject: [Freeipa-users] Cannot enter $ character in "group name" of "user groups" In-Reply-To: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> References: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> Message-ID: On 02/15/2017 10:57 AM, Dimitris Beletsiotis wrote: > Hello, > > Despite the documentation that says that we can use $ in "group names" > the web gui does not allow it, pls see attached. > Is there some option to enable this? > > Thanks, > Dimitris Beletsiotis > > The IdM documentation states that dollar sign at the end of user/group name is due to Samba 3.x support[1]. I an yet to find a reason why $ is forbidden in all other positions. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-users-life-cycle.html#username-format -- Martin^3 Babinsky From jens.timmerman at ugent.be Wed Feb 15 12:40:17 2017 From: jens.timmerman at ugent.be (Jens Timmerman) Date: Wed, 15 Feb 2017 13:40:17 +0100 Subject: [Freeipa-users] Cannot enter $ character in "group name" of "user groups" In-Reply-To: References: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> Message-ID: <7a965a78-11ce-6bd6-bc46-fb8aa2e7ef77@ugent.be> Hi Martin, On 15/02/2017 12:27, Martin Basti wrote: > > > > On 15.02.2017 10:57, Dimitris Beletsiotis wrote: >> Hello, >> >> Despite the documentation that says that we can use $ in "group >> names" the web gui does not allow it, pls see attached. >> Is there some option to enable this? >> >> Thanks, >> Dimitris Beletsiotis >> >> > Hello, > > I checked the code and '$' can be used only as the last character in > group name, so error message is not quite exact > > PATTERN_GROUPUSER_NAME = '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$' Since this is a pattern to be matched, the $ actually means something (it is an end of string anchor) and is not a literal '$' character. see http://www.regular-expressions.info/anchors.html Regards, Jens Timmerman > > Martin^2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 15 12:52:16 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Feb 2017 14:52:16 +0200 Subject: [Freeipa-users] Cannot enter $ character in "group name" of "user groups" In-Reply-To: <7a965a78-11ce-6bd6-bc46-fb8aa2e7ef77@ugent.be> References: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> <7a965a78-11ce-6bd6-bc46-fb8aa2e7ef77@ugent.be> Message-ID: <20170215125216.daxfkla5rgem4264@redhat.com> On ke, 15 helmi 2017, Jens Timmerman wrote: >Hi Martin, > > >On 15/02/2017 12:27, Martin Basti wrote: >> >> >> >> On 15.02.2017 10:57, Dimitris Beletsiotis wrote: >>> Hello, >>> >>> Despite the documentation that says that we can use $ in "group >>> names" the web gui does not allow it, pls see attached. >>> Is there some option to enable this? >>> >>> Thanks, >>> Dimitris Beletsiotis >>> >>> >> Hello, >> >> I checked the code and '$' can be used only as the last character in >> group name, so error message is not quite exact >> >> PATTERN_GROUPUSER_NAME = '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$' >Since this is a pattern to be matched, the $ actually means something >(it is an end of string anchor) and is not a literal '$' character. >see >http://www.regular-expressions.info/anchors.html The third set of allowed characters at the end includes $. The set [a-zA-Z0-9_.$-]? has '?' qualifier which means it is optional. But end result is to allow '$' as the last character of a group or user name. However, '$' is not allowed anywhere else. This makes possible to have machine or trusted domain accounts for Active Directory/Samba purposes but nothing else with '$' sign in the name. -- / Alexander Bokovoy From jens.timmerman at ugent.be Wed Feb 15 13:07:22 2017 From: jens.timmerman at ugent.be (Jens Timmerman) Date: Wed, 15 Feb 2017 14:07:22 +0100 Subject: [Freeipa-users] Cannot enter $ character in "group name" of "user groups" In-Reply-To: <20170215125216.daxfkla5rgem4264@redhat.com> References: <26c8fa00-2a70-8144-cb6b-3b2de2188ec6@gmail.com> <7a965a78-11ce-6bd6-bc46-fb8aa2e7ef77@ugent.be> <20170215125216.daxfkla5rgem4264@redhat.com> Message-ID: On 15/02/2017 13:52, Alexander Bokovoy wrote: > On ke, 15 helmi 2017, Jens Timmerman wrote: >> Hi Martin, >> >> >> On 15/02/2017 12:27, Martin Basti wrote: >>> >>> >>> >>> On 15.02.2017 10:57, Dimitris Beletsiotis wrote: >>>> Hello, >>>> >>>> Despite the documentation that says that we can use $ in "group >>>> names" the web gui does not allow it, pls see attached. >>>> Is there some option to enable this? >>>> >>>> Thanks, >>>> Dimitris Beletsiotis >>>> >>>> >>> Hello, >>> >>> I checked the code and '$' can be used only as the last character in >>> group name, so error message is not quite exact >>> >>> PATTERN_GROUPUSER_NAME = >>> '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$' >> Since this is a pattern to be matched, the $ actually means something >> (it is an end of string anchor) and is not a literal '$' character. >> see >> http://www.regular-expressions.info/anchors.html > The third set of allowed characters at the end includes $. The set > [a-zA-Z0-9_.$-]? has '?' qualifier which means it is optional. But end > result is to allow '$' as the last character of a group or user name. > > However, '$' is not allowed anywhere else. This makes possible to have > machine or trusted domain accounts for Active Directory/Samba purposes > but nothing else with '$' sign in the name. > Oops, Indeed, I just noticed, read a bit too fast, sorry for the junk. From raul at dias.com.br Wed Feb 15 13:10:03 2017 From: raul at dias.com.br (Raul Dias) Date: Wed, 15 Feb 2017 11:10:03 -0200 Subject: [Freeipa-users] Bind Journal errors Message-ID: <7e1d3203-381a-1c16-2aec-7c79685744e4@dias.com.br> Hello, My IPA's named daemon start to show this dyndb journal logs: error: malformed transaction: dyndb-ldap/ipa/master/17.10.10.in-addr.arpa/raw.jnl last serial 1484327694 != transaction first serial 1484327693 restarting it did not help. What should I do? Thanks -rsd From jhrozek at redhat.com Wed Feb 15 13:38:46 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 15 Feb 2017 14:38:46 +0100 Subject: [Freeipa-users] IPA and SSSD sudo In-Reply-To: <1127865287.2031429.1487153087937.JavaMail.zimbra@casalogic.dk> References: <1127865287.2031429.1487153087937.JavaMail.zimbra@casalogic.dk> Message-ID: <20170215133846.enmjbzojmq2nmef2@hendrix> On Wed, Feb 15, 2017 at 11:04:47AM +0100, Troels Hansen wrote: > Hi there > > We have a strange problem....... > > We're trying to override options in sudo rules from IPA, in this case secure_path: > > sudo -ll reports: > > RunAsUsers: root > Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate, secure_path=/bin:/usr/bin:/usr/local/bin > Commands: > stopinst > /usr/local/bin/stopinst > /usr/local/bin/startinst > /bin/mount /rman > /usr/bin/su - root > > /usr/local/bin is also in my local path: > > $ echo $PATH > /usr/local/bin:/usr/bin:/usr/local/sbin.......... > > For easyness, stopinst is currently quite simple: > > $ cat /usr/local/bin/stopinst > #!/bin/bash > echo stopinst > echo "Path: $PATH" > > I can execute the script a normal user, using full path or just the command: > $ stopinst > stopinst > Path: /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin > > However, trying to execute the script using sudo fails: > $ sudo stopinst > [sudo] password for drextrha: > sudo: stopinst: command not found > > Unless using full path: > $ sudo /usr/local/bin/stopinst > stopinst > Path: /bin:/usr/bin:/usr/local/bin > > Secure path in sudoers is: > # grep secure_path /etc/sudoers > Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin > > If I change the secure_path in local sudoers to include /usr/local/bin: > # grep secure_path /etc/sudoers > Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin > > I can execute the command using sudo: > > $ sudo stopinst > stopinst > Path: /bin:/usr/bin:/usr/local/bin > > Soooo...... something gets overwritten somewhere that shouldn't??? We shouldn't rewrite anything on the SSSD side. In general, when it comes to delivering SUDO rules, SSSD should more or less just act as a proxy. Did you try to define a similar rule locally in /etc/sudoers to see if the same issue happens with a local rule? That should at least confirm or deny that the issue might be in SSSD. From th at casalogic.dk Wed Feb 15 13:44:18 2017 From: th at casalogic.dk (Troels Hansen) Date: Wed, 15 Feb 2017 14:44:18 +0100 (CET) Subject: [Freeipa-users] IPA and SSSD sudo In-Reply-To: <20170215133846.enmjbzojmq2nmef2@hendrix> References: <1127865287.2031429.1487153087937.JavaMail.zimbra@casalogic.dk> <20170215133846.enmjbzojmq2nmef2@hendrix> Message-ID: <234182527.2034400.1487166258299.JavaMail.zimbra@casalogic.dk> The same rule works as expected if defined in the local sudoers file. I think the problem is that secure_path in "Options" from IPA isn't taken into account. As described, if I add the path to the one i local sudoers the sudo command from IPA works. ----- On Feb 15, 2017, at 2:38 PM, Jakub Hrozek jhrozek at redhat.com wrote: > On Wed, Feb 15, 2017 at 11:04:47AM +0100, Troels Hansen wrote: >> Hi there >> >> We have a strange problem....... >> >> We're trying to override options in sudo rules from IPA, in this case >> secure_path: >> >> sudo -ll reports: >> >> RunAsUsers: root >> Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate, >> secure_path=/bin:/usr/bin:/usr/local/bin >> Commands: >> stopinst >> /usr/local/bin/stopinst >> /usr/local/bin/startinst >> /bin/mount /rman >> /usr/bin/su - root >> >> /usr/local/bin is also in my local path: >> >> $ echo $PATH >> /usr/local/bin:/usr/bin:/usr/local/sbin.......... >> >> For easyness, stopinst is currently quite simple: >> >> $ cat /usr/local/bin/stopinst >> #!/bin/bash >> echo stopinst >> echo "Path: $PATH" >> >> I can execute the script a normal user, using full path or just the command: >> $ stopinst >> stopinst >> Path: >> /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin >> >> However, trying to execute the script using sudo fails: >> $ sudo stopinst >> [sudo] password for drextrha: >> sudo: stopinst: command not found >> >> Unless using full path: >> $ sudo /usr/local/bin/stopinst >> stopinst >> Path: /bin:/usr/bin:/usr/local/bin >> >> Secure path in sudoers is: >> # grep secure_path /etc/sudoers >> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin >> >> If I change the secure_path in local sudoers to include /usr/local/bin: >> # grep secure_path /etc/sudoers >> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin >> >> I can execute the command using sudo: >> >> $ sudo stopinst >> stopinst >> Path: /bin:/usr/bin:/usr/local/bin >> >> Soooo...... something gets overwritten somewhere that shouldn't??? > > We shouldn't rewrite anything on the SSSD side. In general, when it > comes to delivering SUDO rules, SSSD should more or less just act as a > proxy. > > Did you try to define a similar rule locally in /etc/sudoers to see if > the same issue happens with a local rule? That should at least confirm > or deny that the issue might be in SSSD. > > -- > 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From mbasti at redhat.com Wed Feb 15 14:16:26 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 15 Feb 2017 15:16:26 +0100 Subject: [Freeipa-users] Bind Journal errors In-Reply-To: <7e1d3203-381a-1c16-2aec-7c79685744e4@dias.com.br> References: <7e1d3203-381a-1c16-2aec-7c79685744e4@dias.com.br> Message-ID: <14d11f16-dd07-5149-5cf3-890717fe0676@redhat.com> On 15.02.2017 14:10, Raul Dias wrote: > Hello, > > My IPA's named daemon start to show this dyndb journal logs: > > error: malformed transaction: > dyndb-ldap/ipa/master/17.10.10.in-addr.arpa/raw.jnl last serial > 1484327694 != transaction first serial 1484327693 > > restarting it did not help. > > What should I do? > > Thanks > -rsd > Hello, could you provide broader context, are there logged any events before this error message? Do you use dns views? Martin From michael at stroeder.com Wed Feb 15 14:47:21 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=C3=B6der?=) Date: Wed, 15 Feb 2017 15:47:21 +0100 Subject: [Freeipa-users] Delegation + visibility on users/user groups In-Reply-To: <20170215105129.h2dy6jcbuadgmlxe@redhat.com> References: <20170215105129.h2dy6jcbuadgmlxe@redhat.com> Message-ID: On 2017-02-15 11:51, Alexander Bokovoy wrote: > On ke, 15 helmi 2017, Gerald Zabos wrote: >> Use case: external customer gets limited access and MUST NOT see our >> internal users and/or other external customers. > > Not seeing other users or objects is no possible with FreeIPA design. > It > is also security through obscurity and doesn't really contribute > anything. IMHO such a use-case is a valid security requirement for preventing social engineering threats. Anyway customer accounts are critical regarding _confidentiality_: 1. Customers must not see internal users and their contact data for not being able to circumvent controlled support processes. 2. Customers must not see other customers (competitors) because this could cause business trouble. IMHO dealing with customer accounts is very tricky because a normal user management is optimizied for collaboration and not for multi-tenant confidentiality. Ciao, Michael. From abokovoy at redhat.com Wed Feb 15 15:01:52 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Feb 2017 17:01:52 +0200 Subject: [Freeipa-users] Delegation + visibility on users/user groups In-Reply-To: References: <20170215105129.h2dy6jcbuadgmlxe@redhat.com> Message-ID: <20170215150152.lhlhv6xfbpcxmbic@redhat.com> On ke, 15 helmi 2017, Michael Str?der wrote: >On 2017-02-15 11:51, Alexander Bokovoy wrote: >>On ke, 15 helmi 2017, Gerald Zabos wrote: >>>Use case: external customer gets limited access and MUST NOT see our >>>internal users and/or other external customers. >> >>Not seeing other users or objects is no possible with FreeIPA >>design. It >>is also security through obscurity and doesn't really contribute >>anything. > >IMHO such a use-case is a valid security requirement for preventing >social engineering threats. > >Anyway customer accounts are critical regarding _confidentiality_: > >1. Customers must not see internal users and their contact data > for not being able to circumvent controlled support processes. > >2. Customers must not see other customers (competitors) because this > could cause business trouble. > >IMHO dealing with customer accounts is very tricky because a normal >user management is optimizied for collaboration and not for >multi-tenant confidentiality. You seem to assume something that is not really part of FreeIPA design. FreeIPA has flat DIT, with no OUs or other segregation means. All users and all groups are at the same level, there is no mechanism to prevent them from being invisible to each other. Additionally, it would not give you much of protection against hosts because each enrolled host can see (read-only) all users and groups. If host principals would not be able to do so, SSSD would not be able to retrieve identity information. Even if user has no control over its own enrolled machine, POSIX identity retrieval API also has no separation feature. If you are able to issue getpwnam() or getpwuid() call, you are able to methodically iterate through all POSIX attributes of all users, even inefficiently. Note FreeIPA is not alone at this. Active Directory allows all machines in the domain to query identity information even if you are not able to see it directly from LDAP. Global Catalog service also gives all users at least read-only access to whole forest's identity information. This is why I called a proposed approach to solve this use-case as security through obscurity. The API is there to readily retrieve most of the information without really involved effort. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Wed Feb 15 16:40:38 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Wed, 15 Feb 2017 17:40:38 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> Message-ID: Hi, Is there any update on this ? I need to install 3 other instances but I would like to know upfront if it might be a bug. Thanks, Matt 2017-02-14 17:59 GMT+01:00 Matt . : > Hi Florance, > > Sure I can, here you go: > > Fedora 24 > Freeipa VERSION: 4.4.2, API_VERSION: 2.215 > > I installed this server as self-signed CA > > Cheers, > > Matt > > > > > 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : >> On 02/14/2017 05:43 PM, Matt . wrote: >>> >>> Hi Florance, >>> >>> Thanks for your update, good to see some good into about it. For >>> Comodo I have install all these: >>> >>> AddTrustExternalCARoot.crt >>> COMODORSAAddTrustCA.crt >>> COMODORSADomainValidationSecureServerCA.crt >>> >>> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >>> far as I know but the same issues still exist, the Server-Cert is >>> removed again on ipa-certupdate and fails. >>> >>> I have tried this with setenforce 0 >>> >> Hi Matt, >> >> can you provide more info in order to reproduce the issue? >> - which OS are you using >> - IPA version >> - how did you install ipa server (CA-less or with self-signed CA or with >> externally-signed CA?) >> >> Thanks, >> Flo. >> >> >>> Cheers, >>> >>> Matt >>> >>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>>> >>>> On 02/14/2017 02:54 PM, Matt . wrote: >>>>> >>>>> >>>>> Certs are valid, I will check what you mentioned. >>>>> >>>>> I'm also no fan of bundles, more the seperate files but this doesn't >>>>> seem to work always. At least for the CAroot a bundle was required. >>>>> >>>> Hi Matt, >>>> >>>> if your certificate was provided by an intermediate CA, you need to add >>>> each >>>> CA before running ipa-server-certinstall (start from the top-level CA >>>> with >>>> ipa-cacert-manage install, then run ipa-certupdate, then the intermediate >>>> CA >>>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>>> >>>> There is also a known issue with ipa-certupdate and SELinux in enforcing >>>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>>> >>>> Flo. >>>> >>>> >>>>> Matt >>>>> >>>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>>> : >>>>>> >>>>>> >>>>>> Have you validated the cert (and dumped the contents) from the command >>>>>> line using the openssl tools? I?ve seen the message you are seeing >>>>>> before, >>>>>> for some reason I seem to remember that it has to do with either a >>>>>> missing >>>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>>> CERTIFICATE---- (an error from copy and pasting and not copying the >>>>>> actual >>>>>> file). >>>>>> >>>>>> I?ve never used certupdate so if what is described above doesn?t help >>>>>> somebody else will have to chime in. >>>>>> >>>>>> Dan >>>>>> >>>>>>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>>>>>> >>>>>>> Hi Dan, >>>>>>> >>>>>>> Ues i have tried that and I get the message that it misses the full >>>>>>> chain for the certificate. >>>>>>> >>>>>>> My issue is more, why is the Server-Cert being removed on a certupdate >>>>>>> ? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with the >>>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >>>>>>>>> >>>>>>>>> Hi Guys, >>>>>>>>> >>>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>>> >>>>>>>>> When I run the install command for the certificate itself: >>>>>>>>> >>>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>>> mydomain_com_bundle.crt >>>>>>>>> Directory Manager password: >>>>>>>>> >>>>>>>>> Enter private key unlock password: >>>>>>>>> >>>>>>>>> list index out of range >>>>>>>>> The ipa-server-certinstall command failed. >>>>>>>>> >>>>>>>>> >>>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>>> >>>>>>>>> What can I do to solve this ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 blanchet at abes.fr Wed Feb 15 16:58:19 2017 From: blanchet at abes.fr (=?UTF-8?Q?Nathana=c3=abl_Blanchet?=) Date: Wed, 15 Feb 2017 17:58:19 +0100 Subject: [Freeipa-users] ssh pubkeys and and AD Message-ID: <014a62dc-bd57-9de3-03f6-d2303338ea6c@abes.fr> Hi, I successfully set an active trust between my linux IPA domain and AD. I added a few AD account to id views, and I can sucessfully login to my linux machines with plain password. Now, I added my ssh pub key to these servers and I see two kinds of behaviour: * I can login with the ssh pubkey on new created account (with id view) * But on previous created account, if I first login with a password and switch to a pub key authentication, I can't login without password. * In opposite, if I remove the key to a user that sucessfully authenticated, he still can continue to login without password. I suppose it must exist a cache system, I tried to see several option in sssd.conf as |offline_credentials_expiration, ||account_cache_expiration, ||entry_cache_timeout, but nothing changes.| |Thank you for your help. | -- Nathana?l Blanchet Supervision r?seau P?le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 T?l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet at abes.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Wed Feb 15 19:13:04 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 15 Feb 2017 14:13:04 -0500 Subject: [Freeipa-users] How to change kerberos key lifetime? Message-ID: Hello We are currently mostly using RHEL 6 on the clients but IPA is on RHEL 7.3. I am using Kerberos to authenticate NFS mount and its working fine. However, there is a lot of users who are complaining that its causing too much problems. They are all related to key expiry I have looked at how to rectify this and noticed that the only solution with RHEL 6 is to increase the time the key is valid. However, it hasn't worked, the key lifetime remains a day and maximum lifetime of 7 days. These are the changes I have made so far: Changed the policy on IPA: [root at lithium ~]# ipa krbtpolicy-show Max life: 15552000 Max renew: 25552000 [root at lithium ~]# Changed kerberos configuration: [libdefaults] default_realm = ENG.EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 4320h forwardable = yes udp_preference_limit = 0 Changed sssd configurations: [domain/eng.example.com] krb5_renewable_lifetime = 180d krb5_renew_interval = 3600 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = eng.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = platinum.eng.example.com chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, lithium.eng.example.com ldap_tls_cacert = /etc/ipa/ca.crt autofs_provider = ipa ipa_automount_location = default [sssd] services = nss, sudo, pam, autofs, ssh domains = eng.example.com [nss] homedir_substring = /home None have lead to any difference as seem below. What would I be missing? Ticket cache: FILE:/tmp/krb5cc_782_L8aH9N Default principal: william at ENG.EXAMPLE.COM Valid starting Expires Service principal 02/15/17 13:17:11 02/22/17 13:17:11 krbtgt/ENG.EXAMPLE.COM at ENG.EXAMPLE.COM renew until 03/01/17 13:17:11 Regards, William From jhrozek at redhat.com Wed Feb 15 20:58:14 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 15 Feb 2017 21:58:14 +0100 Subject: [Freeipa-users] IPA and SSSD sudo In-Reply-To: <234182527.2034400.1487166258299.JavaMail.zimbra@casalogic.dk> References: <1127865287.2031429.1487153087937.JavaMail.zimbra@casalogic.dk> <20170215133846.enmjbzojmq2nmef2@hendrix> <234182527.2034400.1487166258299.JavaMail.zimbra@casalogic.dk> Message-ID: <20170215205814.q5ehut7ibv25tfti@hendrix> On Wed, Feb 15, 2017 at 02:44:18PM +0100, Troels Hansen wrote: > The same rule works as expected if defined in the local sudoers file. Then I guess this might be a bug.. > > I think the problem is that secure_path in "Options" from IPA isn't taken into account. options should be treated just as any other attribute, so more or les transparently. Could you run an ldbsearch of the database to check how was the sudo rule stored to the sssd cache? See: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO From jason at tresgeek.net Wed Feb 15 22:11:27 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 15 Feb 2017 16:11:27 -0600 (CST) Subject: [Freeipa-users] DM Password Reset in 4.4.0 Message-ID: <17407504.2209.1487196687011.JavaMail.zimbra@tresgeek.net> Hello All, I have managed to lose the Directory Manager password for my FreeIPA 4.4.0 instance. I've found the following documentation: http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html And: http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password I'm confused as to whether I need to follow the procedure in the second link because of the following note on the page: The following procedure is only applicable to FreeIPA 3.2.1 or older. Since FreeIPA 3.2.2 (and ticket #3594), the procedure is automated as a part of preparing a replica info file by using ipa-replica-prepare The wording of that seems to indicate that it is a copy/paste from a different doc on how to setup PKI (due to the reference to ipa-replica-prepare). Could someone shed some light on the proper way to go about resetting the Directory Manager password in 4.4.0? Thanks, j From dkupka at redhat.com Thu Feb 16 07:22:50 2017 From: dkupka at redhat.com (David Kupka) Date: Thu, 16 Feb 2017 08:22:50 +0100 Subject: [Freeipa-users] How to change kerberos key lifetime? In-Reply-To: References: Message-ID: <20170216072250.GA6059@dkupka.usersys.redhat.com> On Wed, Feb 15, 2017 at 02:13:04PM -0500, William Muriithi wrote: > Hello > > We are currently mostly using RHEL 6 on the clients but IPA is on RHEL > 7.3. I am using Kerberos to authenticate NFS mount and its working > fine. However, there is a lot of users who are complaining that its > causing too much problems. They are all related to key expiry > > > I have looked at how to rectify this and noticed that the only > solution with RHEL 6 is to increase the time the key is valid. > However, it hasn't worked, the key lifetime remains a day and maximum > lifetime of 7 days. > > These are the changes I have made so far: > > Changed the policy on IPA: > > [root at lithium ~]# ipa krbtpolicy-show > Max life: 15552000 > Max renew: 25552000 > [root at lithium ~]# > > > Changed kerberos configuration: > > [libdefaults] > default_realm = ENG.EXAMPLE.COM > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 4320h > forwardable = yes > udp_preference_limit = 0 > > > Changed sssd configurations: > > [domain/eng.example.com] > > krb5_renewable_lifetime = 180d > krb5_renew_interval = 3600 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = eng.example.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = platinum.eng.example.com > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, lithium.eng.example.com > ldap_tls_cacert = /etc/ipa/ca.crt > autofs_provider = ipa > ipa_automount_location = default > [sssd] > services = nss, sudo, pam, autofs, ssh > > domains = eng.example.com > [nss] > homedir_substring = /home > > None have lead to any difference as seem below. What would I be missing? > > Ticket cache: FILE:/tmp/krb5cc_782_L8aH9N > Default principal: william at ENG.EXAMPLE.COM > > Valid starting Expires Service principal > 02/15/17 13:17:11 02/22/17 13:17:11 krbtgt/ENG.EXAMPLE.COM at ENG.EXAMPLE.COM > renew until 03/01/17 13:17:11 > > Regards, > William > > -- > 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 Hello William, first you're mantioning "key expiry" but if I understand corectly you're interested in "ticket lifetime". As mentioned here [1] the ticket lifetime is the minimum of 4 values: 1) maxlife for the user principal 2) maxlife for the service [principal] 3) max_life in the kdc.conf 4) requested lifetime in the ticket request You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in [libdefaults] in /etc/krb5.conf on client). To increase 2) you need to change maxlife for krbtgt service. There're two ways this ca be done: a) modifying krbMaxTicketLife attribute in krbPrincipalName=krbtgt/EXAMPLE.ORG at EXAMPLE.ORG,cn=EXAMPLE.ORG,cn=kerberos,dc=example,dc=org b) using kadmin.local: # kadmin.local Authenticating as principal admin/admin at EXAMPLE.ORG : modprinc -maxlife 10day krbtgt/EXAMPLE.ORG Principal "krbtgt/EXAMPLE.ORG at EXAMPLE.ORG" modified. : exit To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf and restart krb5kdc service. But generally I don't think it's a good idea to have such long tickets. Would it make sense in your use case to deploy SSSD on user systems to handle Kerberos tickets for them? [1] http://mailman.mit.edu/pipermail/kerberos/2009-February/014520.html -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 16 08:28:43 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 16 Feb 2017 09:28:43 +0100 Subject: [Freeipa-users] DM Password Reset in 4.4.0 In-Reply-To: <17407504.2209.1487196687011.JavaMail.zimbra@tresgeek.net> References: <17407504.2209.1487196687011.JavaMail.zimbra@tresgeek.net> Message-ID: <4b4397dc-8784-8ddb-7afd-4ac65b2606ee@redhat.com> On 15.02.2017 23:11, Jason B. Nance wrote: > Hello All, > > I have managed to lose the Directory Manager password for my FreeIPA 4.4.0 instance. I've found the following documentation: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > > And: > > http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > I'm confused as to whether I need to follow the procedure in the second link because of the following note on the page: > > The following procedure is only applicable to FreeIPA 3.2.1 or older. Since FreeIPA 3.2.2 (and ticket #3594), the procedure is automated as a part of preparing a replica info file by using ipa-replica-prepare > > The wording of that seems to indicate that it is a copy/paste from a different doc on how to setup PKI (due to the reference to ipa-replica-prepare). > > Could someone shed some light on the proper way to go about resetting the Directory Manager password in 4.4.0? > > Thanks, > > j > Hello, "Following procedure needs to be performed on all FreeIPA replicas with PKI." and see Prerequisites if you have 3.2.1 and older with CA installed you should use this steps, otherwise you need only change DM password as is stated in Dirsrv documentation. Martin From flo at redhat.com Thu Feb 16 10:17:08 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 16 Feb 2017 11:17:08 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> Message-ID: On 02/15/2017 05:40 PM, Matt . wrote: > Hi, > > Is there any update on this ? I need to install 3 other instances but > I would like to know upfront if it might be a bug. > Hi Matt, I was not able to reproduce your issue. Here were my steps: Install FreeIPA with self-signed cert: ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD The certificate chain is ca1 -> subca -> server. Install the root CA: kinit admin ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem ipa-certupdate Install the subca: ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem ipa-certupdate Install the server cert: ipa-server-certinstall -d -w server.pem key.pem ipa-certupdate basically retrieves the certificates from LDAP (below cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias but I don't remember it removing certs. Can you check the content of your LDAP server? kinit admin ldapsearch -h `hostname` -p 389 -Y GSSAPI -b cn=certificates,cn=ipa,cn=etc,$BASEDN It should contain one entry for each CA that you added. Flo. > Thanks, > > Matt > > 2017-02-14 17:59 GMT+01:00 Matt . : >> Hi Florance, >> >> Sure I can, here you go: >> >> Fedora 24 >> Freeipa VERSION: 4.4.2, API_VERSION: 2.215 >> >> I installed this server as self-signed CA >> >> Cheers, >> >> Matt >> >> >> >> >> 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : >>> On 02/14/2017 05:43 PM, Matt . wrote: >>>> >>>> Hi Florance, >>>> >>>> Thanks for your update, good to see some good into about it. For >>>> Comodo I have install all these: >>>> >>>> AddTrustExternalCARoot.crt >>>> COMODORSAAddTrustCA.crt >>>> COMODORSADomainValidationSecureServerCA.crt >>>> >>>> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >>>> far as I know but the same issues still exist, the Server-Cert is >>>> removed again on ipa-certupdate and fails. >>>> >>>> I have tried this with setenforce 0 >>>> >>> Hi Matt, >>> >>> can you provide more info in order to reproduce the issue? >>> - which OS are you using >>> - IPA version >>> - how did you install ipa server (CA-less or with self-signed CA or with >>> externally-signed CA?) >>> >>> Thanks, >>> Flo. >>> >>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>>>> >>>>> On 02/14/2017 02:54 PM, Matt . wrote: >>>>>> >>>>>> >>>>>> Certs are valid, I will check what you mentioned. >>>>>> >>>>>> I'm also no fan of bundles, more the seperate files but this doesn't >>>>>> seem to work always. At least for the CAroot a bundle was required. >>>>>> >>>>> Hi Matt, >>>>> >>>>> if your certificate was provided by an intermediate CA, you need to add >>>>> each >>>>> CA before running ipa-server-certinstall (start from the top-level CA >>>>> with >>>>> ipa-cacert-manage install, then run ipa-certupdate, then the intermediate >>>>> CA >>>>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>>>> >>>>> There is also a known issue with ipa-certupdate and SELinux in enforcing >>>>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>>>> >>>>> Flo. >>>>> >>>>> >>>>>> Matt >>>>>> >>>>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>>>> : >>>>>>> >>>>>>> >>>>>>> Have you validated the cert (and dumped the contents) from the command >>>>>>> line using the openssl tools? I?ve seen the message you are seeing >>>>>>> before, >>>>>>> for some reason I seem to remember that it has to do with either a >>>>>>> missing >>>>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>>>> CERTIFICATE---- (an error from copy and pasting and not copying the >>>>>>> actual >>>>>>> file). >>>>>>> >>>>>>> I?ve never used certupdate so if what is described above doesn?t help >>>>>>> somebody else will have to chime in. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>>>>>>> >>>>>>>> Hi Dan, >>>>>>>> >>>>>>>> Ues i have tried that and I get the message that it misses the full >>>>>>>> chain for the certificate. >>>>>>>> >>>>>>>> My issue is more, why is the Server-Cert being removed on a certupdate >>>>>>>> ? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with the >>>>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . wrote: >>>>>>>>>> >>>>>>>>>> Hi Guys, >>>>>>>>>> >>>>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>>>> >>>>>>>>>> When I run the install command for the certificate itself: >>>>>>>>>> >>>>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>>>> mydomain_com_bundle.crt >>>>>>>>>> Directory Manager password: >>>>>>>>>> >>>>>>>>>> Enter private key unlock password: >>>>>>>>>> >>>>>>>>>> list index out of range >>>>>>>>>> The ipa-server-certinstall command failed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>>>> >>>>>>>>>> What can I do to solve this ? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 t.ruiten at rdmedia.com Thu Feb 16 12:32:40 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 16 Feb 2017 13:32:40 +0100 Subject: [Freeipa-users] how to resolve replication conflicts Message-ID: Hello, I have a FreeIPA setup in which some masters suffered from a few uncontrolled shutdowns and now there are replication conflicts (which prevent from setting the Domain Level to 1). I was trying to follow the instructions here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html But unfortunately I'm not getting anywhere. This the result of an ldapsearch for replication conflicts: > [root at moscovium ~]# ldapsearch -x -D "cn=directory manager" -W -b > "dc=ipa,dc=rdmedia,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: nsds5ReplConflict=* > # requesting: * nsds5ReplConflict > # > # servers + 334bfc53-cdae11e6-8a85a70a-bda98fae, dns, ipa.rdmedia.com > dn: > cn=servers+nsuniqueid=334bfc53-cdae11e6-8a85a70a-bda98fae,cn=dns,dc=ipa,dc > =rdmedia,dc=com > objectClass: nsContainer > objectClass: top > cn: servers > nsds5ReplConflict: namingConflict > cn=servers,cn=dns,dc=ipa,dc=rdmedia,dc=com > # System: Add CA + 334bfbe5-cdae11e6-8a85a70a-bda98fae, permissions, pbac, > ipa. > rdmedia.com > dn: cn=System: Add > CA+nsuniqueid=334bfbe5-cdae11e6-8a85a70a-bda98fae,cn=permis > sions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: add > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Add CA > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=CA Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: add > ca,cn=permissions,cn=pbac,dc= > ipa,dc=rdmedia,dc=com # System: Delete CA + 334bfbe9-cdae11e6-8a85a70a-bda98fae, permissions, > pbac, i > pa.rdmedia.com > dn: cn=System: Delete > CA+nsuniqueid=334bfbe9-cdae11e6-8a85a70a-bda98fae,cn=per > missions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: delete > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Delete CA > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=CA Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: delete > ca,cn=permissions,cn=pbac, > dc=ipa,dc=rdmedia,dc=com > # System: Modify CA + 334bfbed-cdae11e6-8a85a70a-bda98fae, permissions, > pbac, i > pa.rdmedia.com > dn: cn=System: Modify > CA+nsuniqueid=334bfbed-cdae11e6-8a85a70a-bda98fae,cn=per > missions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Modify CA > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=CA Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: description > ipaPermDefaultAttr: cn > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: modify > ca,cn=permissions,cn=pbac, > dc=ipa,dc=rdmedia,dc=com > # System: Read CAs + 334bfbf1-cdae11e6-8a85a70a-bda98fae, permissions, > pbac, ip > a.rdmedia.com > dn: cn=System: Read > CAs+nsuniqueid=334bfbf1-cdae11e6-8a85a70a-bda98fae,cn=perm > issions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: all > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read CAs > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > ipaPermDefaultAttr: description > ipaPermDefaultAttr: ipacaissuerdn > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: ipacasubjectdn > ipaPermDefaultAttr: ipacaid > ipaPermDefaultAttr: cn > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read > cas,cn=permissions,cn=pbac,d > c=ipa,dc=rdmedia,dc=com > # System: Modify DNS Servers Configuration + > 334bfbf6-cdae11e6-8a85a70a-bda98fa > e, permissions, pbac, ipa.rdmedia.com > dn: cn=System: Modify DNS Servers > Configuration+nsuniqueid=334bfbf6-cdae11e6-8 > a85a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=idnsServerConfigObject) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Modify DNS Servers Configuration > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: idnssoamname > ipaPermDefaultAttr: idnssubstitutionvariable > ipaPermDefaultAttr: idnsforwardpolicy > ipaPermDefaultAttr: idnsforwarders > ipaPermLocation: dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: modify dns servers > configuration, > cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read DNS Servers Configuration + > 334bfbfa-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, ipa.rdmedia.com > dn: cn=System: Read DNS Servers > Configuration+nsuniqueid=334bfbfa-cdae11e6-8a8 > 5a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=idnsServerConfigObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read DNS Servers Configuration > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > member: cn=DNS Servers,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: idnsforwardpolicy > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: idnsforwarders > ipaPermDefaultAttr: idnsserverid > ipaPermDefaultAttr: idnssubstitutionvariable > ipaPermDefaultAttr: idnssoamname > ipaPermLocation: dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read dns servers > configuration,cn > =permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Manage Host Principals + 334bfc0b-cdae11e6-8a85a70a-bda98fae, > permiss > ions, pbac, ipa.rdmedia.com > dn: cn=System: Manage Host > Principals+nsuniqueid=334bfc0b-cdae11e6-8a85a70a-bd > a98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipahost) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Manage Host Principals > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=Host > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > member: cn=Host Enrollment,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: krbprincipalname > ipaPermDefaultAttr: krbcanonicalname > ipaPermLocation: cn=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: manage host > principals,cn=permiss > ions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Add IPA Locations + 334bfc20-cdae11e6-8a85a70a-bda98fae, > permissions, > pbac, ipa.rdmedia.com > dn: cn=System: Add IPA > Locations+nsuniqueid=334bfc20-cdae11e6-8a85a70a-bda98fa > e,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: add > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Add IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: add ipa > locations,cn=permissions, > cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Modify IPA Locations + 334bfc24-cdae11e6-8a85a70a-bda98fae, > permissio > ns, pbac, ipa.rdmedia.com > dn: cn=System: Modify IPA > Locations+nsuniqueid=334bfc24-cdae11e6-8a85a70a-bda9 > 8fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Modify IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: description > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: modify ipa > locations,cn=permissio > ns,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read IPA Locations + 334bfc28-cdae11e6-8a85a70a-bda98fae, > permissions > , pbac, ipa.rdmedia.com > dn: cn=System: Read IPA > Locations+nsuniqueid=334bfc28-cdae11e6-8a85a70a-bda98f > ae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: description > ipaPermDefaultAttr: idnsname > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read ipa > locations,cn=permissions > ,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Remove IPA Locations + 334bfc2c-cdae11e6-8a85a70a-bda98fae, > permissio > ns, pbac, ipa.rdmedia.com > dn: cn=System: Remove IPA > Locations+nsuniqueid=334bfc2c-cdae11e6-8a85a70a-bda9 > 8fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: delete > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Remove IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: remove ipa > locations,cn=permissio > ns,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read Locations of IPA Servers + > 334bfc30-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, ipa.rdmedia.com > dn: cn=System: Read Locations of IPA > Servers+nsuniqueid=334bfc30-cdae11e6-8a85 > a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaConfigObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read Locations of IPA Servers > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: ipaserviceweight > ipaPermDefaultAttr: ipalocation > ipaPermDefaultAttr: cn > ipaPermLocation: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read locations of ipa > servers,cn= > permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read Status of Services on IPA Servers + > 334bfc34-cdae11e6-8a85a70a-b > da98fae, permissions, pbac, ipa.rdmedia.com > dn: cn=System: Read Status of Services on IPA > Servers+nsuniqueid=334bfc34-cdae > 11e6-8a85a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaConfigObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read Status of Services on IPA Servers > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: ipaconfigstring > ipaPermDefaultAttr: cn > ipaPermLocation: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read status of services on > ipa se > rvers,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Manage Service Principals + 334bfc38-cdae11e6-8a85a70a-bda98fae, > perm > issions, pbac, ipa.rdmedia.com > dn: cn=System: Manage Service > Principals+nsuniqueid=334bfc38-cdae11e6-8a85a70a > -bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaservice) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Manage Service Principals > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=Service > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=c > om > ipaPermDefaultAttr: krbprincipalname > ipaPermDefaultAttr: krbcanonicalname > ipaPermLocation: cn=services,cn=accounts,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: manage service > principals,cn=perm > issions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Manage User Principals + 334bfc45-cdae11e6-8a85a70a-bda98fae, > permiss > ions, pbac, ipa.rdmedia.com > dn: cn=System: Manage User > Principals+nsuniqueid=334bfc45-cdae11e6-8a85a70a-bd > a98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=posixaccount) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Manage User Principals > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=User > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > member: cn=Modify Users and Reset > passwords,cn=privileges,cn=pbac,dc=ipa,dc=rd > media,dc=com > ipaPermDefaultAttr: krbprincipalname > ipaPermDefaultAttr: krbcanonicalname > ipaPermLocation: cn=users,cn=accounts,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: manage user > principals,cn=permiss > ions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # locations + 334bfba2-cdae11e6-8a85a70a-bda98fae, etc, ipa.rdmedia.com > dn: > cn=locations+nsuniqueid=334bfba2-cdae11e6-8a85a70a-bda98fae,cn=etc,dc=ipa, > dc=rdmedia,dc=com > objectClass: nsContainer > objectClass: top > cn: locations > nsds5ReplConflict: namingConflict > cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > aci: (targetfilter = "(objectclass=ipaLocationObject)")(version 3.0;acl > "permi > ssion:System: Add IPA Locations";allow (add) groupdn = > "ldap:///cn=System: Ad > d IPA Locations,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "description")(targetfilter = > "(objectclass=ipaLocationObje > ct)")(version 3.0;acl "permission:System: Modify IPA Locations";allow > (write) > groupdn = "ldap:///cn=System: Modify IPA > Locations,cn=permissions,cn=pbac,dc > =ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "createtimestamp || description || entryusn || idnsname > || > modifytimestamp || objectclass")(targetfilter = > "(objectclass=ipaLocationObje > ct)")(version 3.0;acl "permission:System: Read IPA Locations";allow > (compare, > read,search) groupdn = "ldap:///cn=System: Read IPA > Locations,cn=permissions, > cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetfilter = "(objectclass=ipaLocationObject)")(version 3.0;acl > "permi > ssion:System: Remove IPA Locations";allow (delete) groupdn = > "ldap:///cn=Syst > em: Remove IPA > Locations,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > # neon.ipa.rdmedia.com + 1b780d06-017611e6-966aeb96-de53d9d8, computers, > accoun > ts, ipa.rdmedia.com > dn: fqdn=neon.ipa.rdmedia.com > +nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,c > n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com > krbExtraData:: > AAJIQA5XaG9zdC9uZW9uLmlwYS5yZG1lZGlhLmNvbUBJUEEuUkRNRURJQS5DT00 > A > enrolledBy: uid=admin,cn=users,cn=accounts,dc=ipa,dc=rdmedia,dc=com > krbLastPwdChange: 20160413124912Z > krbPrincipalKey:: > MIIBKKADAgEBoQMCAQGiAwIBAaMDAgEBpIIBEDCCAQwwS6FJMEegAwIBEqFA > > BD4gAPd2yVptQC/d3mk7xdb3skL+KkkUzewAxCF0FJgXXuBVt1y2GHtnhzILNe91amjovgXAFEujn > > 8x6YrwHXDA7oTkwN6ADAgERoTAELhAAPbI3gwakFyt9EnCqDLWst6FeXKO0Fwvx3+gZZOGmYQpr0Z > > ujLLtmJuJVmS8wQ6FBMD+gAwIBEKE4BDYYABMJXEKVH2Yn4nGzJ5woqDjO2dVUx8nQ+1NSi6dREwy > > 8T+7VrbdVOpaQgkUx4czwkhxKvVcwO6E5MDegAwIBF6EwBC4QABWhTKkWc50oJlpSw/FK2yhl+ZUo > MZt0XHA/xdPXDD3DxGV5cx2MgvJEhJzs > cn: neon.ipa.rdmedia.com > objectClass: ipaobject > objectClass: ieee802device > objectClass: nshost > objectClass: ipaservice > objectClass: pkiuser > objectClass: ipahost > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: ipasshhost > objectClass: top > objectClass: ipaSshGroupOfPubKeys > fqdn: neon.ipa.rdmedia.com > managedBy: fqdn=neon.ipa.rdmedia.com > ,cn=computers,cn=accounts,dc=ipa,dc=rdmedi > a,dc=com > krbPrincipalName: host/neon.ipa.rdmedia.com at IPA.RDMEDIA.COM > serverHostName: neon > ipaUniqueID: 1eaa355c-0176-11e6-8dd5-001a4aa7101c > krbPwdPolicyReference: cn=Default Host Password > Policy,cn=computers,cn=account > s,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict fqdn=neon.ipa.rdmedia.com > ,cn=computers,cn=ac > counts,dc=ipa,dc=rdmedia,dc=com > # cas + 334bfba8-cdae11e6-8a85a70a-bda98fae, ca, ipa.rdmedia.com > dn: > cn=cas+nsuniqueid=334bfba8-cdae11e6-8a85a70a-bda98fae,cn=ca,dc=ipa,dc=rdme > dia,dc=com > objectClass: nsContainer > objectClass: top > cn: cas > nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl > "permission:System > : Add CA";allow (add) groupdn = "ldap:///cn=System: Add > CA,cn=permissions,cn= > pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl > "permission:System > : Delete CA";allow (delete) groupdn = "ldap:///cn=System: Delete > CA,cn=permis > sions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "cn || description")(targetfilter = > "(objectclass=ipaca)")( > version 3.0;acl "permission:System: Modify CA";allow (write) groupdn = > "ldap: > ///cn=System: Modify CA,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "cn || createtimestamp || description || entryusn || > ipacai > d || ipacaissuerdn || ipacasubjectdn || modifytimestamp || > objectclass")(targ > etfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System: > Read CA > s";allow (compare,read,search) userdn = "ldap:///all";) > # custodia + 334bfbdb-cdae11e6-8a85a70a-bda98fae, ipa, etc, > ipa.rdmedia.com > dn: > cn=custodia+nsuniqueid=334bfbdb-cdae11e6-8a85a70a-bda98fae,cn=ipa,cn=etc,d > c=ipa,dc=rdmedia,dc=com > objectClass: nsContainer > objectClass: top > cn: custodia > nsds5ReplConflict: namingConflict > cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=rdmedia, > dc=com > # domain + 334bfb9e-cdae11e6-8a85a70a-bda98fae, topology, ipa, etc, > ipa.rdmedia > .com > dn: > cn=domain+nsuniqueid=334bfb9e-cdae11e6-8a85a70a-bda98fae,cn=topology,cn=ip > a,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplicaStripAttrs: modifiersName modifyTimestamp > internalModifiersName in > ternalModifyTimestamp > ipaReplTopoConfRoot: dc=ipa,dc=rdmedia,dc=com > objectClass: top > objectClass: iparepltopoconf > nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn > krblasts > uccessfulauth krblastfailedauth krbloginfailedcount > nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof > idnssoaserial > entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount > cn: domain > nsds5ReplConflict: namingConflict > cn=domain,cn=topology,cn=ipa,cn=etc,dc=ipa,d > c=rdmedia,dc=com > # ca + 334bfbe0-cdae11e6-8a85a70a-bda98fae, topology, ipa, etc, > ipa.rdmedia.com > dn: > cn=ca+nsuniqueid=334bfbe0-cdae11e6-8a85a70a-bda98fae,cn=topology,cn=ipa,cn > =etc,dc=ipa,dc=rdmedia,dc=com > objectClass: top > objectClass: iparepltopoconf > cn: ca > ipaReplTopoConfRoot: o=ipaca > nsds5ReplConflict: namingConflict > cn=ca,cn=topology,cn=ipa,cn=etc,dc=ipa,dc=rd > media,dc=com > # dogtag + 334bfbdd-cdae11e6-8a85a70a-bda98fae, custodia + > 334bfbdb-cdae11e6-8a > 85a70a-bda98fae, ipa, etc, ipa.rdmedia.com > dn: > cn=dogtag+nsuniqueid=334bfbdd-cdae11e6-8a85a70a-bda98fae,cn=custodia+nsuni > > queid=334bfbdb-cdae11e6-8a85a70a-bda98fae,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc= > com > objectClass: nsContainer > objectClass: top > cn: dogtag > nsds5ReplConflict: namingConflict > cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=ipa,d > c=rdmedia,dc=com > # lawrencium + 6c7e3d83-c11711e6-8a85a70a-bda98fae, ipa.rdmedia.com., > dns, ipa. > rdmedia.com > dn: > idnsName=lawrencium+nsuniqueid=6c7e3d83-c11711e6-8a85a70a-bda98fae,idnsnam > e=ipa.rdmedia.com.,cn=dns,dc=ipa,dc=rdmedia,dc=com > aRecord: 192.168.50.55 > dNSTTL: 1200 > objectClass: idnsRecord > objectClass: top > idnsName: lawrencium > nsds5ReplConflict: namingConflict idnsname=lawrencium,idnsname= > ipa.rdmedia.com > .,cn=dns,dc=ipa,dc=rdmedia,dc=com > # mendelevium + e5710f85-c5c511e6-8a85a70a-bda98fae, ipa.rdmedia.com., > dns, ipa > .rdmedia.com > dn: > idnsName=mendelevium+nsuniqueid=e5710f85-c5c511e6-8a85a70a-bda98fae,idnsna > me=ipa.rdmedia.com.,cn=dns,dc=ipa,dc=rdmedia,dc=com > aRecord: 192.168.50.52 > dNSTTL: 1200 > objectClass: idnsRecord > objectClass: top > idnsName: mendelevium > nsds5ReplConflict: namingConflict idnsname=mendelevium,idnsname= > ipa.rdmedia.co > m.,cn=dns,dc=ipa,dc=rdmedia,dc=com > # 41 + e764de07-5e2f11e6-bd76eb96-de53d9d8, 120.100.10.in-addr.arpa., dns, > ipa. > rdmedia.com > dn: > idnsname=41+nsuniqueid=e764de07-5e2f11e6-bd76eb96-de53d9d8,idnsname=120.10 > 0.10.in-addr.arpa.,cn=dns,dc=ipa,dc=rdmedia,dc=com > objectClass: top > objectClass: idnsrecord > pTRRecord: arsenica.ipa.rdmedia.com. > idnsName: 41 > nsds5ReplConflict: namingConflict > idnsname=41,idnsname=120.100.10.in-addr.arpa > .,cn=dns,dc=ipa,dc=rdmedia,dc=com > # ipa + 58d90aec-cdae11e6-8a85a70a-bda98fae, cas + > 334bfba8-cdae11e6-8a85a70a-b > da98fae, ca, ipa.rdmedia.com > dn: > cn=ipa+nsuniqueid=58d90aec-cdae11e6-8a85a70a-bda98fae,cn=cas+nsuniqueid=33 > 4bfba8-cdae11e6-8a85a70a-bda98fae,cn=ca,dc=ipa,dc=rdmedia,dc=com > description: IPA CA > ipaCaIssuerDN: CN=Certificate Authority,O=IPA.RDMEDIA.COM > objectClass: top > objectClass: ipaca > ipaCaSubjectDN: CN=Certificate Authority,O=IPA.RDMEDIA.COM > ipaCaId: 21547c03-13c3-4f4f-992b-b0257012d1c1 > cn: ipa > nsds5ReplConflict: namingConflict > cn=ipa,cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > # search result > search: 2 > result: 0 Success > # numResponses: 28 > # numEntries: 27 So when I try eg. this... [root at moscovium ~]# ldapmodify -x -D "cn=directory manager" -W -h > moscovium.ipa.rdmedia.com -p 389 > Enter LDAP Password: > dn: fqdn=neon.ipa.rdmedia.com > +nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,c > n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com > changetype: modrdn > newrdn fqdn=neontemp.ipa.rdmedia.com > deleteoldrdn: 0 ...I get: ldapmodify: invalid format (line 3) entry: "fqdn=neon.ipa.rdmedia.com > +nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,cn=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com" So my question: what can I do to resolve the conflicts? -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Thu Feb 16 12:54:47 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 16 Feb 2017 07:54:47 -0500 Subject: [Freeipa-users] How to change kerberos key lifetime? In-Reply-To: <20170216072250.GA6059@dkupka.usersys.redhat.com> References: <20170216072250.GA6059@dkupka.usersys.redhat.com> Message-ID: Morning David, Thank you very much for your help. > first you're mentioning "key expiry" but if I understand correctly you're > interested in "ticket lifetime". Yes, want to increase ticket lifetime. > > As mentioned here [1] the ticket lifetime is the minimum of 4 values: > 1) maxlife for the user principal > 2) maxlife for the service [principal] > 3) max_life in the kdc.conf > 4) requested lifetime in the ticket request > > You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in > [libdefaults] in /etc/krb5.conf on client). > > To increase 2) you need to change maxlife for krbtgt service. There're two ways > this ca be done: > a) modifying krbMaxTicketLife attribute in > krbPrincipalName=krbtgt/EXAMPLE.ORG at EXAMPLE.ORG,cn=EXAMPLE.ORG,cn=kerberos,dc=example,dc=org > b) using kadmin.local: > # kadmin.local > Authenticating as principal admin/admin at EXAMPLE.ORG > : modprinc -maxlife 10day krbtgt/EXAMPLE.ORG > Principal "krbtgt/EXAMPLE.ORG at EXAMPLE.ORG" modified. > : exit Will try 2 b and see how it goes > > To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf > and restart krb5kdc service. > okay, wasn't actually aware of this. Will look at it > But generally I don't think it's a good idea to have such long tickets. Would > it make sense in your use case to deploy SSSD on user systems to handle > Kerberos tickets for them? > I am actually using SSSD on all the systems, even the desktops. I agree the changes above aren't ideal and would prefer to get SSSD working well. Where would like to avoid this error showing around every 12 hours. antimony: Could not chdir to home directory /home/william: Key has expired Regards, William From lkrispen at redhat.com Thu Feb 16 12:58:42 2017 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 16 Feb 2017 13:58:42 +0100 Subject: [Freeipa-users] how to resolve replication conflicts In-Reply-To: References: Message-ID: <58A5A202.2040703@redhat.com> On 02/16/2017 01:32 PM, Tiemen Ruiten wrote: > Hello, > > I have a FreeIPA setup in which some masters suffered from a few > uncontrolled shutdowns and now there are replication conflicts (which > prevent from setting the Domain Level to 1). > > I was trying to follow the instructions here: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html > > But unfortunately I'm not getting anywhere. This the result of an > ldapsearch for replication conflicts: > > > [root at moscovium ~]# ldapsearch -x -D "cn=directory manager" -W -b > "dc=ipa,dc=rdmedia,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: nsds5ReplConflict=* > # requesting: * nsds5ReplConflict > # > # servers + 334bfc53-cdae11e6-8a85a70a-bda98fae, dns, > ipa.rdmedia.com > dn: > cn=servers+nsuniqueid=334bfc53-cdae11e6-8a85a70a-bda98fae,cn=dns,dc=ipa,dc > =rdmedia,dc=com > objectClass: nsContainer > objectClass: top > cn: servers > nsds5ReplConflict: namingConflict > cn=servers,cn=dns,dc=ipa,dc=rdmedia,dc=com > # System: Add CA + 334bfbe5-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, ipa. > rdmedia.com > dn: cn=System: Add > CA+nsuniqueid=334bfbe5-cdae11e6-8a85a70a-bda98fae,cn=permis > sions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: add > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Add CA > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=CA > Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: add > ca,cn=permissions,cn=pbac,dc= > ipa,dc=rdmedia,dc=com > > # System: Delete CA + 334bfbe9-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, i > pa.rdmedia.com > dn: cn=System: Delete > CA+nsuniqueid=334bfbe9-cdae11e6-8a85a70a-bda98fae,cn=per > missions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: delete > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Delete CA > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=CA > Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: delete > ca,cn=permissions,cn=pbac, > dc=ipa,dc=rdmedia,dc=com > # System: Modify CA + 334bfbed-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, i > pa.rdmedia.com > dn: cn=System: Modify > CA+nsuniqueid=334bfbed-cdae11e6-8a85a70a-bda98fae,cn=per > missions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Modify CA > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=CA > Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: description > ipaPermDefaultAttr: cn > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: modify > ca,cn=permissions,cn=pbac, > dc=ipa,dc=rdmedia,dc=com > # System: Read CAs + 334bfbf1-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, ip > a.rdmedia.com > dn: cn=System: Read > CAs+nsuniqueid=334bfbf1-cdae11e6-8a85a70a-bda98fae,cn=perm > issions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaca) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: all > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read CAs > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > ipaPermDefaultAttr: description > ipaPermDefaultAttr: ipacaissuerdn > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: ipacasubjectdn > ipaPermDefaultAttr: ipacaid > ipaPermDefaultAttr: cn > ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read > cas,cn=permissions,cn=pbac,d > c=ipa,dc=rdmedia,dc=com > # System: Modify DNS Servers Configuration + > 334bfbf6-cdae11e6-8a85a70a-bda98fa > e, permissions, pbac, ipa.rdmedia.com > dn: cn=System: Modify DNS Servers > Configuration+nsuniqueid=334bfbf6-cdae11e6-8 > a85a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=idnsServerConfigObject) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Modify DNS Servers Configuration > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: idnssoamname > ipaPermDefaultAttr: idnssubstitutionvariable > ipaPermDefaultAttr: idnsforwardpolicy > ipaPermDefaultAttr: idnsforwarders > ipaPermLocation: dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: modify dns servers > configuration, > cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read DNS Servers Configuration + > 334bfbfa-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, ipa.rdmedia.com > dn: cn=System: Read DNS Servers > Configuration+nsuniqueid=334bfbfa-cdae11e6-8a8 > 5a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=idnsServerConfigObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read DNS Servers Configuration > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > member: cn=DNS Servers,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: idnsforwardpolicy > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: idnsforwarders > ipaPermDefaultAttr: idnsserverid > ipaPermDefaultAttr: idnssubstitutionvariable > ipaPermDefaultAttr: idnssoamname > ipaPermLocation: dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read dns servers > configuration,cn > =permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Manage Host Principals + > 334bfc0b-cdae11e6-8a85a70a-bda98fae, permiss > ions, pbac, ipa.rdmedia.com > dn: cn=System: Manage Host > Principals+nsuniqueid=334bfc0b-cdae11e6-8a85a70a-bd > a98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipahost) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Manage Host Principals > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=Host > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > member: cn=Host > Enrollment,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: krbprincipalname > ipaPermDefaultAttr: krbcanonicalname > ipaPermLocation: cn=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: manage host > principals,cn=permiss > ions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Add IPA Locations + 334bfc20-cdae11e6-8a85a70a-bda98fae, > permissions, > pbac, ipa.rdmedia.com > dn: cn=System: Add IPA > Locations+nsuniqueid=334bfc20-cdae11e6-8a85a70a-bda98fa > e,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: add > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Add IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: add ipa > locations,cn=permissions, > cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Modify IPA Locations + > 334bfc24-cdae11e6-8a85a70a-bda98fae, permissio > ns, pbac, ipa.rdmedia.com > dn: cn=System: Modify IPA > Locations+nsuniqueid=334bfc24-cdae11e6-8a85a70a-bda9 > 8fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Modify IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: description > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: modify ipa > locations,cn=permissio > ns,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read IPA Locations + > 334bfc28-cdae11e6-8a85a70a-bda98fae, permissions > , pbac, ipa.rdmedia.com > dn: cn=System: Read IPA > Locations+nsuniqueid=334bfc28-cdae11e6-8a85a70a-bda98f > ae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: description > ipaPermDefaultAttr: idnsname > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read ipa > locations,cn=permissions > ,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Remove IPA Locations + > 334bfc2c-cdae11e6-8a85a70a-bda98fae, permissio > ns, pbac, ipa.rdmedia.com > dn: cn=System: Remove IPA > Locations+nsuniqueid=334bfc2c-cdae11e6-8a85a70a-bda9 > 8fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaLocationObject) > ipaPermRight: delete > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Remove IPA Locations > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: remove ipa > locations,cn=permissio > ns,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read Locations of IPA Servers + > 334bfc30-cdae11e6-8a85a70a-bda98fae, > permissions, pbac, ipa.rdmedia.com > dn: cn=System: Read Locations of IPA > Servers+nsuniqueid=334bfc30-cdae11e6-8a85 > a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaConfigObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read Locations of IPA Servers > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: ipaserviceweight > ipaPermDefaultAttr: ipalocation > ipaPermDefaultAttr: cn > ipaPermLocation: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read locations of ipa > servers,cn= > permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Read Status of Services on IPA Servers + > 334bfc34-cdae11e6-8a85a70a-b > da98fae, permissions, pbac, ipa.rdmedia.com > dn: cn=System: Read Status of Services on IPA > Servers+nsuniqueid=334bfc34-cdae > 11e6-8a85a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaConfigObject) > ipaPermRight: read > ipaPermRight: compare > ipaPermRight: search > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Read Status of Services on IPA Servers > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=DNS > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermDefaultAttr: objectclass > ipaPermDefaultAttr: ipaconfigstring > ipaPermDefaultAttr: cn > ipaPermLocation: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: read status of > services on ipa se > rvers,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Manage Service Principals + > 334bfc38-cdae11e6-8a85a70a-bda98fae, perm > issions, pbac, ipa.rdmedia.com > dn: cn=System: Manage Service > Principals+nsuniqueid=334bfc38-cdae11e6-8a85a70a > -bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=ipaservice) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Manage Service Principals > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=Service > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=c > om > ipaPermDefaultAttr: krbprincipalname > ipaPermDefaultAttr: krbcanonicalname > ipaPermLocation: cn=services,cn=accounts,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: manage service > principals,cn=perm > issions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # System: Manage User Principals + > 334bfc45-cdae11e6-8a85a70a-bda98fae, permiss > ions, pbac, ipa.rdmedia.com > dn: cn=System: Manage User > Principals+nsuniqueid=334bfc45-cdae11e6-8a85a70a-bd > a98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > ipaPermTargetFilter: (objectclass=posixaccount) > ipaPermRight: write > ipaPermBindRuleType: permission > ipaPermissionType: V2 > ipaPermissionType: MANAGED > ipaPermissionType: SYSTEM > cn: System: Manage User Principals > objectClass: ipapermission > objectClass: top > objectClass: groupofnames > objectClass: ipapermissionv2 > member: cn=User > Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com > member: cn=Modify Users and Reset > passwords,cn=privileges,cn=pbac,dc=ipa,dc=rd > media,dc=com > ipaPermDefaultAttr: krbprincipalname > ipaPermDefaultAttr: krbcanonicalname > ipaPermLocation: cn=users,cn=accounts,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict cn=system: manage user > principals,cn=permiss > ions,cn=pbac,dc=ipa,dc=rdmedia,dc=com > # locations + 334bfba2-cdae11e6-8a85a70a-bda98fae, etc, > ipa.rdmedia.com > dn: > cn=locations+nsuniqueid=334bfba2-cdae11e6-8a85a70a-bda98fae,cn=etc,dc=ipa, > dc=rdmedia,dc=com > objectClass: nsContainer > objectClass: top > cn: locations > nsds5ReplConflict: namingConflict > cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com > aci: (targetfilter = "(objectclass=ipaLocationObject)")(version > 3.0;acl "permi > ssion:System: Add IPA Locations";allow (add) groupdn = > "ldap:///cn=System: Ad > d IPA Locations,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "description")(targetfilter = > "(objectclass=ipaLocationObje > ct)")(version 3.0;acl "permission:System: Modify IPA > Locations";allow (write) > groupdn = "ldap:///cn=System: Modify IPA > Locations,cn=permissions,cn=pbac,dc > =ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "createtimestamp || description || entryusn || > idnsname || > modifytimestamp || objectclass")(targetfilter = > "(objectclass=ipaLocationObje > ct)")(version 3.0;acl "permission:System: Read IPA > Locations";allow (compare, > read,search) groupdn = "ldap:///cn=System: Read IPA > Locations,cn=permissions, > cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetfilter = "(objectclass=ipaLocationObject)")(version > 3.0;acl "permi > ssion:System: Remove IPA Locations";allow (delete) groupdn = > "ldap:///cn=Syst > em: Remove IPA > Locations,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > # neon.ipa.rdmedia.com + > 1b780d06-017611e6-966aeb96-de53d9d8, computers, accoun > ts, ipa.rdmedia.com > dn: fqdn=neon.ipa.rdmedia.com > +nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,c > n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com > krbExtraData:: > AAJIQA5XaG9zdC9uZW9uLmlwYS5yZG1lZGlhLmNvbUBJUEEuUkRNRURJQS5DT00 > A > enrolledBy: uid=admin,cn=users,cn=accounts,dc=ipa,dc=rdmedia,dc=com > krbLastPwdChange: 20160413124912Z > krbPrincipalKey:: > MIIBKKADAgEBoQMCAQGiAwIBAaMDAgEBpIIBEDCCAQwwS6FJMEegAwIBEqFA > BD4gAPd2yVptQC/d3mk7xdb3skL+KkkUzewAxCF0FJgXXuBVt1y2GHtnhzILNe91amjovgXAFEujn > 8x6YrwHXDA7oTkwN6ADAgERoTAELhAAPbI3gwakFyt9EnCqDLWst6FeXKO0Fwvx3+gZZOGmYQpr0Z > ujLLtmJuJVmS8wQ6FBMD+gAwIBEKE4BDYYABMJXEKVH2Yn4nGzJ5woqDjO2dVUx8nQ+1NSi6dREwy > 8T+7VrbdVOpaQgkUx4czwkhxKvVcwO6E5MDegAwIBF6EwBC4QABWhTKkWc50oJlpSw/FK2yhl+ZUo > MZt0XHA/xdPXDD3DxGV5cx2MgvJEhJzs > cn: neon.ipa.rdmedia.com > objectClass: ipaobject > objectClass: ieee802device > objectClass: nshost > objectClass: ipaservice > objectClass: pkiuser > objectClass: ipahost > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: ipasshhost > objectClass: top > objectClass: ipaSshGroupOfPubKeys > fqdn: neon.ipa.rdmedia.com > managedBy: fqdn=neon.ipa.rdmedia.com > ,cn=computers,cn=accounts,dc=ipa,dc=rdmedi > a,dc=com > krbPrincipalName: host/neon.ipa.rdmedia.com at IPA.RDMEDIA.COM > > serverHostName: neon > ipaUniqueID: 1eaa355c-0176-11e6-8dd5-001a4aa7101c > krbPwdPolicyReference: cn=Default Host Password > Policy,cn=computers,cn=account > s,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict fqdn=neon.ipa.rdmedia.com > ,cn=computers,cn=ac > counts,dc=ipa,dc=rdmedia,dc=com > # cas + 334bfba8-cdae11e6-8a85a70a-bda98fae, ca, ipa.rdmedia.com > > dn: > cn=cas+nsuniqueid=334bfba8-cdae11e6-8a85a70a-bda98fae,cn=ca,dc=ipa,dc=rdme > dia,dc=com > objectClass: nsContainer > objectClass: top > cn: cas > nsds5ReplConflict: namingConflict > cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl > "permission:System > : Add CA";allow (add) groupdn = "ldap:///cn=System: Add > CA,cn=permissions,cn= > pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl > "permission:System > : Delete CA";allow (delete) groupdn = "ldap:///cn=System: Delete > CA,cn=permis > sions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "cn || description")(targetfilter = > "(objectclass=ipaca)")( > version 3.0;acl "permission:System: Modify CA";allow (write) > groupdn = "ldap: > ///cn=System: Modify > CA,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) > aci: (targetattr = "cn || createtimestamp || description || > entryusn || ipacai > d || ipacaissuerdn || ipacasubjectdn || modifytimestamp || > objectclass")(targ > etfilter = "(objectclass=ipaca)")(version 3.0;acl > "permission:System: Read CA > s";allow (compare,read,search) userdn = "ldap:///all";) > # custodia + 334bfbdb-cdae11e6-8a85a70a-bda98fae, ipa, etc, > ipa.rdmedia.com > dn: > cn=custodia+nsuniqueid=334bfbdb-cdae11e6-8a85a70a-bda98fae,cn=ipa,cn=etc,d > c=ipa,dc=rdmedia,dc=com > objectClass: nsContainer > objectClass: top > cn: custodia > nsds5ReplConflict: namingConflict > cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=rdmedia, > dc=com > # domain + 334bfb9e-cdae11e6-8a85a70a-bda98fae, topology, ipa, > etc, ipa.rdmedia > .com > dn: > cn=domain+nsuniqueid=334bfb9e-cdae11e6-8a85a70a-bda98fae,cn=topology,cn=ip > a,cn=etc,dc=ipa,dc=rdmedia,dc=com > nsds5ReplicaStripAttrs: modifiersName modifyTimestamp > internalModifiersName in > ternalModifyTimestamp > ipaReplTopoConfRoot: dc=ipa,dc=rdmedia,dc=com > objectClass: top > objectClass: iparepltopoconf > nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE > entryusn krblasts > uccessfulauth krblastfailedauth krbloginfailedcount > nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof > idnssoaserial > entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount > cn: domain > nsds5ReplConflict: namingConflict > cn=domain,cn=topology,cn=ipa,cn=etc,dc=ipa,d > c=rdmedia,dc=com > # ca + 334bfbe0-cdae11e6-8a85a70a-bda98fae, topology, ipa, etc, > ipa.rdmedia.com > dn: > cn=ca+nsuniqueid=334bfbe0-cdae11e6-8a85a70a-bda98fae,cn=topology,cn=ipa,cn > =etc,dc=ipa,dc=rdmedia,dc=com > objectClass: top > objectClass: iparepltopoconf > cn: ca > ipaReplTopoConfRoot: o=ipaca > nsds5ReplConflict: namingConflict > cn=ca,cn=topology,cn=ipa,cn=etc,dc=ipa,dc=rd > media,dc=com > # dogtag + 334bfbdd-cdae11e6-8a85a70a-bda98fae, custodia + > 334bfbdb-cdae11e6-8a > 85a70a-bda98fae, ipa, etc, ipa.rdmedia.com > dn: > cn=dogtag+nsuniqueid=334bfbdd-cdae11e6-8a85a70a-bda98fae,cn=custodia+nsuni > queid=334bfbdb-cdae11e6-8a85a70a-bda98fae,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc= > com > objectClass: nsContainer > objectClass: top > cn: dogtag > nsds5ReplConflict: namingConflict > cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=ipa,d > c=rdmedia,dc=com > # lawrencium + 6c7e3d83-c11711e6-8a85a70a-bda98fae, > ipa.rdmedia.com ., dns, ipa. > rdmedia.com > dn: > idnsName=lawrencium+nsuniqueid=6c7e3d83-c11711e6-8a85a70a-bda98fae,idnsnam > e=ipa.rdmedia.com > .,cn=dns,dc=ipa,dc=rdmedia,dc=com > aRecord: 192.168.50.55 > dNSTTL: 1200 > objectClass: idnsRecord > objectClass: top > idnsName: lawrencium > nsds5ReplConflict: namingConflict > idnsname=lawrencium,idnsname=ipa.rdmedia.com > .,cn=dns,dc=ipa,dc=rdmedia,dc=com > # mendelevium + e5710f85-c5c511e6-8a85a70a-bda98fae, > ipa.rdmedia.com ., dns, ipa > .rdmedia.com > dn: > idnsName=mendelevium+nsuniqueid=e5710f85-c5c511e6-8a85a70a-bda98fae,idnsna > me=ipa.rdmedia.com > .,cn=dns,dc=ipa,dc=rdmedia,dc=com > aRecord: 192.168.50.52 > dNSTTL: 1200 > objectClass: idnsRecord > objectClass: top > idnsName: mendelevium > nsds5ReplConflict: namingConflict > idnsname=mendelevium,idnsname=ipa.rdmedia.co > m.,cn=dns,dc=ipa,dc=rdmedia,dc=com > # 41 + e764de07-5e2f11e6-bd76eb96-de53d9d8, > 120.100.10.in-addr.arpa., dns, ipa. > rdmedia.com > dn: > idnsname=41+nsuniqueid=e764de07-5e2f11e6-bd76eb96-de53d9d8,idnsname=120.10 > 0.10.in-addr.arpa.,cn=dns,dc=ipa,dc=rdmedia,dc=com > objectClass: top > objectClass: idnsrecord > pTRRecord: arsenica.ipa.rdmedia.com . > idnsName: 41 > nsds5ReplConflict: namingConflict > idnsname=41,idnsname=120.100.10.in-addr.arpa > .,cn=dns,dc=ipa,dc=rdmedia,dc=com > # ipa + 58d90aec-cdae11e6-8a85a70a-bda98fae, cas + > 334bfba8-cdae11e6-8a85a70a-b > da98fae, ca, ipa.rdmedia.com > dn: > cn=ipa+nsuniqueid=58d90aec-cdae11e6-8a85a70a-bda98fae,cn=cas+nsuniqueid=33 > 4bfba8-cdae11e6-8a85a70a-bda98fae,cn=ca,dc=ipa,dc=rdmedia,dc=com > description: IPA CA > ipaCaIssuerDN: CN=Certificate Authority,O=IPA.RDMEDIA.COM > > objectClass: top > objectClass: ipaca > ipaCaSubjectDN: CN=Certificate Authority,O=IPA.RDMEDIA.COM > > ipaCaId: 21547c03-13c3-4f4f-992b-b0257012d1c1 > cn: ipansds5ReplConflict > nsds5ReplConflict: namingConflict > cn=ipa,cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com > # search result > search: 2 > result: 0 Success > # numResponses: 28 > # numEntries: 27 > > > So when I try eg. this... > > [root at moscovium ~]# ldapmodify -x -D "cn=directory manager" -W -h > moscovium.ipa.rdmedia.com -p 389 > Enter LDAP Password: > dn: fqdn=neon.ipa.rdmedia.com > +nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,c > n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com > changetype: modrdn > newrdn fqdn=neontemp.ipa.rdmedia.com > deleteoldrdn: 0 > It has to be newrdn: fqdn=neontemp.ipa.rdmedia.com the ":" was missing. But you don't always have to do the modrdn steps, only if you want to keep the conflict entry under a different dn. I would suggest you do the search for conflicts again, and just returning the nsds5ReplConflict attribute, you get then something like: dn: idnsname=41+nsuniqueid=e764de07-5e2f11e6-bd76eb96-de53d9d8,idnsname=120.10.in- addr.arpa.,cn=dns,dc=ipa,dc=rdmedia,dc=com nsds5ReplConflict: namingConflict idnsname=mendelevium,idnsname=ipa.rdmedia.co m.,cn=dns,dc=ipa,dc=rdmedia,dc=com next do a search for both entries, the conflict entry and the one referenced in the and the nsds5ReplConflict attribute, if the original entry exists and you want to keep this, you can just delete the conflict entry ldapmodify -x -D "cn=directory manager" .... dn: fqdn=neon.ipa.rdmedia.com +nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,c n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com changetype: delete > > ...I get: > > ldapmodify: invalid format (line 3) entry: > "fqdn=neon.ipa.rdmedia.com > +nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,cn=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com" > > So my question: what can I do to resolve the conflicts? > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From chek_chek at ukr.net Wed Feb 15 12:10:57 2017 From: chek_chek at ukr.net (Alexandr Slavov) Date: Wed, 15 Feb 2017 14:10:57 +0200 Subject: [Freeipa-users] Add IP-address client to error-log file Message-ID: <1487158899.436858841.bxqi3dig@frv38.fwdcdn.com> Hello all. We use CentOS 7 ,FreeIPA 4.4, Apache 2.4 We installed audit system like http://www.freeipa.org/page/Centralized_Logging? for monitoring "Who's What's Doing". Audit system parsing /var/log/httpd/error_log and logging to Elasticsearch. Some string for Remove user from group in FreeIPA from /var/log/httpd/error_log: [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] ipa: INFO: admin-user at DOMAIN.COM: batch: group_remove_member(u'somegroup', user=u'someuser'): SUCCESS Parsed string loaded in Elasticsearch: { ? "_index": "logstash-2017.02.15", ? "_type": "events", ? "_id": "Uniq-ID", ? "_score": null, ? "_source": { ??? "timestamp": "2017-02-15T03:46:08-06:00", ??? "status": "SUCCESS", ??? "parameters": "'u'somegroup', user=u'someuser'", ??? "action": "group_remove_member", ??? "principal": "admin-user at DOMAIN.COM", ??? "pid": "31732", ??? "event.tags": [ ????? "ipa", ????? "ipa-call", ????? "batch" ??? ], ??? "host": "server-1", ??? "facility": "local0", ??? "severity": "notice", ??? "tag": "httpderror", ??? "message": " [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] ipa: INFO: admin-user at DOMAIN.COM: batch: group_remove_member(u'somegroup', user=u'someuser'): SUCCESS" ? }, ? "fields": { ??? "timestamp": [ ????? 1487151968000 ??? ] ? }, ? "sort": [ ??? 1487151968000 ? ] } But we need add IP-address of admin-user at DOMAIN.COM? outputting to error_log.? How can? add IP-address to this error_log file ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.hutchison at RACKSPACE.COM Wed Feb 15 20:50:46 2017 From: ryan.hutchison at RACKSPACE.COM (Ryan Hutchison) Date: Wed, 15 Feb 2017 20:50:46 +0000 Subject: [Freeipa-users] ipa-server-install fails at client phase Message-ID: <77C0ABF3-8CE4-420A-B5B4-FB4931EC29CB@rackspace.com> Hello All, Version: IPAv4.4 OS: RHEL 7.3 Having a python import issue during ipa-server-install here, and the internets are failing me. Please note that the urls and server names have been abstracted. During the install run, I get the following: Forwarding 'schema' to json server 'https://ipaserver.domain.com/ipa/json' Traceback (most recent call last): ? File "/usr/sbin/ipa-client-install", line 3128, in ??? sys.exit(main()) ? File "/usr/sbin/ipa-client-install", line 3109, in main ??? rval = install(options, env, fstore, statestore) ? File "/usr/sbin/ipa-client-install", line 2818, in install ???api.finalize() ? File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, in finalize ??? self.__do_if_not_done('load_plugins') ? File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, in __do_if_not_done ??? getattr(self, name)() ? File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, in load_plugins ??? for package in self.packages: ? File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, in packages ??? ipaclient.remote_plugins.get_package(self), ? File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line 118, in get_package ??? plugins = schema.get_package(server_info, client) ? File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 543, in get_package ??? schema = Schema(client) ? File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 387, in __init__ ??? fingerprint, ttl = self._fetch(client, ignore_cache=read_failed) ? File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 426, in _fetch ??? schema = client.forward(u'schema', **kwargs)['result'] ? File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1033, in forward ??? raise NetworkError(uri=server, error=e.errmsg) ipalib.errors.NetworkError: cannot connect to ''https://ipaserver.domain.com/ipa/json: Internal Server Error ipa.ipapython.install.cli.install_tool(Server): ERROR??? Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(Server): ERROR??? The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information The install log doesn?t really tell me whole lot, save for a full stacktrace when running ?ipa-client-install?: 2017-02-15T20:40:12Z DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain domain.com --server ipaserver.domain.com --realm REALM.COM --hostname ipaserver.domain.com 2017-02-15T20:40:13Z DEBUG Process finished, return code=1 2017-02-15T20:40:13Z 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/ipapython/install/cli.py", line 318, in run ??? cfgr.run() ?truncated? However, in the httpd logs I see the following: [Wed Feb 15 14:40:13.488496 2017] [wsgi:error] [pid 39142] [remote 172.20.151.7:58476] mod_wsgi (pid=39142): Target WSGI script '/usr/share/ipa/wsgi.py' cannot be loaded as Python module. [Wed Feb 15 14:40:13.488546 2017] [wsgi:error] [pid 39142] [remote 172.20.151.7:58476] mod_wsgi (pid=39142): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [Wed Feb 15 14:40:13.488638 2017] [wsgi:error] [pid 39142] [remote 172.20.151.7:58476] Traceback (most recent call last): [Wed Feb 15 14:40:13.488664 2017] [wsgi:error] [pid 39142] [remote 172.20.151.7:58476]?? File "/usr/share/ipa/wsgi.py", line 26, in [Wed Feb 15 14:40:13.488674 2017] [wsgi:error] [pid 39142] [remote 172.20.151.7:58476]???? from ipalib import api [Wed Feb 15 14:40:13.488691 2017] [wsgi:error] [pid 39142] [remote 172.20.151.7:58476] ImportError: No module named 'ipalib' Along with other import errors. However, I have confirmed I am able to import these global modules: [root at 720941-ipa ~]# python Python 2.7.5 (default, Aug? 2 2016, 04:20:16) [GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from ipalib import api >>> api I can also run the wsgi script directly without issue: [root at 720941-ipa ~]# python /usr/share/ipa/wsgi.py ipa: INFO: *** PROCESS START *** Can someone point me in the right direction here? Thank you in advance for your help! -- Ryan Hutchison, RHCE/CCNA Enterprise Support Architect Rackspace Hosting Direct: (210) 312-8157 Mobile: (210) 452-4349 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4295 bytes Desc: not available URL: From dkupka at redhat.com Thu Feb 16 13:48:30 2017 From: dkupka at redhat.com (David Kupka) Date: Thu, 16 Feb 2017 14:48:30 +0100 Subject: [Freeipa-users] How to change kerberos key lifetime? In-Reply-To: References: <20170216072250.GA6059@dkupka.usersys.redhat.com> Message-ID: <20170216134830.GE6059@dkupka.usersys.redhat.com> On Thu, Feb 16, 2017 at 07:54:47AM -0500, William Muriithi wrote: > Morning David, > > Thank you very much for your help. > > > first you're mentioning "key expiry" but if I understand correctly you're > > interested in "ticket lifetime". > Yes, want to increase ticket lifetime. > > > > As mentioned here [1] the ticket lifetime is the minimum of 4 values: > > 1) maxlife for the user principal > > 2) maxlife for the service [principal] > > 3) max_life in the kdc.conf > > 4) requested lifetime in the ticket request > > > > You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in > > [libdefaults] in /etc/krb5.conf on client). > > > > To increase 2) you need to change maxlife for krbtgt service. There're two ways > > this ca be done: > > a) modifying krbMaxTicketLife attribute in > > krbPrincipalName=krbtgt/EXAMPLE.ORG at EXAMPLE.ORG,cn=EXAMPLE.ORG,cn=kerberos,dc=example,dc=org > > b) using kadmin.local: > > # kadmin.local > > Authenticating as principal admin/admin at EXAMPLE.ORG > > : modprinc -maxlife 10day krbtgt/EXAMPLE.ORG > > Principal "krbtgt/EXAMPLE.ORG at EXAMPLE.ORG" modified. > > : exit > > Will try 2 b and see how it goes > > > > > To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf > > and restart krb5kdc service. > > > > okay, wasn't actually aware of this. Will look at it > > > But generally I don't think it's a good idea to have such long tickets. Would > > it make sense in your use case to deploy SSSD on user systems to handle > > Kerberos tickets for them? > > > I am actually using SSSD on all the systems, even the desktops. I > agree the changes above aren't ideal and would prefer to get SSSD > working well. Where would like to avoid this error showing around > every 12 hours. > > antimony: Could not chdir to home directory /home/william: Key has expired > > > Regards, > William Hello William! The fact that your desktops are using SSSD changes the situation dramatically. SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in. And can be configured to renew the ticket for the user until the ticket renew life time expires. Given this you can keep ticket life time reasonable short (~1 day) set ticket renewable life time to longer period (~2 weeks) and maintain reasonable security level without negative impact on user's daily work. Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options in sssd-krb5 man page. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From t.ruiten at rdmedia.com Thu Feb 16 14:05:06 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 16 Feb 2017 15:05:06 +0100 Subject: [Freeipa-users] how to resolve replication conflicts In-Reply-To: <58A5A202.2040703@redhat.com> References: <58A5A202.2040703@redhat.com> Message-ID: Thank you very much Ludwig, that worked. I had to do a ldapdelete -r (recursive) to remove a few containers which apparently had some tombstone entries in them. Domain is now running at level 1! On 16 February 2017 at 13:58, Ludwig Krispenz wrote: > > On 02/16/2017 01:32 PM, Tiemen Ruiten wrote: > > Hello, > > I have a FreeIPA setup in which some masters suffered from a few > uncontrolled shutdowns and now there are replication conflicts (which > prevent from setting the Domain Level to 1). > > I was trying to follow the instructions here: https://access.redhat. > com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/ > Identity_Management_Guide/ipa-replica-manage.html > > But unfortunately I'm not getting anywhere. This the result of an > ldapsearch for replication conflicts: > > >> [root at moscovium ~]# ldapsearch -x -D "cn=directory manager" -W -b >> "dc=ipa,dc=rdmedia,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: nsds5ReplConflict=* >> # requesting: * nsds5ReplConflict >> # >> # servers + 334bfc53-cdae11e6-8a85a70a-bda98fae, dns, ipa.rdmedia.com >> dn: cn=servers+nsuniqueid=334bfc53-cdae11e6-8a85a70a- >> bda98fae,cn=dns,dc=ipa,dc >> =rdmedia,dc=com >> objectClass: nsContainer >> objectClass: top >> cn: servers >> nsds5ReplConflict: namingConflict cn=servers,cn=dns,dc=ipa,dc= >> rdmedia,dc=com >> # System: Add CA + 334bfbe5-cdae11e6-8a85a70a-bda98fae, permissions, >> pbac, ipa. >> rdmedia.com >> dn: cn=System: Add CA+nsuniqueid=334bfbe5-cdae11e6-8a85a70a-bda98fae,cn= >> permis >> sions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaca) >> ipaPermRight: add >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Add CA >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=CA Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: add >> ca,cn=permissions,cn=pbac,dc= >> ipa,dc=rdmedia,dc=com > > # System: Delete CA + 334bfbe9-cdae11e6-8a85a70a-bda98fae, permissions, >> pbac, i >> pa.rdmedia.com >> dn: cn=System: Delete CA+nsuniqueid=334bfbe9- >> cdae11e6-8a85a70a-bda98fae,cn=per >> missions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaca) >> ipaPermRight: delete >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Delete CA >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=CA Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: delete >> ca,cn=permissions,cn=pbac, >> dc=ipa,dc=rdmedia,dc=com >> # System: Modify CA + 334bfbed-cdae11e6-8a85a70a-bda98fae, permissions, >> pbac, i >> pa.rdmedia.com >> dn: cn=System: Modify CA+nsuniqueid=334bfbed- >> cdae11e6-8a85a70a-bda98fae,cn=per >> missions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaca) >> ipaPermRight: write >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Modify CA >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=CA Administrator,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermDefaultAttr: description >> ipaPermDefaultAttr: cn >> ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: modify >> ca,cn=permissions,cn=pbac, >> dc=ipa,dc=rdmedia,dc=com >> # System: Read CAs + 334bfbf1-cdae11e6-8a85a70a-bda98fae, permissions, >> pbac, ip >> a.rdmedia.com >> dn: cn=System: Read CAs+nsuniqueid=334bfbf1- >> cdae11e6-8a85a70a-bda98fae,cn=perm >> issions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaca) >> ipaPermRight: read >> ipaPermRight: compare >> ipaPermRight: search >> ipaPermBindRuleType: all >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Read CAs >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> ipaPermDefaultAttr: description >> ipaPermDefaultAttr: ipacaissuerdn >> ipaPermDefaultAttr: objectclass >> ipaPermDefaultAttr: ipacasubjectdn >> ipaPermDefaultAttr: ipacaid >> ipaPermDefaultAttr: cn >> ipaPermLocation: cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: read >> cas,cn=permissions,cn=pbac,d >> c=ipa,dc=rdmedia,dc=com >> # System: Modify DNS Servers Configuration + 334bfbf6-cdae11e6-8a85a70a- >> bda98fa >> e, permissions, pbac, ipa.rdmedia.com >> dn: cn=System: Modify DNS Servers Configuration+nsuniqueid= >> 334bfbf6-cdae11e6-8 >> a85a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=idnsServerConfigObject) >> ipaPermRight: write >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Modify DNS Servers Configuration >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermDefaultAttr: idnssoamname >> ipaPermDefaultAttr: idnssubstitutionvariable >> ipaPermDefaultAttr: idnsforwardpolicy >> ipaPermDefaultAttr: idnsforwarders >> ipaPermLocation: dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: modify dns servers >> configuration, >> cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Read DNS Servers Configuration + 334bfbfa-cdae11e6-8a85a70a- >> bda98fae, >> permissions, pbac, ipa.rdmedia.com >> dn: cn=System: Read DNS Servers Configuration+nsuniqueid= >> 334bfbfa-cdae11e6-8a8 >> 5a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=idnsServerConfigObject) >> ipaPermRight: read >> ipaPermRight: compare >> ipaPermRight: search >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Read DNS Servers Configuration >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> member: cn=DNS Servers,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermDefaultAttr: idnsforwardpolicy >> ipaPermDefaultAttr: objectclass >> ipaPermDefaultAttr: idnsforwarders >> ipaPermDefaultAttr: idnsserverid >> ipaPermDefaultAttr: idnssubstitutionvariable >> ipaPermDefaultAttr: idnssoamname >> ipaPermLocation: dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: read dns servers >> configuration,cn >> =permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Manage Host Principals + 334bfc0b-cdae11e6-8a85a70a-bda98fae, >> permiss >> ions, pbac, ipa.rdmedia.com >> dn: cn=System: Manage Host Principals+nsuniqueid= >> 334bfc0b-cdae11e6-8a85a70a-bd >> a98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipahost) >> ipaPermRight: write >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Manage Host Principals >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=Host Administrators,cn=privileges, >> cn=pbac,dc=ipa,dc=rdmedia,dc=com >> member: cn=Host Enrollment,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermDefaultAttr: krbprincipalname >> ipaPermDefaultAttr: krbcanonicalname >> ipaPermLocation: cn=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: manage host >> principals,cn=permiss >> ions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Add IPA Locations + 334bfc20-cdae11e6-8a85a70a-bda98fae, >> permissions, >> pbac, ipa.rdmedia.com >> dn: cn=System: Add IPA Locations+nsuniqueid=334bfc20- >> cdae11e6-8a85a70a-bda98fa >> e,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaLocationObject) >> ipaPermRight: add >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Add IPA Locations >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: add ipa >> locations,cn=permissions, >> cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Modify IPA Locations + 334bfc24-cdae11e6-8a85a70a-bda98fae, >> permissio >> ns, pbac, ipa.rdmedia.com >> dn: cn=System: Modify IPA Locations+nsuniqueid=334bfc24- >> cdae11e6-8a85a70a-bda9 >> 8fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaLocationObject) >> ipaPermRight: write >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Modify IPA Locations >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermDefaultAttr: description >> ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: modify ipa >> locations,cn=permissio >> ns,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Read IPA Locations + 334bfc28-cdae11e6-8a85a70a-bda98fae, >> permissions >> , pbac, ipa.rdmedia.com >> dn: cn=System: Read IPA Locations+nsuniqueid=334bfc28- >> cdae11e6-8a85a70a-bda98f >> ae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaLocationObject) >> ipaPermRight: read >> ipaPermRight: compare >> ipaPermRight: search >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Read IPA Locations >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermDefaultAttr: objectclass >> ipaPermDefaultAttr: description >> ipaPermDefaultAttr: idnsname >> ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: read ipa >> locations,cn=permissions >> ,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Remove IPA Locations + 334bfc2c-cdae11e6-8a85a70a-bda98fae, >> permissio >> ns, pbac, ipa.rdmedia.com >> dn: cn=System: Remove IPA Locations+nsuniqueid=334bfc2c- >> cdae11e6-8a85a70a-bda9 >> 8fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaLocationObject) >> ipaPermRight: delete >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Remove IPA Locations >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermLocation: cn=locations,cn=etc,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: remove ipa >> locations,cn=permissio >> ns,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Read Locations of IPA Servers + 334bfc30-cdae11e6-8a85a70a- >> bda98fae, >> permissions, pbac, ipa.rdmedia.com >> dn: cn=System: Read Locations of IPA Servers+nsuniqueid=334bfc30- >> cdae11e6-8a85 >> a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaConfigObject) >> ipaPermRight: read >> ipaPermRight: compare >> ipaPermRight: search >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Read Locations of IPA Servers >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermDefaultAttr: objectclass >> ipaPermDefaultAttr: ipaserviceweight >> ipaPermDefaultAttr: ipalocation >> ipaPermDefaultAttr: cn >> ipaPermLocation: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: read locations of ipa >> servers,cn= >> permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Read Status of Services on IPA Servers + >> 334bfc34-cdae11e6-8a85a70a-b >> da98fae, permissions, pbac, ipa.rdmedia.com >> dn: cn=System: Read Status of Services on IPA Servers+nsuniqueid=334bfc34- >> cdae >> 11e6-8a85a70a-bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaConfigObject) >> ipaPermRight: read >> ipaPermRight: compare >> ipaPermRight: search >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Read Status of Services on IPA Servers >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=ipa,dc=rdmedia,dc= >> com >> ipaPermDefaultAttr: objectclass >> ipaPermDefaultAttr: ipaconfigstring >> ipaPermDefaultAttr: cn >> ipaPermLocation: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: read status of services on >> ipa se >> rvers,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Manage Service Principals + 334bfc38-cdae11e6-8a85a70a-bda98fae, >> perm >> issions, pbac, ipa.rdmedia.com >> dn: cn=System: Manage Service Principals+nsuniqueid= >> 334bfc38-cdae11e6-8a85a70a >> -bda98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=ipaservice) >> ipaPermRight: write >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Manage Service Principals >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=Service Administrators,cn=privileges, >> cn=pbac,dc=ipa,dc=rdmedia,dc=c >> om >> ipaPermDefaultAttr: krbprincipalname >> ipaPermDefaultAttr: krbcanonicalname >> ipaPermLocation: cn=services,cn=accounts,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: manage service >> principals,cn=perm >> issions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # System: Manage User Principals + 334bfc45-cdae11e6-8a85a70a-bda98fae, >> permiss >> ions, pbac, ipa.rdmedia.com >> dn: cn=System: Manage User Principals+nsuniqueid= >> 334bfc45-cdae11e6-8a85a70a-bd >> a98fae,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> ipaPermTargetFilter: (objectclass=posixaccount) >> ipaPermRight: write >> ipaPermBindRuleType: permission >> ipaPermissionType: V2 >> ipaPermissionType: MANAGED >> ipaPermissionType: SYSTEM >> cn: System: Manage User Principals >> objectClass: ipapermission >> objectClass: top >> objectClass: groupofnames >> objectClass: ipapermissionv2 >> member: cn=User Administrators,cn=privileges, >> cn=pbac,dc=ipa,dc=rdmedia,dc=com >> member: cn=Modify Users and Reset passwords,cn=privileges,cn= >> pbac,dc=ipa,dc=rd >> media,dc=com >> ipaPermDefaultAttr: krbprincipalname >> ipaPermDefaultAttr: krbcanonicalname >> ipaPermLocation: cn=users,cn=accounts,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict cn=system: manage user >> principals,cn=permiss >> ions,cn=pbac,dc=ipa,dc=rdmedia,dc=com >> # locations + 334bfba2-cdae11e6-8a85a70a-bda98fae, etc, ipa.rdmedia.com >> dn: cn=locations+nsuniqueid=334bfba2-cdae11e6-8a85a70a- >> bda98fae,cn=etc,dc=ipa, >> dc=rdmedia,dc=com >> objectClass: nsContainer >> objectClass: top >> cn: locations >> nsds5ReplConflict: namingConflict cn=locations,cn=etc,dc=ipa,dc= >> rdmedia,dc=com >> aci: (targetfilter = "(objectclass=ipaLocationObject)")(version 3.0;acl >> "permi >> ssion:System: Add IPA Locations";allow (add) groupdn = " >> ldap:///cn=System: Ad >> d IPA Locations,cn=permissions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) >> aci: (targetattr = "description")(targetfilter = >> "(objectclass=ipaLocationObje >> ct)")(version 3.0;acl "permission:System: Modify IPA Locations";allow >> (write) >> groupdn = "ldap:///cn=System: Modify IPA Locations,cn=permissions,cn= >> pbac,dc >> =ipa,dc=rdmedia,dc=com";) >> aci: (targetattr = "createtimestamp || description || entryusn || >> idnsname || >> modifytimestamp || objectclass")(targetfilter = >> "(objectclass=ipaLocationObje >> ct)")(version 3.0;acl "permission:System: Read IPA Locations";allow >> (compare, >> read,search) groupdn = "ldap:///cn=System: Read IPA >> Locations,cn=permissions, >> cn=pbac,dc=ipa,dc=rdmedia,dc=com";) >> aci: (targetfilter = "(objectclass=ipaLocationObject)")(version 3.0;acl >> "permi >> ssion:System: Remove IPA Locations";allow (delete) groupdn = " >> ldap:///cn=Syst >> em: Remove IPA Locations,cn=permissions,cn= >> pbac,dc=ipa,dc=rdmedia,dc=com";) >> # neon.ipa.rdmedia.com + 1b780d06-017611e6-966aeb96-de53d9d8, computers, >> accoun >> ts, ipa.rdmedia.com >> dn: fqdn=neon.ipa.rdmedia.com+nsuniqueid=1b780d06-017611e6- >> 966aeb96-de53d9d8,c >> n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com >> krbExtraData:: AAJIQA5XaG9zdC9uZW9uLmlwYS5yZG >> 1lZGlhLmNvbUBJUEEuUkRNRURJQS5DT00 >> A >> enrolledBy: uid=admin,cn=users,cn=accounts,dc=ipa,dc=rdmedia,dc=com >> krbLastPwdChange: 20160413124912Z >> krbPrincipalKey:: MIIBKKADAgEBoQMCAQGiAwIBAaMDAg >> EBpIIBEDCCAQwwS6FJMEegAwIBEqFA >> BD4gAPd2yVptQC/d3mk7xdb3skL+KkkUzewAxCF0FJgXXuBVt1y2GHtnhz >> ILNe91amjovgXAFEujn >> 8x6YrwHXDA7oTkwN6ADAgERoTAELhAAPbI3gwakFyt9EnCqDLWst6FeXKO0F >> wvx3+gZZOGmYQpr0Z >> ujLLtmJuJVmS8wQ6FBMD+gAwIBEKE4BDYYABMJXEKVH2Yn4nGzJ >> 5woqDjO2dVUx8nQ+1NSi6dREwy >> 8T+7VrbdVOpaQgkUx4czwkhxKvVcwO6E5MDegAwIBF6EwBC4QABWhTKkWc50oJl >> pSw/FK2yhl+ZUo >> MZt0XHA/xdPXDD3DxGV5cx2MgvJEhJzs >> cn: neon.ipa.rdmedia.com >> objectClass: ipaobject >> objectClass: ieee802device >> objectClass: nshost >> objectClass: ipaservice >> objectClass: pkiuser >> objectClass: ipahost >> objectClass: krbprincipal >> objectClass: krbprincipalaux >> objectClass: ipasshhost >> objectClass: top >> objectClass: ipaSshGroupOfPubKeys >> fqdn: neon.ipa.rdmedia.com >> managedBy: fqdn=neon.ipa.rdmedia.com,cn=computers,cn=accounts,dc=ipa, >> dc=rdmedi >> a,dc=com >> krbPrincipalName: host/neon.ipa.rdmedia.com at IPA.RDMEDIA.COM >> serverHostName: neon >> ipaUniqueID: 1eaa355c-0176-11e6-8dd5-001a4aa7101c >> krbPwdPolicyReference: cn=Default Host Password >> Policy,cn=computers,cn=account >> s,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplConflict: namingConflict fqdn=neon.ipa.rdmedia.com,cn= >> computers,cn=ac >> counts,dc=ipa,dc=rdmedia,dc=com >> # cas + 334bfba8-cdae11e6-8a85a70a-bda98fae, ca, ipa.rdmedia.com >> dn: cn=cas+nsuniqueid=334bfba8-cdae11e6-8a85a70a-bda98fae,cn= >> ca,dc=ipa,dc=rdme >> dia,dc=com >> objectClass: nsContainer >> objectClass: top >> cn: cas >> nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=ipa,dc=rdmedia,dc=com >> aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl >> "permission:System >> : Add CA";allow (add) groupdn = "ldap:///cn=System: Add >> CA,cn=permissions,cn= >> pbac,dc=ipa,dc=rdmedia,dc=com";) >> aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl >> "permission:System >> : Delete CA";allow (delete) groupdn = "ldap:///cn=System: Delete >> CA,cn=permis >> sions,cn=pbac,dc=ipa,dc=rdmedia,dc=com";) >> aci: (targetattr = "cn || description")(targetfilter = >> "(objectclass=ipaca)")( >> version 3.0;acl "permission:System: Modify CA";allow (write) groupdn = >> "ldap: >> ///cn=System: Modify CA,cn=permissions,cn=pbac,dc= >> ipa,dc=rdmedia,dc=com";) >> aci: (targetattr = "cn || createtimestamp || description || entryusn || >> ipacai >> d || ipacaissuerdn || ipacasubjectdn || modifytimestamp || >> objectclass")(targ >> etfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System: >> Read CA >> s";allow (compare,read,search) userdn = "ldap:///all";) >> # custodia + 334bfbdb-cdae11e6-8a85a70a-bda98fae, ipa, etc, >> ipa.rdmedia.com >> dn: cn=custodia+nsuniqueid=334bfbdb-cdae11e6-8a85a70a- >> bda98fae,cn=ipa,cn=etc,d >> c=ipa,dc=rdmedia,dc=com >> objectClass: nsContainer >> objectClass: top >> cn: custodia >> nsds5ReplConflict: namingConflict cn=custodia,cn=ipa,cn=etc,dc= >> ipa,dc=rdmedia, >> dc=com >> # domain + 334bfb9e-cdae11e6-8a85a70a-bda98fae, topology, ipa, etc, >> ipa.rdmedia >> .com >> dn: cn=domain+nsuniqueid=334bfb9e-cdae11e6-8a85a70a-bda98fae,cn= >> topology,cn=ip >> a,cn=etc,dc=ipa,dc=rdmedia,dc=com >> nsds5ReplicaStripAttrs: modifiersName modifyTimestamp >> internalModifiersName in >> ternalModifyTimestamp >> ipaReplTopoConfRoot: dc=ipa,dc=rdmedia,dc=com >> objectClass: top >> objectClass: iparepltopoconf >> nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn >> krblasts >> uccessfulauth krblastfailedauth krbloginfailedcount >> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof >> idnssoaserial >> entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount >> cn: domain >> nsds5ReplConflict: namingConflict cn=domain,cn=topology,cn=ipa, >> cn=etc,dc=ipa,d >> c=rdmedia,dc=com >> # ca + 334bfbe0-cdae11e6-8a85a70a-bda98fae, topology, ipa, etc, >> ipa.rdmedia.com >> dn: cn=ca+nsuniqueid=334bfbe0-cdae11e6-8a85a70a-bda98fae,cn= >> topology,cn=ipa,cn >> =etc,dc=ipa,dc=rdmedia,dc=com >> objectClass: top >> objectClass: iparepltopoconf >> cn: ca >> ipaReplTopoConfRoot: o=ipaca >> nsds5ReplConflict: namingConflict cn=ca,cn=topology,cn=ipa,cn= >> etc,dc=ipa,dc=rd >> media,dc=com >> # dogtag + 334bfbdd-cdae11e6-8a85a70a-bda98fae, custodia + >> 334bfbdb-cdae11e6-8a >> 85a70a-bda98fae, ipa, etc, ipa.rdmedia.com >> dn: cn=dogtag+nsuniqueid=334bfbdd-cdae11e6-8a85a70a-bda98fae,cn= >> custodia+nsuni >> queid=334bfbdb-cdae11e6-8a85a70a-bda98fae,cn=ipa,cn= >> etc,dc=ipa,dc=rdmedia,dc= >> com >> objectClass: nsContainer >> objectClass: top >> cn: dogtag >> nsds5ReplConflict: namingConflict cn=dogtag,cn=custodia,cn=ipa, >> cn=etc,dc=ipa,d >> c=rdmedia,dc=com >> # lawrencium + 6c7e3d83-c11711e6-8a85a70a-bda98fae, ipa.rdmedia.com., >> dns, ipa. >> rdmedia.com >> dn: idnsName=lawrencium+nsuniqueid=6c7e3d83-c11711e6- >> 8a85a70a-bda98fae,idnsnam >> e=ipa.rdmedia.com.,cn=dns,dc=ipa,dc=rdmedia,dc=com >> aRecord: 192.168.50.55 >> dNSTTL: 1200 >> objectClass: idnsRecord >> objectClass: top >> idnsName: lawrencium >> nsds5ReplConflict: namingConflict idnsname=lawrencium,idnsname=i >> pa.rdmedia.com >> .,cn=dns,dc=ipa,dc=rdmedia,dc=com >> # mendelevium + e5710f85-c5c511e6-8a85a70a-bda98fae, ipa.rdmedia.com., >> dns, ipa >> .rdmedia.com >> dn: idnsName=mendelevium+nsuniqueid=e5710f85-c5c511e6- >> 8a85a70a-bda98fae,idnsna >> me=ipa.rdmedia.com.,cn=dns,dc=ipa,dc=rdmedia,dc=com >> aRecord: 192.168.50.52 >> dNSTTL: 1200 >> objectClass: idnsRecord >> objectClass: top >> idnsName: mendelevium >> nsds5ReplConflict: namingConflict idnsname=mendelevium,idnsname= >> ipa.rdmedia.co >> m.,cn=dns,dc=ipa,dc=rdmedia,dc=com >> # 41 + e764de07-5e2f11e6-bd76eb96-de53d9d8, 120.100.10.in-addr.arpa., >> dns, ipa. >> rdmedia.com >> dn: idnsname=41+nsuniqueid=e764de07-5e2f11e6-bd76eb96- >> de53d9d8,idnsname=120.10 >> 0.10.in-addr.arpa.,cn=dns,dc=ipa,dc=rdmedia,dc=com >> objectClass: top >> objectClass: idnsrecord >> pTRRecord: arsenica.ipa.rdmedia.com. >> idnsName: 41 >> nsds5ReplConflict: namingConflict idnsname=41,idnsname=120.100. >> 10.in-addr.arpa >> .,cn=dns,dc=ipa,dc=rdmedia,dc=com >> # ipa + 58d90aec-cdae11e6-8a85a70a-bda98fae, cas + >> 334bfba8-cdae11e6-8a85a70a-b >> da98fae, ca, ipa.rdmedia.com >> dn: cn=ipa+nsuniqueid=58d90aec-cdae11e6-8a85a70a-bda98fae,cn= >> cas+nsuniqueid=33 >> 4bfba8-cdae11e6-8a85a70a-bda98fae,cn=ca,dc=ipa,dc=rdmedia,dc=com >> description: IPA CA >> ipaCaIssuerDN: CN=Certificate Authority,O=IPA.RDMEDIA.COM >> objectClass: top >> objectClass: ipaca >> ipaCaSubjectDN: CN=Certificate Authority,O=IPA.RDMEDIA.COM >> ipaCaId: 21547c03-13c3-4f4f-992b-b0257012d1c1 >> cn: ipansds5ReplConflict >> nsds5ReplConflict: namingConflict cn=ipa,cn=cas,cn=ca,dc=ipa,dc= >> rdmedia,dc=com >> # search result >> search: 2 >> result: 0 Success >> # numResponses: 28 >> # numEntries: 27 > > > So when I try eg. this... > > [root at moscovium ~]# ldapmodify -x -D "cn=directory manager" -W -h >> moscovium.ipa.rdmedia.com -p 389 >> Enter LDAP Password: >> dn: fqdn=neon.ipa.rdmedia.com+nsuniqueid=1b780d06-017611e6- >> 966aeb96-de53d9d8,c >> n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com >> changetype: modrdn >> newrdn fqdn=neontemp.ipa.rdmedia.com >> deleteoldrdn: 0 > > It has to be > newrdn: fqdn=neontemp.ipa.rdmedia.com > the ":" was missing. > But you don't always have to do the modrdn steps, only if you want to keep > the conflict entry under a different dn. > > I would suggest you do the search for conflicts again, and just returning > the nsds5ReplConflict attribute, you get then something like: > dn: idnsname=41+nsuniqueid=e764de07-5e2f11e6-bd76eb96-de53d9d8,idnsname=120.10.in- > addr.arpa.,cn=dns,dc=ipa,dc=rdmedia,dc=com > nsds5ReplConflict: namingConflict idnsname=mendelevium,idnsname= > ipa.rdmedia.co > m.,cn=dns,dc=ipa,dc=rdmedia,dc=com > > > next do a search for both entries, the conflict entry and the one > referenced in the and the > nsds5ReplConflict attribute, if the original entry exists and you want to > keep this, you can just delete the conflict entry > > ldapmodify -x -D "cn=directory manager" .... > dn: fqdn=neon.ipa.rdmedia.com+nsuniqueid=1b780d06-017611e6- > 966aeb96-de53d9d8,c > n=computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com > changetype: delete > > > ...I get: > > ldapmodify: invalid format (line 3) entry: "fqdn=neon.ipa.rdmedia.com+ >> nsuniqueid=1b780d06-017611e6-966aeb96-de53d9d8,cn= >> computers,cn=accounts,dc=ipa,dc=rdmedia,dc=com" > > > So my question: what can I do to resolve the conflicts? > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > > > > -- > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander > > > -- > 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 > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 16 14:51:52 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 16 Feb 2017 09:51:52 -0500 Subject: [Freeipa-users] Add IP-address client to error-log file In-Reply-To: <1487158899.436858841.bxqi3dig@frv38.fwdcdn.com> References: <1487158899.436858841.bxqi3dig@frv38.fwdcdn.com> Message-ID: <4b118fc7-49f4-a269-c776-ecf785284861@redhat.com> Alexandr Slavov wrote: > Hello all. > We use CentOS 7 ,FreeIPA 4.4, Apache 2.4 > We installed audit system like > http://www.freeipa.org/page/Centralized_Logging for monitoring "Who's > What's Doing". > Audit system parsing /var/log/httpd/error_log and logging to Elasticsearch. > > Some string for Remove user from group in FreeIPA from > /var/log/httpd/error_log: > [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] ipa: INFO: > admin-user at DOMAIN.COM: batch: group_remove_member(u'somegroup', > user=u'someuser'): SUCCESS > > Parsed string loaded in Elasticsearch: > { > "_index": "logstash-2017.02.15", > "_type": "events", > "_id": "Uniq-ID", > "_score": null, > "_source": { > "timestamp": "2017-02-15T03:46:08-06:00", > "status": "SUCCESS", > "parameters": "'u'somegroup', user=u'someuser'", > "action": "group_remove_member", > "principal": "admin-user at DOMAIN.COM", > "pid": "31732", > "event.tags": [ > "ipa", > "ipa-call", > "batch" > ], > "host": "server-1", > "facility": "local0", > "severity": "notice", > "tag": "httpderror", > "message": " [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] > ipa: INFO: admin-user at DOMAIN.COM: batch: > group_remove_member(u'somegroup', user=u'someuser'): SUCCESS" > }, > "fields": { > "timestamp": [ > 1487151968000 > ] > }, > "sort": [ > 1487151968000 > ] > } > > > But we need add IP-address of admin-user at DOMAIN.COM outputting to > error_log. How can add IP-address to this error_log file ? See https://httpd.apache.org/docs/2.4/mod/core.html#errorlogformat You'd have to manually configure this on each master and ensure that it survives IPA updates. Alternatively you can open a ticket asking IPA to add this. rob From jpazdziora at redhat.com Thu Feb 16 15:02:00 2017 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 16 Feb 2017 16:02:00 +0100 Subject: [Freeipa-users] IPA rewrite conf In-Reply-To: References: <20161128080404.GT29414@redhat.com> <20161128130916.GV29414@redhat.com> Message-ID: <20170216150200.GH4474@redhat.com> On Mon, Nov 28, 2016 at 03:09:51PM +0000, Deepak Dimri wrote: > Hi Jan, sorry to ask but where exactly i can modify the referer with RequestHeader on IPA Server? > I've now described the load-balancing setup for WebUI with FreeIPA replicas at https://www.adelton.com/freeipa/freeipa-behind-load-balancer Hope this helps, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From chek_chek at ukr.net Thu Feb 16 15:05:44 2017 From: chek_chek at ukr.net (Alexandr Slavov) Date: Thu, 16 Feb 2017 17:05:44 +0200 Subject: [Freeipa-users] Add IP-address client to error-log file In-Reply-To: <4b118fc7-49f4-a269-c776-ecf785284861@redhat.com> References: <1487158899.436858841.bxqi3dig@frv38.fwdcdn.com> <4b118fc7-49f4-a269-c776-ecf785284861@redhat.com> Message-ID: <1487257186.973828855.hyxs8a06@frv38.fwdcdn.com> Thanks ? for your response. I was added custom ErrorLogFormat? , but not resolved. I think this is python output information. Can your have any idea? Where can I open ticket about add this? Alexandr Slavov wrote: > Hello all. > We use CentOS 7 ,FreeIPA 4.4, Apache 2.4 > We installed audit system like > http://www.freeipa.org/page/Centralized_Logging for monitoring "Who's > What's Doing". > Audit system parsing /var/log/httpd/error_log and logging to Elasticsearch. > > Some string for Remove user from group in FreeIPA from > /var/log/httpd/error_log: > [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] ipa: INFO: > admin-user at DOMAIN.COM : batch: group_remove_member(u'somegroup', > user=u'someuser'): SUCCESS > > Parsed string loaded in Elasticsearch: > { > "_index": "logstash-2017.02.15", > "_type": "events", > "_id": "Uniq-ID", > "_score": null, > "_source": { > "timestamp": "2017-02-15T03:46:08-06:00", > "status": "SUCCESS", > "parameters": "'u'somegroup', user=u'someuser'", > "action": "group_remove_member", > "principal": "admin-user at DOMAIN.COM", > "pid": "31732", > "event.tags": [ > "ipa", > "ipa-call", > "batch" > ], > "host": "server-1", > "facility": "local0", > "severity": "notice", > "tag": "httpderror", > "message": " [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] > ipa: INFO: admin-user at DOMAIN.COM : batch: > group_remove_member(u'somegroup', user=u'someuser'): SUCCESS" > }, > "fields": { > "timestamp": [ > 1487151968000 > ] > }, > "sort": [ > 1487151968000 > ] > } > > > But we need add IP-address of admin-user at DOMAIN.COM outputting to > error_log. How can add IP-address to this error_log file ? See https://httpd.apache.org/docs/2.4/mod/core.html#errorlogformat You'd have to manually configure this on each master and ensure that it survives IPA updates. Alternatively you can open a ticket asking IPA to add this. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 16 15:13:50 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 16 Feb 2017 10:13:50 -0500 Subject: [Freeipa-users] Add IP-address client to error-log file In-Reply-To: <1487257186.973828855.hyxs8a06@frv38.fwdcdn.com> References: <1487158899.436858841.bxqi3dig@frv38.fwdcdn.com> <4b118fc7-49f4-a269-c776-ecf785284861@redhat.com> <1487257186.973828855.hyxs8a06@frv38.fwdcdn.com> Message-ID: <29bf7c49-6f3f-751d-1bc7-7e2bd8c3d4a5@redhat.com> Alexandr Slavov wrote: > Thanks for your response. > I was added custom ErrorLogFormat , but not resolved. > I think this is python output information. > > Can your have any idea? > > Where can I open ticket about add this? For the short term https://fedorahosted.org/freeipa/newticket You need a FAS (Fedora Account) to open one. rob > > Alexandr Slavov wrote: > > Hello all. > > We use CentOS 7 ,FreeIPA 4.4, Apache 2.4 > > We installed audit system like > > http://www.freeipa.org/page/Centralized_Logging for monitoring "Who's > > What's Doing". > > Audit system parsing /var/log/httpd/error_log and logging to Elasticsearch. > > > > Some string for Remove user from group in FreeIPA from > > /var/log/httpd/error_log: > > [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] ipa: INFO: > > admin-user at DOMAIN.COM : batch: group_remove_member(u'somegroup', > > user=u'someuser'): SUCCESS > > > > Parsed string loaded in Elasticsearch: > > { > > "_index": "logstash-2017.02.15", > > "_type": "events", > > "_id": "Uniq-ID", > > "_score": null, > > "_source": { > > "timestamp": "2017-02-15T03:46:08-06:00", > > "status": "SUCCESS", > > "parameters": "'u'somegroup', user=u'someuser'", > > "action": "group_remove_member", > > "principal": "admin-user at DOMAIN.COM", > > "pid": "31732", > > "event.tags": [ > > "ipa", > > "ipa-call", > > "batch" > > ], > > "host": "server-1", > > "facility": "local0", > > "severity": "notice", > > "tag": "httpderror", > > "message": " [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] > > ipa: INFO: admin-user at DOMAIN.COM : batch: > > group_remove_member(u'somegroup', user=u'someuser'): SUCCESS" > > }, > > "fields": { > > "timestamp": [ > > 1487151968000 > > ] > > }, > > "sort": [ > > 1487151968000 > > ] > > } > > > > > > But we need add IP-address of admin-user at DOMAIN.COM outputting to > > error_log. How can add IP-address to this error_log file ? > > See https://httpd.apache.org/docs/2.4/mod/core.html#errorlogformat > > You'd have to manually configure this on each master and ensure that it > survives IPA updates. > > Alternatively you can open a ticket asking IPA to add this. > > rob > From t.ruiten at rdmedia.com Thu Feb 16 16:21:12 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 16 Feb 2017 17:21:12 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server Message-ID: Hello, I'm trying to add a third replica to a FreeIPA 4.4 domain (level 1), but I'm getting this error: [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w "XXXXXXXXXX" > --mkhomedir --setup-dns --forwarder 8.8.8.8 --forwarder 8.8.4.4 > Checking DNS forwarders, please wait ... > Run connection check to master > Connection check OK > 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 (dirsrv). Estimated time: 1 minute > [1/44]: creating directory server user > [2/44]: creating directory server instance > [3/44]: updating configuration in dse.ldif > [4/44]: restarting directory server > [5/44]: adding default schema > [6/44]: enabling memberof plugin > [7/44]: enabling winsync plugin > [8/44]: configuring replication version plugin > [9/44]: enabling IPA enrollment plugin > [10/44]: enabling ldapi > [11/44]: configuring uniqueness plugin > [12/44]: configuring uuid plugin > [13/44]: configuring modrdn plugin > [14/44]: configuring DNS plugin > [15/44]: enabling entryUSN plugin > [16/44]: configuring lockout plugin > [17/44]: configuring topology plugin > [18/44]: creating indices > [19/44]: enabling referential integrity plugin > [20/44]: configuring certmap.conf > [21/44]: configure autobind for root > [22/44]: configure new location for managed entries > [23/44]: configure dirsrv ccache > [24/44]: enabling SASL mapping fallback > [25/44]: restarting directory server > [26/44]: creating DS keytab > [27/44]: retrieving DS Certificate > [28/44]: restarting directory server > ipa : CRITICAL Failed to restart the directory server (Command > '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' returned non-zero > exit status 1). See the installation log for details. > [29/44]: setting up initial replication > [error] error: [Errno 111] Connection refused > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > ipa.ipapython.install.cli.install_tool(Replica): ERROR [Errno 111] > Connection refused > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See /var/log/ipareplica-install.log for > more information In /var/log/ipareplica-install.log we find: 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS Certificate > 2017-02-16T15:53:59Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM IPA CA -a > 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 > 2017-02-16T15:53:59Z DEBUG stdout= > > *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find cert: > IPA.RDMEDIA.COM IPA CA: PR_FILE_NOT_FOUND_ERROR: > File not found* > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f > /etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt > 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 > 2017-02-16T15:53:59Z DEBUG stdout= > 2017-02-16T15:53:59Z DEBUG stderr= > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM IPA CA -t CT,C,C > -a > 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 > 2017-02-16T15:53:59Z DEBUG stdout= > 2017-02-16T15:53:59Z DEBUG stderr= > 2017-02-16T15:53:59Z DEBUG certmonger request is in state > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) > 2017-02-16T15:54:04Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > 2017-02-16T15:54:04Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket from SchemaCache > 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket > conn= > 2017-02-16T15:54:05Z DEBUG duration: 5 seconds > 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory server > 2017-02-16T15:54:05Z DEBUG Starting external process > 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system daemon-reload > 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 > 2017-02-16T15:54:05Z DEBUG stdout= > 2017-02-16T15:54:05Z DEBUG stderr= > 2017-02-16T15:54:05Z DEBUG Starting external process > 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart > dirsrv at IPA-RDMEDIA-COM.service > 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 > 2017-02-16T15:54:06Z DEBUG stdout= > 2017-02-16T15:54:06Z DEBUG stderr=Job for dirsrv at IPA-RDMEDIA-COM.service > failed because the control process exited with error code. See "systemctl > status dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for details. > 2017-02-16T15:54:06Z CRITICAL Failed to restart the directory server > (Command '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' returned > non-zero exit status 1). See the installation log for details. > 2017-02-16T15:54:06Z DEBUG duration: 1 seconds > 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial replication > 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 449, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 439, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 405, in __setup_replica > self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line > 118, in enable_replication_version_checking > conn.do_simple_bind(bindpw=dirman_passwd) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1665, > in do_simple_bind > self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1660, > in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1643, > in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1286, > in wait_for_open_socket > raise e > error: [Errno 111] Connection refused > 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] Connection refused > 2017-02-16T15:54:16Z DEBUG Destroyed connection context.ldap2_78478480 > 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", line > 318, in run > cfgr.run() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 310, in run > self.execute() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 332, in execute > for nothing in self._executor(): > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 586, in _configure > next(executor) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 63, in _install > for nothing in self._installer(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1714, in main > promote(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 364, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1415, in promote > promote=True, pkcs12_info=dirsrv_pkcs12_info) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 127, in install_replica_ds > api=remote_api, > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 399, in create_replica > self.start_creation(runtime=60) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 449, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 439, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 405, in __setup_replica > self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line > 118, in enable_replication_version_checking > conn.do_simple_bind(bindpw=dirman_passwd) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1665, > in do_simple_bind > self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1660, > in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1643, > in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1286, > in wait_for_open_socket > raise e > 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command failed, > exception: error: [Errno 111] Connection refused > 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused > 2017-02-16T15:54:16Z ERROR The ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > How can I troubleshoot this? -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Feb 16 16:29:10 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 16 Feb 2017 17:29:10 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: Message-ID: On 16.02.2017 17:21, Tiemen Ruiten wrote: > Hello, > > I'm trying to add a third replica to a FreeIPA 4.4 domain (level 1), > but I'm getting this error: > > [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w > "XXXXXXXXXX" --mkhomedir --setup-dns --forwarder 8.8.8.8 > --forwarder 8.8.4.4 > Checking DNS forwarders, please wait ... > Run connection check to master > Connection check OK > 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 (dirsrv). Estimated time: 1 minute > [1/44]: creating directory server user > [2/44]: creating directory server instance > [3/44]: updating configuration in dse.ldif > [4/44]: restarting directory server > [5/44]: adding default schema > [6/44]: enabling memberof plugin > [7/44]: enabling winsync plugin > [8/44]: configuring replication version plugin > [9/44]: enabling IPA enrollment plugin > [10/44]: enabling ldapi > [11/44]: configuring uniqueness plugin > [12/44]: configuring uuid plugin > [13/44]: configuring modrdn plugin > [14/44]: configuring DNS plugin > [15/44]: enabling entryUSN plugin > [16/44]: configuring lockout plugin > [17/44]: configuring topology plugin > [18/44]: creating indices > [19/44]: enabling referential integrity plugin > [20/44]: configuring certmap.conf > [21/44]: configure autobind for root > [22/44]: configure new location for managed entries > [23/44]: configure dirsrv ccache > [24/44]: enabling SASL mapping fallback > [25/44]: restarting directory server > [26/44]: creating DS keytab > [27/44]: retrieving DS Certificate > [28/44]: restarting directory server > ipa : CRITICAL Failed to restart the directory server > (Command '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' > returned non-zero exit status 1). See the installation log for > details. > [29/44]: setting up initial replication > [error] error: [Errno 111] Connection refused > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > ipa.ipapython.install.cli.install_tool(Replica): ERROR [Errno > 111] Connection refused > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > > In /var/log/ipareplica-install.log we find: > > 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS Certificate > 2017-02-16T15:53:59Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM > IPA CA -a > 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 > 2017-02-16T15:53:59Z DEBUG stdout= > *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find cert: > IPA.RDMEDIA.COM IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found* > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f > /etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt > 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 > 2017-02-16T15:53:59Z DEBUG stdout= > 2017-02-16T15:53:59Z DEBUG stderr= > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM > IPA CA -t CT,C,C -a > 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 > 2017-02-16T15:53:59Z DEBUG stdout= > 2017-02-16T15:53:59Z DEBUG stderr= > 2017-02-16T15:53:59Z DEBUG certmonger request is in state > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) > 2017-02-16T15:54:04Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > 2017-02-16T15:54:04Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket from SchemaCache > 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket > conn= > 2017-02-16T15:54:05Z DEBUG duration: 5 seconds > 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory server > 2017-02-16T15:54:05Z DEBUG Starting external process > 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system daemon-reload > 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 > 2017-02-16T15:54:05Z DEBUG stdout= > 2017-02-16T15:54:05Z DEBUG stderr= > 2017-02-16T15:54:05Z DEBUG Starting external process > 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart > dirsrv at IPA-RDMEDIA-COM.service > 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 > 2017-02-16T15:54:06Z DEBUG stdout= > 2017-02-16T15:54:06Z DEBUG stderr=Job for > dirsrv at IPA-RDMEDIA-COM.service failed because the control process > exited with error code. See "systemctl status > dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for details. > 2017-02-16T15:54:06Z CRITICAL Failed to restart the directory > server (Command '/bin/systemctl restart > dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit status 1). > See the installation log for details. > 2017-02-16T15:54:06Z DEBUG duration: 1 seconds > 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial replication > 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 449, in start_creation > run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 439, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 405, in __setup_replica > self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 118, in enable_replication_version_checking > conn.do_simple_bind(bindpw=dirman_passwd) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1665, in do_simple_bind > self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1660, in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1643, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", > line 1286, in wait_for_open_socket > raise e > error: [Errno 111] Connection refused > 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] Connection > refused > 2017-02-16T15:54:16Z DEBUG Destroyed connection context.ldap2_78478480 > 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", line > 318, in run > cfgr.run() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 310, in run > self.execute() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 332, in execute > for nothing in self._executor(): > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 362, in __runner > step() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 586, in _configure > next(executor) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 362, in __runner > step() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File > "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 63, in _install > for nothing in self._installer(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1714, in main > promote(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 364, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1415, in promote > promote=True, pkcs12_info=dirsrv_pkcs12_info) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 127, in install_replica_ds > api=remote_api, > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 399, in create_replica > self.start_creation(runtime=60) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 449, in start_creation > run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 439, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 405, in __setup_replica > self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 118, in enable_replication_version_checking > conn.do_simple_bind(bindpw=dirman_passwd) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1665, in do_simple_bind > self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1660, in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1643, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", > line 1286, in wait_for_open_socket > raise e > 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command failed, > exception: error: [Errno 111] Connection refused > 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused > 2017-02-16T15:54:16Z ERROR The ipa-replica-install command failed. > See /var/log/ipareplica-install.log for more information > > > How can I troubleshoot this? > > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > > Hello, please check /var/log/dirsrv/slapd-*/errors log on both master and replica Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgoddard at emerlyn.com Thu Feb 16 16:29:26 2017 From: jgoddard at emerlyn.com (Jeff Goddard) Date: Thu, 16 Feb 2017 11:29:26 -0500 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: Message-ID: Might be another instance of this: https://fedorahosted.org/freeipa/ticket/6613 Jeff On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten wrote: > Hello, > > I'm trying to add a third replica to a FreeIPA 4.4 domain (level 1), but > I'm getting this error: > > [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w "XXXXXXXXXX" >> --mkhomedir --setup-dns --forwarder 8.8.8.8 --forwarder 8.8.4.4 >> Checking DNS forwarders, please wait ... >> Run connection check to master >> Connection check OK >> 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 (dirsrv). Estimated time: 1 minute >> [1/44]: creating directory server user >> [2/44]: creating directory server instance >> [3/44]: updating configuration in dse.ldif >> [4/44]: restarting directory server >> [5/44]: adding default schema >> [6/44]: enabling memberof plugin >> [7/44]: enabling winsync plugin >> [8/44]: configuring replication version plugin >> [9/44]: enabling IPA enrollment plugin >> [10/44]: enabling ldapi >> [11/44]: configuring uniqueness plugin >> [12/44]: configuring uuid plugin >> [13/44]: configuring modrdn plugin >> [14/44]: configuring DNS plugin >> [15/44]: enabling entryUSN plugin >> [16/44]: configuring lockout plugin >> [17/44]: configuring topology plugin >> [18/44]: creating indices >> [19/44]: enabling referential integrity plugin >> [20/44]: configuring certmap.conf >> [21/44]: configure autobind for root >> [22/44]: configure new location for managed entries >> [23/44]: configure dirsrv ccache >> [24/44]: enabling SASL mapping fallback >> [25/44]: restarting directory server >> [26/44]: creating DS keytab >> [27/44]: retrieving DS Certificate >> [28/44]: restarting directory server >> ipa : CRITICAL Failed to restart the directory server (Command >> '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' returned >> non-zero exit status 1). See the installation log for details. >> [29/44]: setting up initial replication >> [error] error: [Errno 111] Connection refused >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> ipa.ipapython.install.cli.install_tool(Replica): ERROR [Errno 111] >> Connection refused >> ipa.ipapython.install.cli.install_tool(Replica): ERROR The >> ipa-replica-install command failed. See /var/log/ipareplica-install.log >> for more information > > > In /var/log/ipareplica-install.log we find: > > 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS Certificate >> 2017-02-16T15:53:59Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2017-02-16T15:53:59Z DEBUG Starting external process >> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM IPA CA -a >> 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 >> 2017-02-16T15:53:59Z DEBUG stdout= >> >> *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find cert: >> IPA.RDMEDIA.COM IPA CA: PR_FILE_NOT_FOUND_ERROR: >> File not found* >> 2017-02-16T15:53:59Z DEBUG Starting external process >> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f /etc/dirsrv/slapd-IPA-RDMEDIA- >> COM//pwdfile.txt >> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >> 2017-02-16T15:53:59Z DEBUG stdout= >> 2017-02-16T15:53:59Z DEBUG stderr= >> 2017-02-16T15:53:59Z DEBUG Starting external process >> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM IPA CA -t >> CT,C,C -a >> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >> 2017-02-16T15:53:59Z DEBUG stdout= >> 2017-02-16T15:53:59Z DEBUG stderr= >> 2017-02-16T15:53:59Z DEBUG certmonger request is in state >> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) >> 2017-02-16T15:54:04Z DEBUG certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> 2017-02-16T15:54:04Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >> from SchemaCache >> 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >> conn= >> 2017-02-16T15:54:05Z DEBUG duration: 5 seconds >> 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory server >> 2017-02-16T15:54:05Z DEBUG Starting external process >> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system daemon-reload >> 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 >> 2017-02-16T15:54:05Z DEBUG stdout= >> 2017-02-16T15:54:05Z DEBUG stderr= >> 2017-02-16T15:54:05Z DEBUG Starting external process >> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart >> dirsrv at IPA-RDMEDIA-COM.service >> 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 >> 2017-02-16T15:54:06Z DEBUG stdout= >> 2017-02-16T15:54:06Z DEBUG stderr=Job for dirsrv at IPA-RDMEDIA-COM.service >> failed because the control process exited with error code. See "systemctl >> status dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for details. >> 2017-02-16T15:54:06Z CRITICAL Failed to restart the directory server >> (Command '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' >> returned non-zero exit status 1). See the installation log for details. >> 2017-02-16T15:54:06Z DEBUG duration: 1 seconds >> 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial replication >> 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 449, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 439, in run_step >> method() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >> line 405, in __setup_replica >> self.dm_password) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >> line 118, in enable_replication_version_checking >> conn.do_simple_bind(bindpw=dirman_passwd) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1665, in do_simple_bind >> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1660, in __bind_with_wait >> self.__wait_for_connection(timeout) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1643, in __wait_for_connection >> wait_for_open_socket(lurl.hostport, timeout) >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >> 1286, in wait_for_open_socket >> raise e >> error: [Errno 111] Connection refused >> 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] Connection refused >> 2017-02-16T15:54:16Z DEBUG Destroyed connection context.ldap2_78478480 >> 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", line >> 318, in run >> cfgr.run() >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 310, in run >> self.execute() >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 332, in execute >> for nothing in self._executor(): >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 372, in __runner >> self._handle_exception(exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 394, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 362, in __runner >> step() >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 359, in >> step = lambda: next(self.__gen) >> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line 81, in run_generator_with_yield_from >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line 59, in run_generator_with_yield_from >> value = gen.send(prev_value) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 586, in _configure >> next(executor) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 372, in __runner >> self._handle_exception(exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 449, in _handle_exception >> self.__parent._handle_exception(exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 394, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 446, in _handle_exception >> super(ComponentBase, self)._handle_exception(exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 394, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 362, in __runner >> step() >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 359, in >> step = lambda: next(self.__gen) >> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line 81, in run_generator_with_yield_from >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line 59, in run_generator_with_yield_from >> value = gen.send(prev_value) >> File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", >> line 63, in _install >> for nothing in self._installer(self.parent): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >> line 1714, in main >> promote(self) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >> line 364, in decorated >> func(installer) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >> line 1415, in promote >> promote=True, pkcs12_info=dirsrv_pkcs12_info) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >> line 127, in install_replica_ds >> api=remote_api, >> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >> line 399, in create_replica >> self.start_creation(runtime=60) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 449, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 439, in run_step >> method() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >> line 405, in __setup_replica >> self.dm_password) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >> line 118, in enable_replication_version_checking >> conn.do_simple_bind(bindpw=dirman_passwd) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1665, in do_simple_bind >> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1660, in __bind_with_wait >> self.__wait_for_connection(timeout) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1643, in __wait_for_connection >> wait_for_open_socket(lurl.hostport, timeout) >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >> 1286, in wait_for_open_socket >> raise e >> 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command failed, >> exception: error: [Errno 111] Connection refused >> 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused >> 2017-02-16T15:54:16Z ERROR The ipa-replica-install command failed. See >> /var/log/ipareplica-install.log for more information >> > > How can I troubleshoot this? > > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > > -- > 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 t.ruiten at rdmedia.com Thu Feb 16 17:23:30 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 16 Feb 2017 18:23:30 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: Message-ID: @Martin: No messages are generated in the errors log during the failed replica install, there are some warnings, but they are generated at different times and they don't look related. @Jeff, I did see that on one of the existing masters the listener was configured to be "::1". I changed it to 127.0.0.1 but no difference. I commented the ::1 localhost entry in /etc/hosts on all three nodes, no difference either. My journal looks the same as in the bugreport you linked: Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.445272051 +0100] SSL alert: Security Initialization: > Can't find certificate (Server-Cert) for family > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.445891468 +0100] SSL alert: Security Initialization: > Unable to retrieve private key for cert Server-Cert of family > cn=RSA,cn=encryption,cn=config (Netscape Po > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.446420819 +0100] SSL failure: None of the cipher are > valid > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.446913819 +0100] ERROR: SSL2 Initialization Failed. > Disabling SSL2. > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.447550894 +0100] 389-Directory/1.3.5.10 > B2017.017.2314 starting up > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.460575142 +0100] default_mr_indexer_create: warning - > plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.470162594 +0100] Can't find certificate Server-Cert > in attrcrypt_fetch_private_key: -8174 - security library: bad database. > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.470985550 +0100] Can't get private key from cert > Server-Cert in attrcrypt_fetch_private_key: -8174 - security library: bad > database. > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.471763716 +0100] Error: unable to initialize > attrcrypt system for userRoot > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.472487718 +0100] start: Failed to start databases, > err=-1 BDB0092 Unknown error: -1 > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.473207435 +0100] Failed to start database plugin ldbm > database > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.475663288 +0100] WARNING: ldbm instance userRoot > already exists > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.476418009 +0100] ldbm_config_read_instance_entries: > failed to add instance entry cn=userRoot,cn=ldbm > database,cn=plugins,cn=config > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.477152165 +0100] ldbm_config_load_dse_info: failed to > read instance entries > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.477915898 +0100] start: Loading database > configuration failed > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.478593267 +0100] Failed to start database plugin ldbm > database > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.479243074 +0100] Error: Failed to resolve plugin > dependencies > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.479836990 +0100] Error: betxnpreoperation plugin > 7-bit check is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.480476048 +0100] Error: preoperation plugin Account > Usability Plugin is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.481116304 +0100] Error: accesscontrol plugin ACL > Plugin is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.482357723 +0100] Error: preoperation plugin ACL > preoperation is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.483158681 +0100] Error: betxnpreoperation plugin Auto > Membership Plugin is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.483763046 +0100] Error: object plugin Class of > Service is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.484398389 +0100] Error: preoperation plugin deref is > not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.485001277 +0100] Error: preoperation plugin HTTP > Client is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.485612725 +0100] Error: preoperation plugin IPA DNS > is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.486187470 +0100] Error: object plugin IPA Lockout is > not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.486740705 +0100] Error: betxnpostoperation plugin IPA > MODRDN is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.487279020 +0100] Error: object plugin IPA Topology > Configuration is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.487830515 +0100] Error: preoperation plugin IPA UUID > is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.488373342 +0100] Error: preoperation plugin > ipa-winsync is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.488953343 +0100] Error: extendedop plugin > ipa_enrollment_extop is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.489516092 +0100] Error: preoperation plugin > ipaUniqueID uniqueness is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.490054133 +0100] Error: preoperation plugin > krbCanonicalName uniqueness is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.490606671 +0100] Error: preoperation plugin > krbPrincipalName uniqueness is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.491143361 +0100] Error: database plugin ldbm database > is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.491698168 +0100] Error: object plugin Legacy > Replication Plugin is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.492236304 +0100] Error: betxnpreoperation plugin > Linked Attributes is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.492790717 +0100] Error: betxnpreoperation plugin > Managed Entries is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.493383474 +0100] Error: betxnpostoperation plugin > MemberOf Plugin is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.493949979 +0100] Error: object plugin Multimaster > Replication Plugin is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.495205267 +0100] Error: preoperation plugin netgroup > uniqueness is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.496041114 +0100] Error: betxnpostoperation plugin > referential integrity postoperation is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.496686920 +0100] Error: object plugin Roles Plugin is > not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.497192324 +0100] Error: preoperation plugin sudorule > name uniqueness is not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.497704125 +0100] Error: object plugin USN is not > started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.498202061 +0100] Error: object plugin Views is not > started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com ns-slapd[6200]: > [16/Feb/2017:18:12:05.498711263 +0100] Error: extendedop plugin whoami is > not started > Feb 16 18:12:05 copernicum.ipa.rdmedia.com systemd[1]: > dirsrv at IPA-RDMEDIA-COM.service: main process exited, code=exited, > status=1/FAILURE > Feb 16 18:12:05 copernicum.ipa.rdmedia.com systemd[1]: Failed to start > 389 Directory Server IPA-RDMEDIA-COM.. On 16 February 2017 at 17:29, Jeff Goddard wrote: > Might be another instance of this: https://fedorahosted.org/ > freeipa/ticket/6613 > > Jeff > > On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten > wrote: > >> Hello, >> >> I'm trying to add a third replica to a FreeIPA 4.4 domain (level 1), but >> I'm getting this error: >> >> [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w "XXXXXXXXXX" >>> --mkhomedir --setup-dns --forwarder 8.8.8.8 --forwarder 8.8.4.4 >>> Checking DNS forwarders, please wait ... >>> Run connection check to master >>> Connection check OK >>> 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 (dirsrv). Estimated time: 1 minute >>> [1/44]: creating directory server user >>> [2/44]: creating directory server instance >>> [3/44]: updating configuration in dse.ldif >>> [4/44]: restarting directory server >>> [5/44]: adding default schema >>> [6/44]: enabling memberof plugin >>> [7/44]: enabling winsync plugin >>> [8/44]: configuring replication version plugin >>> [9/44]: enabling IPA enrollment plugin >>> [10/44]: enabling ldapi >>> [11/44]: configuring uniqueness plugin >>> [12/44]: configuring uuid plugin >>> [13/44]: configuring modrdn plugin >>> [14/44]: configuring DNS plugin >>> [15/44]: enabling entryUSN plugin >>> [16/44]: configuring lockout plugin >>> [17/44]: configuring topology plugin >>> [18/44]: creating indices >>> [19/44]: enabling referential integrity plugin >>> [20/44]: configuring certmap.conf >>> [21/44]: configure autobind for root >>> [22/44]: configure new location for managed entries >>> [23/44]: configure dirsrv ccache >>> [24/44]: enabling SASL mapping fallback >>> [25/44]: restarting directory server >>> [26/44]: creating DS keytab >>> [27/44]: retrieving DS Certificate >>> [28/44]: restarting directory server >>> ipa : CRITICAL Failed to restart the directory server (Command >>> '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' returned >>> non-zero exit status 1). See the installation log for details. >>> [29/44]: setting up initial replication >>> [error] error: [Errno 111] Connection refused >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR [Errno 111] >>> Connection refused >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR The >>> ipa-replica-install command failed. See /var/log/ipareplica-install.log >>> for more information >> >> >> In /var/log/ipareplica-install.log we find: >> >> 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS Certificate >>> 2017-02-16T15:53:59Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM IPA CA -a >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> >>> *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find cert: >>> IPA.RDMEDIA.COM IPA CA: PR_FILE_NOT_FOUND_ERROR: >>> File not found* >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f /etc/dirsrv/slapd-IPA-RDMEDIA- >>> COM//pwdfile.txt >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> 2017-02-16T15:53:59Z DEBUG stderr= >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM IPA CA -t >>> CT,C,C -a >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> 2017-02-16T15:53:59Z DEBUG stderr= >>> 2017-02-16T15:53:59Z DEBUG certmonger request is in state >>> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) >>> 2017-02-16T15:54:04Z DEBUG certmonger request is in state >>> dbus.String(u'CA_UNREACHABLE', variant_level=1) >>> 2017-02-16T15:54:04Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>> from SchemaCache >>> 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache >>> url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>> conn= >>> 2017-02-16T15:54:05Z DEBUG duration: 5 seconds >>> 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory server >>> 2017-02-16T15:54:05Z DEBUG Starting external process >>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system daemon-reload >>> 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:54:05Z DEBUG stdout= >>> 2017-02-16T15:54:05Z DEBUG stderr= >>> 2017-02-16T15:54:05Z DEBUG Starting external process >>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart >>> dirsrv at IPA-RDMEDIA-COM.service >>> 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 >>> 2017-02-16T15:54:06Z DEBUG stdout= >>> 2017-02-16T15:54:06Z DEBUG stderr=Job for dirsrv at IPA-RDMEDIA-COM.service >>> failed because the control process exited with error code. See "systemctl >>> status dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for details. >>> 2017-02-16T15:54:06Z CRITICAL Failed to restart the directory server >>> (Command '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' >>> returned non-zero exit status 1). See the installation log for details. >>> 2017-02-16T15:54:06Z DEBUG duration: 1 seconds >>> 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial replication >>> 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 449, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 439, in run_step >>> method() >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>> line 405, in __setup_replica >>> self.dm_password) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>> line 118, in enable_replication_version_checking >>> conn.do_simple_bind(bindpw=dirman_passwd) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1665, in do_simple_bind >>> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1660, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1643, in __wait_for_connection >>> wait_for_open_socket(lurl.hostport, timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>> 1286, in wait_for_open_socket >>> raise e >>> error: [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] Connection >>> refused >>> 2017-02-16T15:54:16Z DEBUG Destroyed connection context.ldap2_78478480 >>> 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", >>> line 318, in run >>> cfgr.run() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 310, in run >>> self.execute() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 332, in execute >>> for nothing in self._executor(): >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 372, in __runner >>> self._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 394, in _handle_exception >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 362, in __runner >>> step() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 359, in >>> step = lambda: next(self.__gen) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 81, in run_generator_with_yield_from >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 59, in run_generator_with_yield_from >>> value = gen.send(prev_value) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 586, in _configure >>> next(executor) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 372, in __runner >>> self._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 449, in _handle_exception >>> self.__parent._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 394, in _handle_exception >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 446, in _handle_exception >>> super(ComponentBase, self)._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 394, in _handle_exception >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 362, in __runner >>> step() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 359, in >>> step = lambda: next(self.__gen) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 81, in run_generator_with_yield_from >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 59, in run_generator_with_yield_from >>> value = gen.send(prev_value) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", >>> line 63, in _install >>> for nothing in self._installer(self.parent): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 1714, in main >>> promote(self) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 364, in decorated >>> func(installer) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 1415, in promote >>> promote=True, pkcs12_info=dirsrv_pkcs12_info) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 127, in install_replica_ds >>> api=remote_api, >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>> line 399, in create_replica >>> self.start_creation(runtime=60) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 449, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 439, in run_step >>> method() >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>> line 405, in __setup_replica >>> self.dm_password) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>> line 118, in enable_replication_version_checking >>> conn.do_simple_bind(bindpw=dirman_passwd) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1665, in do_simple_bind >>> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1660, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1643, in __wait_for_connection >>> wait_for_open_socket(lurl.hostport, timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>> 1286, in wait_for_open_socket >>> raise e >>> 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command failed, >>> exception: error: [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z ERROR The ipa-replica-install command failed. See >>> /var/log/ipareplica-install.log for more information >>> >> >> How can I troubleshoot this? >> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> >> -- >> 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 >> > > > > > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Thu Feb 16 17:04:05 2017 From: jochen at jochen.org (Jochen Hein) Date: Thu, 16 Feb 2017 18:04:05 +0100 Subject: [Freeipa-users] Ubuntu client 2FA not working In-Reply-To: <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> (Tommy Nikjoo's message of "Mon, 6 Feb 2017 13:56:06 +0000") References: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> <20161214224809.GA4232@dhcp-40-8.bne.redhat.com> <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> Message-ID: <83zihmqd8a.fsf@jochen.org> Tommy Nikjoo writes: > I'm having some issues with 2FA PAM config's on Ubuntu clients. > Currently, I'm guessing that the PAM module doesn't know how to talk to > the 2FA protocol. Is anyone able to give an in site into how to get > this working correctly? You may need to fix /etc/pam.d/common-auth, so that only pam_sss get's called for IPA users: # here are the per-package modules (the "Primary" block) auth [default=1 success=ok] pam_localuser.so auth [success=3 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth [success=1 default=ignore] pam_sss.so forward_pass # here's the fallback if no module succeeds auth requisite pam_deny.so I'm running a 14.04 client with an older IPA client - there I have to enter password+OTP in one string and it works perfect. On my 16.10 Laptop I use IPA 4.3.2 against CentOS 7.3 server. That client had problems with OTP users which were not obvious to me. The system asked for first and second factor but would give me system error 7. I think the following entry in /etc/krb5.conf helped: [libdefaults] ... default_ccache_name = KEYRING:persistent:%{uid} [realms] ... Otherwise please enable the debug trace and review the logs. They are really verbose and you need to check both client and server for errors. There is hope - I run Ubuntu clients with OTP user (OTP is via privacyidea/radius, but that shouldn't matter). Jochen -- The only problem with troubleshooting is that the trouble shoots back. From yamakasi.014 at gmail.com Thu Feb 16 20:55:45 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 16 Feb 2017 21:55:45 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> Message-ID: Hi Flo! (if I may call you like that, saves some characters in typing but with this extra line it doesn't anymore :)) This works perfectly, thank you very much. No questions further actually :) Cheers, Matt 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : > On 02/15/2017 05:40 PM, Matt . wrote: >> >> Hi, >> >> Is there any update on this ? I need to install 3 other instances but >> I would like to know upfront if it might be a bug. >> > Hi Matt, > > I was not able to reproduce your issue. Here were my steps: > > Install FreeIPA with self-signed cert: > ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD > > The certificate chain is ca1 -> subca -> server. > Install the root CA: > kinit admin > ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem > ipa-certupdate > > Install the subca: > ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem > ipa-certupdate > > Install the server cert: > ipa-server-certinstall -d -w server.pem key.pem > > ipa-certupdate basically retrieves the certificates from LDAP (below > cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias but > I don't remember it removing certs. > > Can you check the content of your LDAP server? > kinit admin > ldapsearch -h `hostname` -p 389 -Y GSSAPI -b > cn=certificates,cn=ipa,cn=etc,$BASEDN > > It should contain one entry for each CA that you added. > > Flo. > >> Thanks, >> >> Matt >> >> 2017-02-14 17:59 GMT+01:00 Matt . : >>> >>> Hi Florance, >>> >>> Sure I can, here you go: >>> >>> Fedora 24 >>> Freeipa VERSION: 4.4.2, API_VERSION: 2.215 >>> >>> I installed this server as self-signed CA >>> >>> Cheers, >>> >>> Matt >>> >>> >>> >>> >>> 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : >>>> >>>> On 02/14/2017 05:43 PM, Matt . wrote: >>>>> >>>>> >>>>> Hi Florance, >>>>> >>>>> Thanks for your update, good to see some good into about it. For >>>>> Comodo I have install all these: >>>>> >>>>> AddTrustExternalCARoot.crt >>>>> COMODORSAAddTrustCA.crt >>>>> COMODORSADomainValidationSecureServerCA.crt >>>>> >>>>> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >>>>> far as I know but the same issues still exist, the Server-Cert is >>>>> removed again on ipa-certupdate and fails. >>>>> >>>>> I have tried this with setenforce 0 >>>>> >>>> Hi Matt, >>>> >>>> can you provide more info in order to reproduce the issue? >>>> - which OS are you using >>>> - IPA version >>>> - how did you install ipa server (CA-less or with self-signed CA or with >>>> externally-signed CA?) >>>> >>>> Thanks, >>>> Flo. >>>> >>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>>>>> >>>>>> >>>>>> On 02/14/2017 02:54 PM, Matt . wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Certs are valid, I will check what you mentioned. >>>>>>> >>>>>>> I'm also no fan of bundles, more the seperate files but this doesn't >>>>>>> seem to work always. At least for the CAroot a bundle was required. >>>>>>> >>>>>> Hi Matt, >>>>>> >>>>>> if your certificate was provided by an intermediate CA, you need to >>>>>> add >>>>>> each >>>>>> CA before running ipa-server-certinstall (start from the top-level CA >>>>>> with >>>>>> ipa-cacert-manage install, then run ipa-certupdate, then the >>>>>> intermediate >>>>>> CA >>>>>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>>>>> >>>>>> There is also a known issue with ipa-certupdate and SELinux in >>>>>> enforcing >>>>>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>>>>> >>>>>> Flo. >>>>>> >>>>>> >>>>>>> Matt >>>>>>> >>>>>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Have you validated the cert (and dumped the contents) from the >>>>>>>> command >>>>>>>> line using the openssl tools? I?ve seen the message you are seeing >>>>>>>> before, >>>>>>>> for some reason I seem to remember that it has to do with either a >>>>>>>> missing >>>>>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>>>>> CERTIFICATE---- (an error from copy and pasting and not copying the >>>>>>>> actual >>>>>>>> file). >>>>>>>> >>>>>>>> I?ve never used certupdate so if what is described above doesn?t >>>>>>>> help >>>>>>>> somebody else will have to chime in. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>>>>>>>> >>>>>>>>> Hi Dan, >>>>>>>>> >>>>>>>>> Ues i have tried that and I get the message that it misses the full >>>>>>>>> chain for the certificate. >>>>>>>>> >>>>>>>>> My issue is more, why is the Server-Cert being removed on a >>>>>>>>> certupdate >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with >>>>>>>>>> the >>>>>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Guys, >>>>>>>>>>> >>>>>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>>>>> >>>>>>>>>>> When I run the install command for the certificate itself: >>>>>>>>>>> >>>>>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>>>>> mydomain_com_bundle.crt >>>>>>>>>>> Directory Manager password: >>>>>>>>>>> >>>>>>>>>>> Enter private key unlock password: >>>>>>>>>>> >>>>>>>>>>> list index out of range >>>>>>>>>>> The ipa-server-certinstall command failed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>>>>> >>>>>>>>>>> What can I do to solve this ? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 flo at redhat.com Thu Feb 16 22:55:50 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 16 Feb 2017 23:55:50 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> Message-ID: <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> On 02/16/2017 09:55 PM, Matt . wrote: > Hi Flo! (if I may call you like that, saves some characters in typing > but with this extra line it doesn't anymore :)) > > This works perfectly, thank you very much. > Hi Matt, glad I could help. What did you do differently that could explain the failure, though? Maybe the cert installation needs some hardening. Flo. > No questions further actually :) > > Cheers, > > Matt > > 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >> On 02/15/2017 05:40 PM, Matt . wrote: >>> >>> Hi, >>> >>> Is there any update on this ? I need to install 3 other instances but >>> I would like to know upfront if it might be a bug. >>> >> Hi Matt, >> >> I was not able to reproduce your issue. Here were my steps: >> >> Install FreeIPA with self-signed cert: >> ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD >> >> The certificate chain is ca1 -> subca -> server. >> Install the root CA: >> kinit admin >> ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem >> ipa-certupdate >> >> Install the subca: >> ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem >> ipa-certupdate >> >> Install the server cert: >> ipa-server-certinstall -d -w server.pem key.pem >> >> ipa-certupdate basically retrieves the certificates from LDAP (below >> cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias but >> I don't remember it removing certs. >> >> Can you check the content of your LDAP server? >> kinit admin >> ldapsearch -h `hostname` -p 389 -Y GSSAPI -b >> cn=certificates,cn=ipa,cn=etc,$BASEDN >> >> It should contain one entry for each CA that you added. >> >> Flo. >> >>> Thanks, >>> >>> Matt >>> >>> 2017-02-14 17:59 GMT+01:00 Matt . : >>>> >>>> Hi Florance, >>>> >>>> Sure I can, here you go: >>>> >>>> Fedora 24 >>>> Freeipa VERSION: 4.4.2, API_VERSION: 2.215 >>>> >>>> I installed this server as self-signed CA >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> >>>> >>>> >>>> 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : >>>>> >>>>> On 02/14/2017 05:43 PM, Matt . wrote: >>>>>> >>>>>> >>>>>> Hi Florance, >>>>>> >>>>>> Thanks for your update, good to see some good into about it. For >>>>>> Comodo I have install all these: >>>>>> >>>>>> AddTrustExternalCARoot.crt >>>>>> COMODORSAAddTrustCA.crt >>>>>> COMODORSADomainValidationSecureServerCA.crt >>>>>> >>>>>> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >>>>>> far as I know but the same issues still exist, the Server-Cert is >>>>>> removed again on ipa-certupdate and fails. >>>>>> >>>>>> I have tried this with setenforce 0 >>>>>> >>>>> Hi Matt, >>>>> >>>>> can you provide more info in order to reproduce the issue? >>>>> - which OS are you using >>>>> - IPA version >>>>> - how did you install ipa server (CA-less or with self-signed CA or with >>>>> externally-signed CA?) >>>>> >>>>> Thanks, >>>>> Flo. >>>>> >>>>> >>>>>> Cheers, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>>>>>> >>>>>>> >>>>>>> On 02/14/2017 02:54 PM, Matt . wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Certs are valid, I will check what you mentioned. >>>>>>>> >>>>>>>> I'm also no fan of bundles, more the seperate files but this doesn't >>>>>>>> seem to work always. At least for the CAroot a bundle was required. >>>>>>>> >>>>>>> Hi Matt, >>>>>>> >>>>>>> if your certificate was provided by an intermediate CA, you need to >>>>>>> add >>>>>>> each >>>>>>> CA before running ipa-server-certinstall (start from the top-level CA >>>>>>> with >>>>>>> ipa-cacert-manage install, then run ipa-certupdate, then the >>>>>>> intermediate >>>>>>> CA >>>>>>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>>>>>> >>>>>>> There is also a known issue with ipa-certupdate and SELinux in >>>>>>> enforcing >>>>>>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>>>>>> >>>>>>> Flo. >>>>>>> >>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Have you validated the cert (and dumped the contents) from the >>>>>>>>> command >>>>>>>>> line using the openssl tools? I?ve seen the message you are seeing >>>>>>>>> before, >>>>>>>>> for some reason I seem to remember that it has to do with either a >>>>>>>>> missing >>>>>>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>>>>>> CERTIFICATE---- (an error from copy and pasting and not copying the >>>>>>>>> actual >>>>>>>>> file). >>>>>>>>> >>>>>>>>> I?ve never used certupdate so if what is described above doesn?t >>>>>>>>> help >>>>>>>>> somebody else will have to chime in. >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>>> On Feb 14, 2017, at 2:18 AM, Matt . wrote: >>>>>>>>>> >>>>>>>>>> Hi Dan, >>>>>>>>>> >>>>>>>>>> Ues i have tried that and I get the message that it misses the full >>>>>>>>>> chain for the certificate. >>>>>>>>>> >>>>>>>>>> My issue is more, why is the Server-Cert being removed on a >>>>>>>>>> certupdate >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with >>>>>>>>>>> the >>>>>>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Guys, >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>>>>>> >>>>>>>>>>>> When I run the install command for the certificate itself: >>>>>>>>>>>> >>>>>>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>>>>>> mydomain_com_bundle.crt >>>>>>>>>>>> Directory Manager password: >>>>>>>>>>>> >>>>>>>>>>>> Enter private key unlock password: >>>>>>>>>>>> >>>>>>>>>>>> list index out of range >>>>>>>>>>>> The ipa-server-certinstall command failed. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>>>>>> >>>>>>>>>>>> What can I do to solve this ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 william.muriithi at gmail.com Thu Feb 16 23:05:48 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 16 Feb 2017 18:05:48 -0500 Subject: [Freeipa-users] How to change kerberos key lifetime? In-Reply-To: <20170216134830.GE6059@dkupka.usersys.redhat.com> References: <20170216072250.GA6059@dkupka.usersys.redhat.com> <20170216134830.GE6059@dkupka.usersys.redhat.com> Message-ID: David > > The fact that your desktops are using SSSD changes the situation dramatically. > > SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in. > And can be configured to renew the ticket for the user until the ticket renew > life time expires. > > Given this you can keep ticket life time reasonable short (~1 day) set ticket > renewable life time to longer period (~2 weeks) and maintain reasonable > security level without negative impact on user's daily work. > > Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options > in sssd-krb5 man page. > Thanks a lot. I did actually end up using this. Will wait for a couple of days and see if anybody if the situation is better and update you. Curious though, why isn't renewal interval setup by default? Is there a negative consequence of having SSSD renewing tickets by default? I can't think of any and hence a bit lost on explaining the default setup > -- Regards, William From yamakasi.014 at gmail.com Thu Feb 16 23:15:08 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 17 Feb 2017 00:15:08 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> Message-ID: Hi Flo, Sure I can, I will look through the steps closely tomorrow and will create some lineup here. Cheers, Matt 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud : > On 02/16/2017 09:55 PM, Matt . wrote: >> >> Hi Flo! (if I may call you like that, saves some characters in typing >> but with this extra line it doesn't anymore :)) >> >> This works perfectly, thank you very much. >> > Hi Matt, > > glad I could help. What did you do differently that could explain the > failure, though? Maybe the cert installation needs some hardening. > > Flo. > >> No questions further actually :) >> >> Cheers, >> >> Matt >> >> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >>> >>> On 02/15/2017 05:40 PM, Matt . wrote: >>>> >>>> >>>> Hi, >>>> >>>> Is there any update on this ? I need to install 3 other instances but >>>> I would like to know upfront if it might be a bug. >>>> >>> Hi Matt, >>> >>> I was not able to reproduce your issue. Here were my steps: >>> >>> Install FreeIPA with self-signed cert: >>> ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD >>> >>> The certificate chain is ca1 -> subca -> server. >>> Install the root CA: >>> kinit admin >>> ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem >>> ipa-certupdate >>> >>> Install the subca: >>> ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem >>> ipa-certupdate >>> >>> Install the server cert: >>> ipa-server-certinstall -d -w server.pem key.pem >>> >>> ipa-certupdate basically retrieves the certificates from LDAP (below >>> cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias >>> but >>> I don't remember it removing certs. >>> >>> Can you check the content of your LDAP server? >>> kinit admin >>> ldapsearch -h `hostname` -p 389 -Y GSSAPI -b >>> cn=certificates,cn=ipa,cn=etc,$BASEDN >>> >>> It should contain one entry for each CA that you added. >>> >>> Flo. >>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> 2017-02-14 17:59 GMT+01:00 Matt . : >>>>> >>>>> >>>>> Hi Florance, >>>>> >>>>> Sure I can, here you go: >>>>> >>>>> Fedora 24 >>>>> Freeipa VERSION: 4.4.2, API_VERSION: 2.215 >>>>> >>>>> I installed this server as self-signed CA >>>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> >>>>> >>>>> >>>>> 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : >>>>>> >>>>>> >>>>>> On 02/14/2017 05:43 PM, Matt . wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Florance, >>>>>>> >>>>>>> Thanks for your update, good to see some good into about it. For >>>>>>> Comodo I have install all these: >>>>>>> >>>>>>> AddTrustExternalCARoot.crt >>>>>>> COMODORSAAddTrustCA.crt >>>>>>> COMODORSADomainValidationSecureServerCA.crt >>>>>>> >>>>>>> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >>>>>>> far as I know but the same issues still exist, the Server-Cert is >>>>>>> removed again on ipa-certupdate and fails. >>>>>>> >>>>>>> I have tried this with setenforce 0 >>>>>>> >>>>>> Hi Matt, >>>>>> >>>>>> can you provide more info in order to reproduce the issue? >>>>>> - which OS are you using >>>>>> - IPA version >>>>>> - how did you install ipa server (CA-less or with self-signed CA or >>>>>> with >>>>>> externally-signed CA?) >>>>>> >>>>>> Thanks, >>>>>> Flo. >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 02/14/2017 02:54 PM, Matt . wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Certs are valid, I will check what you mentioned. >>>>>>>>> >>>>>>>>> I'm also no fan of bundles, more the seperate files but this >>>>>>>>> doesn't >>>>>>>>> seem to work always. At least for the CAroot a bundle was required. >>>>>>>>> >>>>>>>> Hi Matt, >>>>>>>> >>>>>>>> if your certificate was provided by an intermediate CA, you need to >>>>>>>> add >>>>>>>> each >>>>>>>> CA before running ipa-server-certinstall (start from the top-level >>>>>>>> CA >>>>>>>> with >>>>>>>> ipa-cacert-manage install, then run ipa-certupdate, then the >>>>>>>> intermediate >>>>>>>> CA >>>>>>>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>>>>>>> >>>>>>>> There is also a known issue with ipa-certupdate and SELinux in >>>>>>>> enforcing >>>>>>>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>>>>>>> >>>>>>>> Flo. >>>>>>>> >>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Have you validated the cert (and dumped the contents) from the >>>>>>>>>> command >>>>>>>>>> line using the openssl tools? I?ve seen the message you are >>>>>>>>>> seeing >>>>>>>>>> before, >>>>>>>>>> for some reason I seem to remember that it has to do with either a >>>>>>>>>> missing >>>>>>>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>>>>>>> CERTIFICATE---- (an error from copy and pasting and not copying >>>>>>>>>> the >>>>>>>>>> actual >>>>>>>>>> file). >>>>>>>>>> >>>>>>>>>> I?ve never used certupdate so if what is described above doesn?t >>>>>>>>>> help >>>>>>>>>> somebody else will have to chime in. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>>> On Feb 14, 2017, at 2:18 AM, Matt . >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Dan, >>>>>>>>>>> >>>>>>>>>>> Ues i have tried that and I get the message that it misses the >>>>>>>>>>> full >>>>>>>>>>> chain for the certificate. >>>>>>>>>>> >>>>>>>>>>> My issue is more, why is the Server-Cert being removed on a >>>>>>>>>>> certupdate >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with >>>>>>>>>>>> the >>>>>>>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>>>>>>> >>>>>>>>>>>> Dan >>>>>>>>>>>> >>>>>>>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Guys, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>>>>>>> >>>>>>>>>>>>> When I run the install command for the certificate itself: >>>>>>>>>>>>> >>>>>>>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>>>>>>> mydomain_com_bundle.crt >>>>>>>>>>>>> Directory Manager password: >>>>>>>>>>>>> >>>>>>>>>>>>> Enter private key unlock password: >>>>>>>>>>>>> >>>>>>>>>>>>> list index out of range >>>>>>>>>>>>> The ipa-server-certinstall command failed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>>>>>>> >>>>>>>>>>>>> What can I do to solve this ? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Matt >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 r3pek at r3pek.org Thu Feb 16 23:25:19 2017 From: r3pek at r3pek.org (Carlos Silva) Date: Thu, 16 Feb 2017 23:25:19 +0000 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: Message-ID: On Thu, Feb 16, 2017 at 5:23 PM, Tiemen Ruiten wrote: > @Jeff, I did see that on one of the existing masters the listener was > configured to be "::1". I changed it to 127.0.0.1 but no difference. I > commented the ::1 localhost entry in /etc/hosts on all three nodes, no > difference either. My journal looks the same as in the bugreport you linked: > You did restart the service right? (Just to be sure) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Fri Feb 17 06:49:41 2017 From: dkupka at redhat.com (David Kupka) Date: Fri, 17 Feb 2017 07:49:41 +0100 Subject: [Freeipa-users] How to change kerberos key lifetime? In-Reply-To: References: <20170216072250.GA6059@dkupka.usersys.redhat.com> <20170216134830.GE6059@dkupka.usersys.redhat.com> Message-ID: <20170217064940.GB3231@dkupka.usersys.redhat.com> On Thu, Feb 16, 2017 at 06:05:48PM -0500, William Muriithi wrote: > David > > > > > > The fact that your desktops are using SSSD changes the situation dramatically. > > > > SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in. > > And can be configured to renew the ticket for the user until the ticket renew > > life time expires. > > > > Given this you can keep ticket life time reasonable short (~1 day) set ticket > > renewable life time to longer period (~2 weeks) and maintain reasonable > > security level without negative impact on user's daily work. > > > > Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options > > in sssd-krb5 man page. > > > Thanks a lot. I did actually end up using this. Will wait for a > couple of days and see if anybody if the situation is better and > update you. > > Curious though, why isn't renewal interval setup by default? Is there > a negative consequence of having SSSD renewing tickets by default? I > can't think of any and hence a bit lost on explaining the default > setup > > -- > Regards, > William Honestly, I don't know why krb5_renew_interval isn't set by default. My wild guess would be that in typical SSSD deployment user logs-in in the begining of work day, SSSD gets ticket that last for a day for him and he logs-out in the end of the workday (after 8~10 hours). So there's no need to refresh it. But feel free to open a ticket for SSSD [1] and describe you use case. I don't know SSSD that well and maybe there's no reason against setting it by default. [1] https://fedorahosted.org/sssd/newticket -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From t.ruiten at rdmedia.com Fri Feb 17 09:36:25 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Fri, 17 Feb 2017 10:36:25 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: Message-ID: I went through that bugreport, particularly this section... OK, I think I found the error. On the logs I get something like this *before* the failing dirsrv restart: 2017-01-14T03:41:28Z DEBUG [27/44]: retrieving DS Certificate 2017-01-14T03:41:28Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2017-01-14T03:41:28Z DEBUG Starting external process 2017-01-14T03:41:28Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM IPA CA -a 2017-01-14T03:41:28Z DEBUG Process finished, return code=255 2017-01-14T03:41:28Z DEBUG stdout= 2017-01-14T03:41:28Z DEBUG stderr=certutil: Could not find cert: EXAMPLE.COM IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found So, when the process stopped, I run the command again: # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM IPA CA -a certutil: Could not find cert: EXAMPLE.COM : PR_FILE_NOT_FOUND_ERROR: File not found and thought "wait... something is missing there": # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n "EXAMPLE.COM IPA CA" -a -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- So, could this be the problem? ...and indeed when I run [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM IPA CA -a > [sudo] password for tiemen: > certutil: Could not find cert: IPA.RDMEDIA.COM > : PR_FILE_NOT_FOUND_ERROR: File not found and when I run [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n "IPA.RDMEDIA.COM IPA CA" -a -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- valid certificate output. Where can I change this command to quote this string? On 16 February 2017 at 17:29, Jeff Goddard wrote: > Might be another instance of this: https://fedorahosted.org/ > freeipa/ticket/6613 > > Jeff > > On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten > wrote: > >> Hello, >> >> I'm trying to add a third replica to a FreeIPA 4.4 domain (level 1), but >> I'm getting this error: >> >> [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w "XXXXXXXXXX" >>> --mkhomedir --setup-dns --forwarder 8.8.8.8 --forwarder 8.8.4.4 >>> Checking DNS forwarders, please wait ... >>> Run connection check to master >>> Connection check OK >>> 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 (dirsrv). Estimated time: 1 minute >>> [1/44]: creating directory server user >>> [2/44]: creating directory server instance >>> [3/44]: updating configuration in dse.ldif >>> [4/44]: restarting directory server >>> [5/44]: adding default schema >>> [6/44]: enabling memberof plugin >>> [7/44]: enabling winsync plugin >>> [8/44]: configuring replication version plugin >>> [9/44]: enabling IPA enrollment plugin >>> [10/44]: enabling ldapi >>> [11/44]: configuring uniqueness plugin >>> [12/44]: configuring uuid plugin >>> [13/44]: configuring modrdn plugin >>> [14/44]: configuring DNS plugin >>> [15/44]: enabling entryUSN plugin >>> [16/44]: configuring lockout plugin >>> [17/44]: configuring topology plugin >>> [18/44]: creating indices >>> [19/44]: enabling referential integrity plugin >>> [20/44]: configuring certmap.conf >>> [21/44]: configure autobind for root >>> [22/44]: configure new location for managed entries >>> [23/44]: configure dirsrv ccache >>> [24/44]: enabling SASL mapping fallback >>> [25/44]: restarting directory server >>> [26/44]: creating DS keytab >>> [27/44]: retrieving DS Certificate >>> [28/44]: restarting directory server >>> ipa : CRITICAL Failed to restart the directory server (Command >>> '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' returned >>> non-zero exit status 1). See the installation log for details. >>> [29/44]: setting up initial replication >>> [error] error: [Errno 111] Connection refused >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR [Errno 111] >>> Connection refused >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR The >>> ipa-replica-install command failed. See /var/log/ipareplica-install.log >>> for more information >> >> >> In /var/log/ipareplica-install.log we find: >> >> 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS Certificate >>> 2017-02-16T15:53:59Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM IPA CA -a >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> >>> *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find cert: >>> IPA.RDMEDIA.COM IPA CA: PR_FILE_NOT_FOUND_ERROR: >>> File not found* >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f /etc/dirsrv/slapd-IPA-RDMEDIA- >>> COM//pwdfile.txt >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> 2017-02-16T15:53:59Z DEBUG stderr= >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM IPA CA -t >>> CT,C,C -a >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> 2017-02-16T15:53:59Z DEBUG stderr= >>> 2017-02-16T15:53:59Z DEBUG certmonger request is in state >>> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) >>> 2017-02-16T15:54:04Z DEBUG certmonger request is in state >>> dbus.String(u'CA_UNREACHABLE', variant_level=1) >>> 2017-02-16T15:54:04Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>> from SchemaCache >>> 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache >>> url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>> conn= >>> 2017-02-16T15:54:05Z DEBUG duration: 5 seconds >>> 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory server >>> 2017-02-16T15:54:05Z DEBUG Starting external process >>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system daemon-reload >>> 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:54:05Z DEBUG stdout= >>> 2017-02-16T15:54:05Z DEBUG stderr= >>> 2017-02-16T15:54:05Z DEBUG Starting external process >>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart >>> dirsrv at IPA-RDMEDIA-COM.service >>> 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 >>> 2017-02-16T15:54:06Z DEBUG stdout= >>> 2017-02-16T15:54:06Z DEBUG stderr=Job for dirsrv at IPA-RDMEDIA-COM.service >>> failed because the control process exited with error code. See "systemctl >>> status dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for details. >>> 2017-02-16T15:54:06Z CRITICAL Failed to restart the directory server >>> (Command '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' >>> returned non-zero exit status 1). See the installation log for details. >>> 2017-02-16T15:54:06Z DEBUG duration: 1 seconds >>> 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial replication >>> 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 449, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 439, in run_step >>> method() >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>> line 405, in __setup_replica >>> self.dm_password) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>> line 118, in enable_replication_version_checking >>> conn.do_simple_bind(bindpw=dirman_passwd) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1665, in do_simple_bind >>> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1660, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1643, in __wait_for_connection >>> wait_for_open_socket(lurl.hostport, timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>> 1286, in wait_for_open_socket >>> raise e >>> error: [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] Connection >>> refused >>> 2017-02-16T15:54:16Z DEBUG Destroyed connection context.ldap2_78478480 >>> 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", >>> line 318, in run >>> cfgr.run() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 310, in run >>> self.execute() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 332, in execute >>> for nothing in self._executor(): >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 372, in __runner >>> self._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 394, in _handle_exception >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 362, in __runner >>> step() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 359, in >>> step = lambda: next(self.__gen) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 81, in run_generator_with_yield_from >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 59, in run_generator_with_yield_from >>> value = gen.send(prev_value) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 586, in _configure >>> next(executor) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 372, in __runner >>> self._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 449, in _handle_exception >>> self.__parent._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 394, in _handle_exception >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 446, in _handle_exception >>> super(ComponentBase, self)._handle_exception(exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 394, in _handle_exception >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 362, in __runner >>> step() >>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line 359, in >>> step = lambda: next(self.__gen) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 81, in run_generator_with_yield_from >>> six.reraise(*exc_info) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line 59, in run_generator_with_yield_from >>> value = gen.send(prev_value) >>> File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", >>> line 63, in _install >>> for nothing in self._installer(self.parent): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 1714, in main >>> promote(self) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 364, in decorated >>> func(installer) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 1415, in promote >>> promote=True, pkcs12_info=dirsrv_pkcs12_info) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> line 127, in install_replica_ds >>> api=remote_api, >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>> line 399, in create_replica >>> self.start_creation(runtime=60) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 449, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 439, in run_step >>> method() >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>> line 405, in __setup_replica >>> self.dm_password) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>> line 118, in enable_replication_version_checking >>> conn.do_simple_bind(bindpw=dirman_passwd) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1665, in do_simple_bind >>> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1660, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1643, in __wait_for_connection >>> wait_for_open_socket(lurl.hostport, timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>> 1286, in wait_for_open_socket >>> raise e >>> 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command failed, >>> exception: error: [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z ERROR The ipa-replica-install command failed. See >>> /var/log/ipareplica-install.log for more information >>> >> >> How can I troubleshoot this? >> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> >> -- >> 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 >> > > > > > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri Feb 17 14:56:56 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Feb 2017 15:56:56 +0100 Subject: [Freeipa-users] How to change kerberos key lifetime? In-Reply-To: References: <20170216072250.GA6059@dkupka.usersys.redhat.com> <20170216134830.GE6059@dkupka.usersys.redhat.com> Message-ID: <20170217145655.GE18161@10.4.128.1> On (16/02/17 18:05), William Muriithi wrote: >> The fact that your desktops are using SSSD changes the situation dramatically. >> >> SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in. >> And can be configured to renew the ticket for the user until the ticket renew >> life time expires. >> >> Given this you can keep ticket life time reasonable short (~1 day) set ticket >> renewable life time to longer period (~2 weeks) and maintain reasonable >> security level without negative impact on user's daily work. >> >> Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options >> in sssd-krb5 man page. >> >Thanks a lot. I did actually end up using this. Will wait for a >couple of days and see if anybody if the situation is better and >update you. > >Curious though, why isn't renewal interval setup by default? Is there >a negative consequence of having SSSD renewing tickets by default? I >can't think of any and hence a bit lost on explaining the default >setup Desktop/laptop user usually does not need automatic renewal. They authenticate/login/unlock screen quite often and for each action sssd authenticate against IPA server which automatically get/renew krb5 ticket. Unless machine is offline. LS From perq at me.com Fri Feb 17 15:37:50 2017 From: perq at me.com (Per Qvindesland) Date: Fri, 17 Feb 2017 15:37:50 +0000 Subject: [Freeipa-users] Debian client installation Message-ID: <9650A9F7-BC3E-4FA8-B2EC-9A98FF249630@me.com> Hi All I have installed free ipa client by using http://www.pakjiddat.pk/articles/all/installing-freeipa-client-on-debian which works, but I am unable to get the sudo to work, on debian 7.11 machines, sssd installed version is 1.9.6 which I think is pretty old. Does anyone have any suggestions on how to get sudo to work on debian 7? perhaps another more updated how to? Regards Per From robert.l.harris at gmail.com Sat Feb 18 01:24:34 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Sat, 18 Feb 2017 01:24:34 +0000 Subject: [Freeipa-users] Installing on Ubuntu Message-ID: I have an Ubuntu 16.04 test system which is currently clean. I'm trying to install freeipa-server via apt and I'm getting an error about files missing : Setting up freeipa-server (4.3.1-0ubuntu1) ... Running ipa-server-upgrade... IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: IOError: [Errno 2] No such file or directory: u'/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif' The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information dpkg: error processing package freeipa-server (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of freeipa-server-dns: freeipa-server-dns depends on freeipa-server (>= 4.3.1-0ubuntu1); however: Package freeipa-server is not configured yet. Anyone seen this? The only source I see for these files is the slapd package which conflicts with freeipa. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Sat Feb 18 01:40:13 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Fri, 17 Feb 2017 20:40:13 -0500 Subject: [Freeipa-users] IDM server doesn't boot after update to RHEL 7.3 In-Reply-To: References: Message-ID: I now have a detailed debug log for this failed boot which I've attached with the mail. The issue seems to be specific to this system. The replica was updated to 7.3 too, and it works fine. I've zipped the log because it's quite big. The original workaround still holds true. i.e. I boot in rescue mode, start sssd, and then call isolate graphical.target which makes everything work normally. With the graphical target as default, the system doesn't boot. Somehow sssd is involved in the mix. Can someone please have a look at the log ? On Thu, Nov 10, 2016 at 12:53 PM, Prasun Gera wrote: > Yes, from my experiments, it gets stuck at some point where it has to > start avahi. And it fails to start it because it is dependent on something > that is not started yet (which is started when sssd is started). Googling > for that error pointed took me to http://www.calculate-linux. > org/boards/15/topics/26673, which seems to be somewhat related I > think. I'll post the journal messages soon. Is there some sort of a systemd > diff utility which can compare the start sequence of services from two > different systems ? Since my replica is on 7.2, which afaik works fine, > doing a diff between the two might highlight if something has changed in > the start sequence. > > On Thu, Nov 10, 2016 at 12:35 PM, Petr Vobornik > wrote: > >> On 11/09/2016 12:53 PM, Prasun Gera wrote: >> > It looks like something is messed up in the systemd configuration after >> 7.3. My >> > system doesn't boot at all. The boot screen would display the message: >> "Failed >> > to register match for Disconnected message: Connection timed out". >> After some >> > trial and error, I've managed to boot it. Here's what works right now: >> 1) Boot >> > into system rescue target with debug shell 2) start sssd 3) isolate >> graphical.target >> > >> > I have a replica which I haven't upgraded to 7.3 yet. So I can compare >> the two >> > systems to isolate the problem. >> > >> >> I'm afraid that without more info(messages/journal) nobody will be able >> to help. >> >> But based on the description it seems that it didn't even get to step >> where IPA is started. >> >> -- >> Petr Vobornik >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: failed_boot.txt.zip Type: application/zip Size: 473559 bytes Desc: not available URL: From tjaalton at ubuntu.com Sat Feb 18 05:33:00 2017 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sat, 18 Feb 2017 07:33:00 +0200 Subject: [Freeipa-users] Installing on Ubuntu In-Reply-To: References: Message-ID: <0415223c-2158-f84e-4e29-bc9b5d9f657c@ubuntu.com> On 18.02.2017 03:24, Robert L. Harris wrote: > > I have an Ubuntu 16.04 test system which is currently clean. I'm > trying to install freeipa-server via apt and I'm getting an error about > files missing : > > Setting up freeipa-server (4.3.1-0ubuntu1) ... > Running ipa-server-upgrade... > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > command ipa-server-upgrade manually. > Unexpected error - see /var/log/ipaupgrade.log for details: > IOError: [Errno 2] No such file or directory: > u'/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif' > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information > dpkg: error processing package freeipa-server (--configure): > subprocess installed post-installation script returned error exit status 1 > dpkg: dependency problems prevent configuration of freeipa-server-dns: > freeipa-server-dns depends on freeipa-server (>= 4.3.1-0ubuntu1); however: > Package freeipa-server is not configured yet. It shouldn't run ipa-server-upgrade on a clean install. What does: python2 -c 'from ipaserver.install import installutils; print "yes" if installutils.is_ipa_configured() else "no";' return? -- t From tjaalton at ubuntu.com Sat Feb 18 05:34:45 2017 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sat, 18 Feb 2017 07:34:45 +0200 Subject: [Freeipa-users] Debian client installation In-Reply-To: <9650A9F7-BC3E-4FA8-B2EC-9A98FF249630@me.com> References: <9650A9F7-BC3E-4FA8-B2EC-9A98FF249630@me.com> Message-ID: <4aa5e734-406e-a080-7d62-3f4433a0996e@ubuntu.com> On 17.02.2017 17:37, Per Qvindesland wrote: > Hi All > > I have installed free ipa client by using http://www.pakjiddat.pk/articles/all/installing-freeipa-client-on-debian which works, but I am unable to get the sudo to work, on debian 7.11 machines, sssd installed version is 1.9.6 which I think is pretty old. > > Does anyone have any suggestions on how to get sudo to work on debian 7? perhaps another more updated how to? you need sudo built with sssd support, which that repo is lacking. -- t From yamakasi.014 at gmail.com Sat Feb 18 13:47:18 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 18 Feb 2017 14:47:18 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> Message-ID: Hi Florance, I'm actually stil investigating this as the following occurs. I have removed all unneeded certs and installed the 2 intermediates for Comodo and did an ipa-certupdate which results in this: #certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB C,, AddTrustExternalCARoot C,, ipaCert u,u,u COMODORSAAddTrustCA C,, COMODORSAAddTrustCA C,, IPA.MYDOMAIN.TLD IPA CA CT,C,C I'm curious why the COMODORSAAddTrustCA is there twice, if I remove both and start over they are duplicated again. Also the AddTrustExternalCARoot comes back again even when this was not installed anymore as it's not needed. I'm able to install my cert after the update: #certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB C,, AddTrustExternalCARoot C,, ipaCert u,u,u COMODORSAAddTrustCA C,, COMODORSAAddTrustCA C,, IPA.MYDOMAIN.TLD IPA CA CT,C,C CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control Validated u,u,u Now this works great for the WebGui which uses the right Certificate for the ssl connection but ldaps on port 636 seems to use: CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB Do you have any clue about this ? I'm also curious about what IPA syncs between all hosts, it seems to be only the Intermediate certs and not the install domains certificate, this needs to be installed manually after a local #ipa-certupdate on each node ? I hope you can clearify this out. Thanks, Matt 2017-02-17 0:15 GMT+01:00 Matt . : > Hi Flo, > > Sure I can, I will look through the steps closely tomorrow and will > create some lineup here. > > Cheers, > > Matt > > 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud : >> On 02/16/2017 09:55 PM, Matt . wrote: >>> >>> Hi Flo! (if I may call you like that, saves some characters in typing >>> but with this extra line it doesn't anymore :)) >>> >>> This works perfectly, thank you very much. >>> >> Hi Matt, >> >> glad I could help. What did you do differently that could explain the >> failure, though? Maybe the cert installation needs some hardening. >> >> Flo. >> >>> No questions further actually :) >>> >>> Cheers, >>> >>> Matt >>> >>> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >>>> >>>> On 02/15/2017 05:40 PM, Matt . wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Is there any update on this ? I need to install 3 other instances but >>>>> I would like to know upfront if it might be a bug. >>>>> >>>> Hi Matt, >>>> >>>> I was not able to reproduce your issue. Here were my steps: >>>> >>>> Install FreeIPA with self-signed cert: >>>> ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD >>>> >>>> The certificate chain is ca1 -> subca -> server. >>>> Install the root CA: >>>> kinit admin >>>> ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem >>>> ipa-certupdate >>>> >>>> Install the subca: >>>> ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem >>>> ipa-certupdate >>>> >>>> Install the server cert: >>>> ipa-server-certinstall -d -w server.pem key.pem >>>> >>>> ipa-certupdate basically retrieves the certificates from LDAP (below >>>> cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias >>>> but >>>> I don't remember it removing certs. >>>> >>>> Can you check the content of your LDAP server? >>>> kinit admin >>>> ldapsearch -h `hostname` -p 389 -Y GSSAPI -b >>>> cn=certificates,cn=ipa,cn=etc,$BASEDN >>>> >>>> It should contain one entry for each CA that you added. >>>> >>>> Flo. >>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> 2017-02-14 17:59 GMT+01:00 Matt . : >>>>>> >>>>>> >>>>>> Hi Florance, >>>>>> >>>>>> Sure I can, here you go: >>>>>> >>>>>> Fedora 24 >>>>>> Freeipa VERSION: 4.4.2, API_VERSION: 2.215 >>>>>> >>>>>> I installed this server as self-signed CA >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : >>>>>>> >>>>>>> >>>>>>> On 02/14/2017 05:43 PM, Matt . wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Florance, >>>>>>>> >>>>>>>> Thanks for your update, good to see some good into about it. For >>>>>>>> Comodo I have install all these: >>>>>>>> >>>>>>>> AddTrustExternalCARoot.crt >>>>>>>> COMODORSAAddTrustCA.crt >>>>>>>> COMODORSADomainValidationSecureServerCA.crt >>>>>>>> >>>>>>>> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >>>>>>>> far as I know but the same issues still exist, the Server-Cert is >>>>>>>> removed again on ipa-certupdate and fails. >>>>>>>> >>>>>>>> I have tried this with setenforce 0 >>>>>>>> >>>>>>> Hi Matt, >>>>>>> >>>>>>> can you provide more info in order to reproduce the issue? >>>>>>> - which OS are you using >>>>>>> - IPA version >>>>>>> - how did you install ipa server (CA-less or with self-signed CA or >>>>>>> with >>>>>>> externally-signed CA?) >>>>>>> >>>>>>> Thanks, >>>>>>> Flo. >>>>>>> >>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/14/2017 02:54 PM, Matt . wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Certs are valid, I will check what you mentioned. >>>>>>>>>> >>>>>>>>>> I'm also no fan of bundles, more the seperate files but this >>>>>>>>>> doesn't >>>>>>>>>> seem to work always. At least for the CAroot a bundle was required. >>>>>>>>>> >>>>>>>>> Hi Matt, >>>>>>>>> >>>>>>>>> if your certificate was provided by an intermediate CA, you need to >>>>>>>>> add >>>>>>>>> each >>>>>>>>> CA before running ipa-server-certinstall (start from the top-level >>>>>>>>> CA >>>>>>>>> with >>>>>>>>> ipa-cacert-manage install, then run ipa-certupdate, then the >>>>>>>>> intermediate >>>>>>>>> CA >>>>>>>>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>>>>>>>> >>>>>>>>> There is also a known issue with ipa-certupdate and SELinux in >>>>>>>>> enforcing >>>>>>>>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>>>>>>>> >>>>>>>>> Flo. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Have you validated the cert (and dumped the contents) from the >>>>>>>>>>> command >>>>>>>>>>> line using the openssl tools? I?ve seen the message you are >>>>>>>>>>> seeing >>>>>>>>>>> before, >>>>>>>>>>> for some reason I seem to remember that it has to do with either a >>>>>>>>>>> missing >>>>>>>>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>>>>>>>> CERTIFICATE---- (an error from copy and pasting and not copying >>>>>>>>>>> the >>>>>>>>>>> actual >>>>>>>>>>> file). >>>>>>>>>>> >>>>>>>>>>> I?ve never used certupdate so if what is described above doesn?t >>>>>>>>>>> help >>>>>>>>>>> somebody else will have to chime in. >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>>> On Feb 14, 2017, at 2:18 AM, Matt . >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Dan, >>>>>>>>>>>> >>>>>>>>>>>> Ues i have tried that and I get the message that it misses the >>>>>>>>>>>> full >>>>>>>>>>>> chain for the certificate. >>>>>>>>>>>> >>>>>>>>>>>> My issue is more, why is the Server-Cert being removed on a >>>>>>>>>>>> certupdate >>>>>>>>>>>> ? >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with >>>>>>>>>>>>> the >>>>>>>>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>>>>>>>> >>>>>>>>>>>>> Dan >>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Guys, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>>>>>>>> >>>>>>>>>>>>>> When I run the install command for the certificate itself: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>>>>>>>> mydomain_com_bundle.crt >>>>>>>>>>>>>> Directory Manager password: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Enter private key unlock password: >>>>>>>>>>>>>> >>>>>>>>>>>>>> list index out of range >>>>>>>>>>>>>> The ipa-server-certinstall command failed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What can I do to solve this ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Matt >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 yamakasi.014 at gmail.com Sat Feb 18 14:06:21 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 18 Feb 2017 15:06:21 +0100 Subject: [Freeipa-users] sysaccounts max length Message-ID: Hi Guys, Does anyone know what the max length is for a sysaccount username is ? Thanks, Matt From t.ruiten at rdmedia.com Mon Feb 20 08:19:05 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Mon, 20 Feb 2017 09:19:05 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: Message-ID: Any help would be much appreciated! I really need to add this replica (and others)... On 17 February 2017 at 10:36, Tiemen Ruiten wrote: > I went through that bugreport, particularly this section... > > OK, I think I found the error. On the logs I get something like this > *before* the failing dirsrv restart: > > 2017-01-14T03:41:28Z DEBUG [27/44]: retrieving DS Certificate > 2017-01-14T03:41:28Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > 2017-01-14T03:41:28Z DEBUG Starting external process > 2017-01-14T03:41:28Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM IPA CA -a > 2017-01-14T03:41:28Z DEBUG Process finished, return code=255 > 2017-01-14T03:41:28Z DEBUG stdout= > 2017-01-14T03:41:28Z DEBUG stderr=certutil: Could not find cert: EXAMPLE.COM IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found > > So, when the process stopped, I run the command again: > > # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM IPA CA -a > certutil: Could not find cert: EXAMPLE.COM > : PR_FILE_NOT_FOUND_ERROR: File not found > > > and thought "wait... something is missing there": > > # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n "EXAMPLE.COM IPA CA" -a > -----BEGIN CERTIFICATE----- > > -----END CERTIFICATE----- > > So, could this be the problem? > > ...and indeed when I run > > [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM IPA CA -a >> [sudo] password for tiemen: >> certutil: Could not find cert: IPA.RDMEDIA.COM >> : PR_FILE_NOT_FOUND_ERROR: File not found > > > and when I run > > [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n "IPA.RDMEDIA.COM IPA CA" -a > -----BEGIN CERTIFICATE----- > > -----END CERTIFICATE----- > > valid certificate output. Where can I change this command to quote this > string? > > > On 16 February 2017 at 17:29, Jeff Goddard wrote: > >> Might be another instance of this: https://fedorahosted.org/freei >> pa/ticket/6613 >> >> Jeff >> >> On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten >> wrote: >> >>> Hello, >>> >>> I'm trying to add a third replica to a FreeIPA 4.4 domain (level 1), but >>> I'm getting this error: >>> >>> [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w >>>> "XXXXXXXXXX" --mkhomedir --setup-dns --forwarder 8.8.8.8 --forwarder 8.8.4.4 >>>> Checking DNS forwarders, please wait ... >>>> Run connection check to master >>>> Connection check OK >>>> 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 (dirsrv). Estimated time: 1 minute >>>> [1/44]: creating directory server user >>>> [2/44]: creating directory server instance >>>> [3/44]: updating configuration in dse.ldif >>>> [4/44]: restarting directory server >>>> [5/44]: adding default schema >>>> [6/44]: enabling memberof plugin >>>> [7/44]: enabling winsync plugin >>>> [8/44]: configuring replication version plugin >>>> [9/44]: enabling IPA enrollment plugin >>>> [10/44]: enabling ldapi >>>> [11/44]: configuring uniqueness plugin >>>> [12/44]: configuring uuid plugin >>>> [13/44]: configuring modrdn plugin >>>> [14/44]: configuring DNS plugin >>>> [15/44]: enabling entryUSN plugin >>>> [16/44]: configuring lockout plugin >>>> [17/44]: configuring topology plugin >>>> [18/44]: creating indices >>>> [19/44]: enabling referential integrity plugin >>>> [20/44]: configuring certmap.conf >>>> [21/44]: configure autobind for root >>>> [22/44]: configure new location for managed entries >>>> [23/44]: configure dirsrv ccache >>>> [24/44]: enabling SASL mapping fallback >>>> [25/44]: restarting directory server >>>> [26/44]: creating DS keytab >>>> [27/44]: retrieving DS Certificate >>>> [28/44]: restarting directory server >>>> ipa : CRITICAL Failed to restart the directory server (Command >>>> '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' returned >>>> non-zero exit status 1). See the installation log for details. >>>> [29/44]: setting up initial replication >>>> [error] error: [Errno 111] Connection refused >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> ipa.ipapython.install.cli.install_tool(Replica): ERROR [Errno 111] >>>> Connection refused >>>> ipa.ipapython.install.cli.install_tool(Replica): ERROR The >>>> ipa-replica-install command failed. See /var/log/ipareplica-install.log >>>> for more information >>> >>> >>> In /var/log/ipareplica-install.log we find: >>> >>> 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS Certificate >>>> 2017-02-16T15:53:59Z DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2017-02-16T15:53:59Z DEBUG Starting external process >>>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM IPA CA -a >>>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 >>>> 2017-02-16T15:53:59Z DEBUG stdout= >>>> >>>> *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find cert: >>>> IPA.RDMEDIA.COM IPA CA: PR_FILE_NOT_FOUND_ERROR: >>>> File not found* >>>> 2017-02-16T15:53:59Z DEBUG Starting external process >>>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f /etc/dirsrv/slapd-IPA-RDMEDIA- >>>> COM//pwdfile.txt >>>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>>> 2017-02-16T15:53:59Z DEBUG stdout= >>>> 2017-02-16T15:53:59Z DEBUG stderr= >>>> 2017-02-16T15:53:59Z DEBUG Starting external process >>>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM IPA CA -t >>>> CT,C,C -a >>>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>>> 2017-02-16T15:53:59Z DEBUG stdout= >>>> 2017-02-16T15:53:59Z DEBUG stderr= >>>> 2017-02-16T15:53:59Z DEBUG certmonger request is in state >>>> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) >>>> 2017-02-16T15:54:04Z DEBUG certmonger request is in state >>>> dbus.String(u'CA_UNREACHABLE', variant_level=1) >>>> 2017-02-16T15:54:04Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>>> from SchemaCache >>>> 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache >>>> url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>>> conn= >>>> 2017-02-16T15:54:05Z DEBUG duration: 5 seconds >>>> 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory server >>>> 2017-02-16T15:54:05Z DEBUG Starting external process >>>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system daemon-reload >>>> 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 >>>> 2017-02-16T15:54:05Z DEBUG stdout= >>>> 2017-02-16T15:54:05Z DEBUG stderr= >>>> 2017-02-16T15:54:05Z DEBUG Starting external process >>>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart >>>> dirsrv at IPA-RDMEDIA-COM.service >>>> 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 >>>> 2017-02-16T15:54:06Z DEBUG stdout= >>>> 2017-02-16T15:54:06Z DEBUG stderr=Job for dirsrv at IPA-RDMEDIA-COM.service >>>> failed because the control process exited with error code. See "systemctl >>>> status dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for >>>> details. >>>> 2017-02-16T15:54:06Z CRITICAL Failed to restart the directory server >>>> (Command '/bin/systemctl restart dirsrv at IPA-RDMEDIA-COM.service' >>>> returned non-zero exit status 1). See the installation log for details. >>>> 2017-02-16T15:54:06Z DEBUG duration: 1 seconds >>>> 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial replication >>>> 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 449, in start_creation >>>> run_step(full_msg, method) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 439, in run_step >>>> method() >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>>> line 405, in __setup_replica >>>> self.dm_password) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>>> line 118, in enable_replication_version_checking >>>> conn.do_simple_bind(bindpw=dirman_passwd) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1665, in do_simple_bind >>>> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1660, in __bind_with_wait >>>> self.__wait_for_connection(timeout) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1643, in __wait_for_connection >>>> wait_for_open_socket(lurl.hostport, timeout) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>>> 1286, in wait_for_open_socket >>>> raise e >>>> error: [Errno 111] Connection refused >>>> 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] Connection >>>> refused >>>> 2017-02-16T15:54:16Z DEBUG Destroyed connection context.ldap2_78478480 >>>> 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", >>>> line 318, in run >>>> cfgr.run() >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 310, in run >>>> self.execute() >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 332, in execute >>>> for nothing in self._executor(): >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 372, in __runner >>>> self._handle_exception(exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 394, in _handle_exception >>>> six.reraise(*exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 362, in __runner >>>> step() >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 359, in >>>> step = lambda: next(self.__gen) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>>> line 81, in run_generator_with_yield_from >>>> six.reraise(*exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>>> line 59, in run_generator_with_yield_from >>>> value = gen.send(prev_value) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 586, in _configure >>>> next(executor) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 372, in __runner >>>> self._handle_exception(exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 449, in _handle_exception >>>> self.__parent._handle_exception(exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 394, in _handle_exception >>>> six.reraise(*exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 446, in _handle_exception >>>> super(ComponentBase, self)._handle_exception(exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 394, in _handle_exception >>>> six.reraise(*exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 362, in __runner >>>> step() >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>>> line 359, in >>>> step = lambda: next(self.__gen) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>>> line 81, in run_generator_with_yield_from >>>> six.reraise(*exc_info) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>>> line 59, in run_generator_with_yield_from >>>> value = gen.send(prev_value) >>>> File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", >>>> line 63, in _install >>>> for nothing in self._installer(self.parent): >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>> line 1714, in main >>>> promote(self) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>> line 364, in decorated >>>> func(installer) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>> line 1415, in promote >>>> promote=True, pkcs12_info=dirsrv_pkcs12_info) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>> line 127, in install_replica_ds >>>> api=remote_api, >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>>> line 399, in create_replica >>>> self.start_creation(runtime=60) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 449, in start_creation >>>> run_step(full_msg, method) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 439, in run_step >>>> method() >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >>>> line 405, in __setup_replica >>>> self.dm_password) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >>>> line 118, in enable_replication_version_checking >>>> conn.do_simple_bind(bindpw=dirman_passwd) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1665, in do_simple_bind >>>> self.__bind_with_wait(self.simple_bind, timeout, binddn, bindpw) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1660, in __bind_with_wait >>>> self.__wait_for_connection(timeout) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1643, in __wait_for_connection >>>> wait_for_open_socket(lurl.hostport, timeout) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>>> 1286, in wait_for_open_socket >>>> raise e >>>> 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command failed, >>>> exception: error: [Errno 111] Connection refused >>>> 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused >>>> 2017-02-16T15:54:16Z ERROR The ipa-replica-install command failed. See >>>> /var/log/ipareplica-install.log for more information >>>> >>> >>> How can I troubleshoot this? >>> >>> >>> >>> -- >>> Tiemen Ruiten >>> Systems Engineer >>> R&D Media >>> >>> -- >>> 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 >>> >> >> >> >> >> > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Mon Feb 20 08:28:45 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Mon, 20 Feb 2017 09:28:45 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: Message-ID: <3ea10958-6805-1f14-94d7-14124fd37eeb@redhat.com> On 02/17/2017 10:36 AM, Tiemen Ruiten wrote: > I went through that bugreport, particularly this section... > > OK, I think I found the error. On the logs I get something like this > *before* the failing dirsrv restart: > > 2017-01-14T03:41:28Z DEBUG [27/44]: retrieving DS Certificate > 2017-01-14T03:41:28Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > 2017-01-14T03:41:28Z DEBUG Starting external process > 2017-01-14T03:41:28Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM IPA CA -a > 2017-01-14T03:41:28Z DEBUG Process finished, return code=255 > 2017-01-14T03:41:28Z DEBUG stdout= > 2017-01-14T03:41:28Z DEBUG stderr=certutil: Could not find cert: EXAMPLE.COM IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found > Hi, this error shows that the server certificate for the LDAP server is not present in the NSS database. I am pretty sure that if you run $ getcert list -d /etc/dirsrv/slapd-DOMAIN you will get an error like this one: status: CA_UNREACHABLE ca-error: Server at https://ipa.EXAMPLE.COM/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (503)). Make sure that the file /etc/pki/pki-tomcat/server.xml (on all the masters) defines the AJP connector like this: and that the /etc/hosts file (on all the masters) properly defines localhost: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 Then restart the PKI service on the masters: systemctl stop pki-tomcatd at pki-tomcat.service After this, you should be able to re-run ipa-replica-install without any problem. HTH, Flo. > So, when the process stopped, I run the command again: > > # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM IPA CA -a > certutil: Could not find cert: EXAMPLE.COM > : PR_FILE_NOT_FOUND_ERROR: File not found > > and thought "wait... something is missing there": > > # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n "EXAMPLE.COM IPA CA" -a > -----BEGIN CERTIFICATE----- > > -----END CERTIFICATE----- > > So, could this be the problem? > > > ...and indeed when I run > > [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM > IPA CA -a > [sudo] password for tiemen: > certutil: Could not find cert: IPA.RDMEDIA.COM > : PR_FILE_NOT_FOUND_ERROR: File not found > > > and when I run > > [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n "IPA.RDMEDIA.COM > IPA CA" -a > -----BEGIN CERTIFICATE----- > > -----END CERTIFICATE----- > > valid certificate output. Where can I change this command to quote this > string? > > > On 16 February 2017 at 17:29, Jeff Goddard > wrote: > > Might be another instance of this: > https://fedorahosted.org/freeipa/ticket/6613 > > > Jeff > > On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten > > wrote: > > Hello, > > I'm trying to add a third replica to a FreeIPA 4.4 domain (level > 1), but I'm getting this error: > > [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w > "XXXXXXXXXX" --mkhomedir --setup-dns --forwarder 8.8.8.8 > --forwarder 8.8.4.4 > Checking DNS forwarders, please wait ... > Run connection check to master > Connection check OK > 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 (dirsrv). Estimated time: 1 minute > [1/44]: creating directory server user > [2/44]: creating directory server instance > [3/44]: updating configuration in dse.ldif > [4/44]: restarting directory server > [5/44]: adding default schema > [6/44]: enabling memberof plugin > [7/44]: enabling winsync plugin > [8/44]: configuring replication version plugin > [9/44]: enabling IPA enrollment plugin > [10/44]: enabling ldapi > [11/44]: configuring uniqueness plugin > [12/44]: configuring uuid plugin > [13/44]: configuring modrdn plugin > [14/44]: configuring DNS plugin > [15/44]: enabling entryUSN plugin > [16/44]: configuring lockout plugin > [17/44]: configuring topology plugin > [18/44]: creating indices > [19/44]: enabling referential integrity plugin > [20/44]: configuring certmap.conf > [21/44]: configure autobind for root > [22/44]: configure new location for managed entries > [23/44]: configure dirsrv ccache > [24/44]: enabling SASL mapping fallback > [25/44]: restarting directory server > [26/44]: creating DS keytab > [27/44]: retrieving DS Certificate > [28/44]: restarting directory server > ipa : CRITICAL Failed to restart the directory > server (Command '/bin/systemctl restart > dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit > status 1). See the installation log for details. > [29/44]: setting up initial replication > [error] error: [Errno 111] Connection refused > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > ipa.ipapython.install.cli.install_tool(Replica): ERROR > [Errno 111] Connection refused > ipa.ipapython.install.cli.install_tool(Replica): ERROR > The ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > > In /var/log/ipareplica-install.log we find: > > 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS Certificate > 2017-02-16T15:53:59Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM > IPA CA -a > 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 > 2017-02-16T15:53:59Z DEBUG stdout= > *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find > cert: IPA.RDMEDIA.COM IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found* > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f > /etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt > 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 > 2017-02-16T15:53:59Z DEBUG stdout= > 2017-02-16T15:53:59Z DEBUG stderr= > 2017-02-16T15:53:59Z DEBUG Starting external process > 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM > IPA CA -t CT,C,C -a > 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 > 2017-02-16T15:53:59Z DEBUG stdout= > 2017-02-16T15:53:59Z DEBUG stderr= > 2017-02-16T15:53:59Z DEBUG certmonger request is in state > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) > 2017-02-16T15:54:04Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > 2017-02-16T15:54:04Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket from > SchemaCache > 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket > conn= > 2017-02-16T15:54:05Z DEBUG duration: 5 seconds > 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory > server > 2017-02-16T15:54:05Z DEBUG Starting external process > 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system > daemon-reload > 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 > 2017-02-16T15:54:05Z DEBUG stdout= > 2017-02-16T15:54:05Z DEBUG stderr= > 2017-02-16T15:54:05Z DEBUG Starting external process > 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart > dirsrv at IPA-RDMEDIA-COM.service > 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 > 2017-02-16T15:54:06Z DEBUG stdout= > 2017-02-16T15:54:06Z DEBUG stderr=Job for > dirsrv at IPA-RDMEDIA-COM.service failed because the control > process exited with error code. See "systemctl status > dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for > details. > 2017-02-16T15:54:06Z CRITICAL Failed to restart the > directory server (Command '/bin/systemctl restart > dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit > status 1). See the installation log for details. > 2017-02-16T15:54:06Z DEBUG duration: 1 seconds > 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial > replication > 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 449, in start_creation > run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 439, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 405, in __setup_replica > self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 118, in enable_replication_version_checking > conn.do_simple_bind(bindpw=dirman_passwd) > File > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1665, in do_simple_bind > self.__bind_with_wait(self.simple_bind, timeout, binddn, > bindpw) > File > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1660, in __bind_with_wait > self.__wait_for_connection(timeout) > File > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1643, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", > line 1286, in wait_for_open_socket > raise e > error: [Errno 111] Connection refused > 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] > Connection refused > 2017-02-16T15:54:16Z DEBUG Destroyed connection > context.ldap2_78478480 > 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", > line 318, in run > cfgr.run() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 310, in run > self.execute() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 332, in execute > for nothing in self._executor(): > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 362, in __runner > step() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 586, in _configure > next(executor) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 362, in __runner > step() > File > "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File > "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line > 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File > "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 63, in _install > for nothing in self._installer(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1714, in main > promote(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 364, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1415, in promote > promote=True, pkcs12_info=dirsrv_pkcs12_info) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 127, in install_replica_ds > api=remote_api, > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 399, in create_replica > self.start_creation(runtime=60) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 449, in start_creation > run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 439, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 405, in __setup_replica > self.dm_password) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 118, in enable_replication_version_checking > conn.do_simple_bind(bindpw=dirman_passwd) > File > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1665, in do_simple_bind > self.__bind_with_wait(self.simple_bind, timeout, binddn, > bindpw) > File > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1660, in __bind_with_wait > self.__wait_for_connection(timeout) > File > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > line 1643, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", > line 1286, in wait_for_open_socket > raise e > 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command > failed, exception: error: [Errno 111] Connection refused > 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused > 2017-02-16T15:54:16Z ERROR The ipa-replica-install command > failed. See /var/log/ipareplica-install.log for more information > > > How can I troubleshoot this? > > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > > -- > 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 > > > > > > > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > > From t.ruiten at rdmedia.com Mon Feb 20 09:05:28 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Mon, 20 Feb 2017 10:05:28 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: <3ea10958-6805-1f14-94d7-14124fd37eeb@redhat.com> References: <3ea10958-6805-1f14-94d7-14124fd37eeb@redhat.com> Message-ID: Hello Flo, Thanks for your response. I ran that command and I seem to have a different problem (connectors are defined as you indicated): [tiemen at copernicum ~]$ sudo getcert list -d > /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ > [sudo] password for tiemen: > Number of certificates and requests being tracked: 2. > Request ID '20170217130857': > status: CA_UNREACHABLE > ca-error: Server at https://moscovium.ipa.rdmedia.com/ipa/xml failed > request, will retry: 4301 (RPC failed at server. Certificate operation > cannot be completed: FAILURE (*CA not found: > 1ba8130c-56b8-4bd9-ae8a-8b0333d71b80*)). > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-IPA-RDMEDIA-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-IPA-RDMEDIA-COM',nickname='Server-Cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes On 20 February 2017 at 09:28, Florence Blanc-Renaud wrote: > On 02/17/2017 10:36 AM, Tiemen Ruiten wrote: > >> I went through that bugreport, particularly this section... >> >> OK, I think I found the error. On the logs I get something like this >> *before* the failing dirsrv restart: >> >> 2017-01-14T03:41:28Z DEBUG [27/44]: retrieving DS Certificate >> 2017-01-14T03:41:28Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2017-01-14T03:41:28Z DEBUG Starting external process >> 2017-01-14T03:41:28Z DEBUG args=/usr/bin/certutil -d >> /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM >> IPA CA -a >> 2017-01-14T03:41:28Z DEBUG Process finished, return code=255 >> 2017-01-14T03:41:28Z DEBUG stdout= >> 2017-01-14T03:41:28Z DEBUG stderr=certutil: Could not find cert: >> EXAMPLE.COM IPA CA >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> > Hi, > > this error shows that the server certificate for the LDAP server is not > present in the NSS database. I am pretty sure that if you run > $ getcert list -d /etc/dirsrv/slapd-DOMAIN > you will get an error like this one: > status: CA_UNREACHABLE > ca-error: Server at https://ipa.EXAMPLE.COM/ipa/xml failed > request, will retry: 4301 (RPC failed at server. Certificate operation > cannot be completed: Unable to communicate with CMS (503)). > > Make sure that the file /etc/pki/pki-tomcat/server.xml (on all the > masters) defines the AJP connector like this: > protocol="AJP/1.3" > redirectPort="8443" > address="localhost" /> > and that the /etc/hosts file (on all the masters) properly defines > localhost: > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > Then restart the PKI service on the masters: > systemctl stop pki-tomcatd at pki-tomcat.service > > After this, you should be able to re-run ipa-replica-install without any > problem. > HTH, > Flo. > > So, when the process stopped, I run the command again: >> >> # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM < >> http://EXAMPLE.COM> IPA CA -a >> certutil: Could not find cert: EXAMPLE.COM >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> and thought "wait... something is missing there": >> >> # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n "EXAMPLE.COM >> IPA CA" -a >> -----BEGIN CERTIFICATE----- >> >> -----END CERTIFICATE----- >> >> So, could this be the problem? >> >> >> ...and indeed when I run >> >> [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM >> IPA CA -a >> [sudo] password for tiemen: >> certutil: Could not find cert: IPA.RDMEDIA.COM < >> http://IPA.RDMEDIA.COM> >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> >> and when I run >> >> [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n "IPA.RDMEDIA.COM >> IPA CA" -a >> -----BEGIN CERTIFICATE----- >> >> -----END CERTIFICATE----- >> >> valid certificate output. Where can I change this command to quote this >> string? >> >> >> On 16 February 2017 at 17:29, Jeff Goddard > > wrote: >> >> Might be another instance of this: >> https://fedorahosted.org/freeipa/ticket/6613 >> >> >> Jeff >> >> On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten >> > wrote: >> >> Hello, >> >> I'm trying to add a third replica to a FreeIPA 4.4 domain (level >> 1), but I'm getting this error: >> >> [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w >> "XXXXXXXXXX" --mkhomedir --setup-dns --forwarder 8.8.8.8 >> --forwarder 8.8.4.4 >> Checking DNS forwarders, please wait ... >> Run connection check to master >> Connection check OK >> 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 (dirsrv). Estimated time: 1 >> minute >> [1/44]: creating directory server user >> [2/44]: creating directory server instance >> [3/44]: updating configuration in dse.ldif >> [4/44]: restarting directory server >> [5/44]: adding default schema >> [6/44]: enabling memberof plugin >> [7/44]: enabling winsync plugin >> [8/44]: configuring replication version plugin >> [9/44]: enabling IPA enrollment plugin >> [10/44]: enabling ldapi >> [11/44]: configuring uniqueness plugin >> [12/44]: configuring uuid plugin >> [13/44]: configuring modrdn plugin >> [14/44]: configuring DNS plugin >> [15/44]: enabling entryUSN plugin >> [16/44]: configuring lockout plugin >> [17/44]: configuring topology plugin >> [18/44]: creating indices >> [19/44]: enabling referential integrity plugin >> [20/44]: configuring certmap.conf >> [21/44]: configure autobind for root >> [22/44]: configure new location for managed entries >> [23/44]: configure dirsrv ccache >> [24/44]: enabling SASL mapping fallback >> [25/44]: restarting directory server >> [26/44]: creating DS keytab >> [27/44]: retrieving DS Certificate >> [28/44]: restarting directory server >> ipa : CRITICAL Failed to restart the directory >> server (Command '/bin/systemctl restart >> dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit >> status 1). See the installation log for details. >> [29/44]: setting up initial replication >> [error] error: [Errno 111] Connection refused >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> ipa.ipapython.install.cli.install_tool(Replica): ERROR >> [Errno 111] Connection refused >> ipa.ipapython.install.cli.install_tool(Replica): ERROR >> The ipa-replica-install command failed. See >> /var/log/ipareplica-install.log for more information >> >> >> In /var/log/ipareplica-install.log we find: >> >> 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS >> Certificate >> 2017-02-16T15:53:59Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2017-02-16T15:53:59Z DEBUG Starting external process >> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM >> IPA CA -a >> 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 >> 2017-02-16T15:53:59Z DEBUG stdout= >> *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find >> cert: IPA.RDMEDIA.COM IPA CA >> : PR_FILE_NOT_FOUND_ERROR: File not found* >> 2017-02-16T15:53:59Z DEBUG Starting external process >> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt >> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >> 2017-02-16T15:53:59Z DEBUG stdout= >> 2017-02-16T15:53:59Z DEBUG stderr= >> 2017-02-16T15:53:59Z DEBUG Starting external process >> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM >> IPA CA -t CT,C,C -a >> >> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >> 2017-02-16T15:53:59Z DEBUG stdout= >> 2017-02-16T15:53:59Z DEBUG stderr= >> 2017-02-16T15:53:59Z DEBUG certmonger request is in state >> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) >> 2017-02-16T15:54:04Z DEBUG certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> 2017-02-16T15:54:04Z DEBUG flushing >> ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket from >> SchemaCache >> 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >> conn= >> 2017-02-16T15:54:05Z DEBUG duration: 5 seconds >> 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory >> server >> 2017-02-16T15:54:05Z DEBUG Starting external process >> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system >> daemon-reload >> 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 >> 2017-02-16T15:54:05Z DEBUG stdout= >> 2017-02-16T15:54:05Z DEBUG stderr= >> 2017-02-16T15:54:05Z DEBUG Starting external process >> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart >> dirsrv at IPA-RDMEDIA-COM.service >> 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 >> 2017-02-16T15:54:06Z DEBUG stdout= >> 2017-02-16T15:54:06Z DEBUG stderr=Job for >> dirsrv at IPA-RDMEDIA-COM.service failed because the control >> process exited with error code. See "systemctl status >> dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for >> details. >> 2017-02-16T15:54:06Z CRITICAL Failed to restart the >> directory server (Command '/bin/systemctl restart >> dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit >> status 1). See the installation log for details. >> 2017-02-16T15:54:06Z DEBUG duration: 1 seconds >> 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial >> replication >> 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >> py", >> line 449, in start_creation >> run_step(full_msg, method) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >> py", >> line 439, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstan >> ce.py", >> line 405, in __setup_replica >> self.dm_password) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/replicat >> ion.py", >> line 118, in enable_replication_version_checking >> conn.do_simple_bind(bindpw=dirman_passwd) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >> line 1665, in do_simple_bind >> self.__bind_with_wait(self.simple_bind, timeout, binddn, >> bindpw) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >> line 1660, in __bind_with_wait >> self.__wait_for_connection(timeout) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >> line 1643, in __wait_for_connection >> wait_for_open_socket(lurl.hostport, timeout) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >> line 1286, in wait_for_open_socket >> raise e >> error: [Errno 111] Connection refused >> 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] >> Connection refused >> 2017-02-16T15:54:16Z DEBUG Destroyed connection >> context.ldap2_78478480 >> 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", >> line 318, in run >> cfgr.run() >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 310, in run >> self.execute() >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 332, in execute >> for nothing in self._executor(): >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 372, in __runner >> self._handle_exception(exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 394, in _handle_exception >> six.reraise(*exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 362, in __runner >> step() >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 359, in >> step = lambda: next(self.__gen) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line >> 81, in run_generator_with_yield_from >> six.reraise(*exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line >> 59, in run_generator_with_yield_from >> value = gen.send(prev_value) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 586, in _configure >> next(executor) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 372, in __runner >> self._handle_exception(exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 449, in _handle_exception >> self.__parent._handle_exception(exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 394, in _handle_exception >> six.reraise(*exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 446, in _handle_exception >> super(ComponentBase, self)._handle_exception(exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 394, in _handle_exception >> six.reraise(*exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 362, in __runner >> step() >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line >> 359, in >> step = lambda: next(self.__gen) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line >> 81, in run_generator_with_yield_from >> six.reraise(*exc_info) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line >> 59, in run_generator_with_yield_from >> value = gen.send(prev_value) >> File >> "/usr/lib/python2.7/site-packages/ipapython/install/common. >> py", >> line 63, in _install >> for nothing in self._installer(self.parent): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/ >> replicainstall.py", >> line 1714, in main >> promote(self) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/ >> replicainstall.py", >> line 364, in decorated >> func(installer) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/ >> replicainstall.py", >> line 1415, in promote >> promote=True, pkcs12_info=dirsrv_pkcs12_info) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/ >> replicainstall.py", >> line 127, in install_replica_ds >> api=remote_api, >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstan >> ce.py", >> line 399, in create_replica >> self.start_creation(runtime=60) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >> py", >> line 449, in start_creation >> run_step(full_msg, method) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >> py", >> line 439, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstan >> ce.py", >> line 405, in __setup_replica >> self.dm_password) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/replicat >> ion.py", >> line 118, in enable_replication_version_checking >> conn.do_simple_bind(bindpw=dirman_passwd) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >> line 1665, in do_simple_bind >> self.__bind_with_wait(self.simple_bind, timeout, binddn, >> bindpw) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >> line 1660, in __bind_with_wait >> self.__wait_for_connection(timeout) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >> line 1643, in __wait_for_connection >> wait_for_open_socket(lurl.hostport, timeout) >> File >> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >> line 1286, in wait_for_open_socket >> raise e >> 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command >> failed, exception: error: [Errno 111] Connection refused >> 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused >> 2017-02-16T15:54:16Z ERROR The ipa-replica-install command >> failed. See /var/log/ipareplica-install.log for more >> information >> >> >> How can I troubleshoot this? >> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> >> -- >> 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 >> >> >> >> >> >> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> >> >> > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Mon Feb 20 09:31:16 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 20 Feb 2017 10:31:16 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <328E82A3-77A2-4C2A-8FEC-E0AF3A7BBBE4@bsd.uchicago.edu> <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> Message-ID: Hi, The install seems to be OK this way, but I'm still confused about the duplicated and the RootCA. Cheers, Matt 2017-02-18 14:47 GMT+01:00 Matt . : > Hi Florance, > > > I'm actually stil investigating this as the following occurs. > > I have removed all unneeded certs and installed the 2 intermediates > for Comodo and did an ipa-certupdate which results in this: > > #certutil -L -d /etc/httpd/alias > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA > Limited,L=Salford,ST=Greater Manchester,C=GB C,, > AddTrustExternalCARoot C,, > ipaCert u,u,u > COMODORSAAddTrustCA C,, > COMODORSAAddTrustCA C,, > IPA.MYDOMAIN.TLD IPA CA CT,C,C > > > I'm curious why the COMODORSAAddTrustCA is there twice, if I remove > both and start over they are duplicated again. Also the > AddTrustExternalCARoot comes back again even when this was not > installed anymore as it's not needed. > > I'm able to install my cert after the update: > > > #certutil -L -d /etc/httpd/alias > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA > Limited,L=Salford,ST=Greater Manchester,C=GB C,, > AddTrustExternalCARoot C,, > ipaCert u,u,u > COMODORSAAddTrustCA C,, > COMODORSAAddTrustCA C,, > IPA.MYDOMAIN.TLD IPA CA CT,C,C > CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control Validated u,u,u > > > > Now this works great for the WebGui which uses the right Certificate > for the ssl connection but ldaps on port 636 seems to use: > > CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA > Limited,L=Salford,ST=Greater Manchester,C=GB > > > Do you have any clue about this ? > > I'm also curious about what IPA syncs between all hosts, it seems to > be only the Intermediate certs and not the install domains > certificate, this needs to be installed manually after a local > #ipa-certupdate on each node ? > > I hope you can clearify this out. > > > Thanks, > > Matt > > > 2017-02-17 0:15 GMT+01:00 Matt . : >> Hi Flo, >> >> Sure I can, I will look through the steps closely tomorrow and will >> create some lineup here. >> >> Cheers, >> >> Matt >> >> 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud : >>> On 02/16/2017 09:55 PM, Matt . wrote: >>>> >>>> Hi Flo! (if I may call you like that, saves some characters in typing >>>> but with this extra line it doesn't anymore :)) >>>> >>>> This works perfectly, thank you very much. >>>> >>> Hi Matt, >>> >>> glad I could help. What did you do differently that could explain the >>> failure, though? Maybe the cert installation needs some hardening. >>> >>> Flo. >>> >>>> No questions further actually :) >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >>>>> >>>>> On 02/15/2017 05:40 PM, Matt . wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Is there any update on this ? I need to install 3 other instances but >>>>>> I would like to know upfront if it might be a bug. >>>>>> >>>>> Hi Matt, >>>>> >>>>> I was not able to reproduce your issue. Here were my steps: >>>>> >>>>> Install FreeIPA with self-signed cert: >>>>> ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD >>>>> >>>>> The certificate chain is ca1 -> subca -> server. >>>>> Install the root CA: >>>>> kinit admin >>>>> ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem >>>>> ipa-certupdate >>>>> >>>>> Install the subca: >>>>> ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem >>>>> ipa-certupdate >>>>> >>>>> Install the server cert: >>>>> ipa-server-certinstall -d -w server.pem key.pem >>>>> >>>>> ipa-certupdate basically retrieves the certificates from LDAP (below >>>>> cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias >>>>> but >>>>> I don't remember it removing certs. >>>>> >>>>> Can you check the content of your LDAP server? >>>>> kinit admin >>>>> ldapsearch -h `hostname` -p 389 -Y GSSAPI -b >>>>> cn=certificates,cn=ipa,cn=etc,$BASEDN >>>>> >>>>> It should contain one entry for each CA that you added. >>>>> >>>>> Flo. >>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2017-02-14 17:59 GMT+01:00 Matt . : >>>>>>> >>>>>>> >>>>>>> Hi Florance, >>>>>>> >>>>>>> Sure I can, here you go: >>>>>>> >>>>>>> Fedora 24 >>>>>>> Freeipa VERSION: 4.4.2, API_VERSION: 2.215 >>>>>>> >>>>>>> I installed this server as self-signed CA >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud : >>>>>>>> >>>>>>>> >>>>>>>> On 02/14/2017 05:43 PM, Matt . wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Florance, >>>>>>>>> >>>>>>>>> Thanks for your update, good to see some good into about it. For >>>>>>>>> Comodo I have install all these: >>>>>>>>> >>>>>>>>> AddTrustExternalCARoot.crt >>>>>>>>> COMODORSAAddTrustCA.crt >>>>>>>>> COMODORSADomainValidationSecureServerCA.crt >>>>>>>>> >>>>>>>>> Where COMODORSADomainValidationSecureServerCA.crt is not needed as >>>>>>>>> far as I know but the same issues still exist, the Server-Cert is >>>>>>>>> removed again on ipa-certupdate and fails. >>>>>>>>> >>>>>>>>> I have tried this with setenforce 0 >>>>>>>>> >>>>>>>> Hi Matt, >>>>>>>> >>>>>>>> can you provide more info in order to reproduce the issue? >>>>>>>> - which OS are you using >>>>>>>> - IPA version >>>>>>>> - how did you install ipa server (CA-less or with self-signed CA or >>>>>>>> with >>>>>>>> externally-signed CA?) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Flo. >>>>>>>> >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> 2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/14/2017 02:54 PM, Matt . wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Certs are valid, I will check what you mentioned. >>>>>>>>>>> >>>>>>>>>>> I'm also no fan of bundles, more the seperate files but this >>>>>>>>>>> doesn't >>>>>>>>>>> seem to work always. At least for the CAroot a bundle was required. >>>>>>>>>>> >>>>>>>>>> Hi Matt, >>>>>>>>>> >>>>>>>>>> if your certificate was provided by an intermediate CA, you need to >>>>>>>>>> add >>>>>>>>>> each >>>>>>>>>> CA before running ipa-server-certinstall (start from the top-level >>>>>>>>>> CA >>>>>>>>>> with >>>>>>>>>> ipa-cacert-manage install, then run ipa-certupdate, then the >>>>>>>>>> intermediate >>>>>>>>>> CA >>>>>>>>>> with ipa-cacert-manage install, then ipa-certupdate etc...) >>>>>>>>>> >>>>>>>>>> There is also a known issue with ipa-certupdate and SELinux in >>>>>>>>>> enforcing >>>>>>>>>> mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024). >>>>>>>>>> >>>>>>>>>> Flo. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> 2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Have you validated the cert (and dumped the contents) from the >>>>>>>>>>>> command >>>>>>>>>>>> line using the openssl tools? I?ve seen the message you are >>>>>>>>>>>> seeing >>>>>>>>>>>> before, >>>>>>>>>>>> for some reason I seem to remember that it has to do with either a >>>>>>>>>>>> missing >>>>>>>>>>>> or an extra - at either the -----BEGIN CERTIFICATE---- or -----END >>>>>>>>>>>> CERTIFICATE---- (an error from copy and pasting and not copying >>>>>>>>>>>> the >>>>>>>>>>>> actual >>>>>>>>>>>> file). >>>>>>>>>>>> >>>>>>>>>>>> I?ve never used certupdate so if what is described above doesn?t >>>>>>>>>>>> help >>>>>>>>>>>> somebody else will have to chime in. >>>>>>>>>>>> >>>>>>>>>>>> Dan >>>>>>>>>>>> >>>>>>>>>>>>> On Feb 14, 2017, at 2:18 AM, Matt . >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Dan, >>>>>>>>>>>>> >>>>>>>>>>>>> Ues i have tried that and I get the message that it misses the >>>>>>>>>>>>> full >>>>>>>>>>>>> chain for the certificate. >>>>>>>>>>>>> >>>>>>>>>>>>> My issue is more, why is the Server-Cert being removed on a >>>>>>>>>>>>> certupdate >>>>>>>>>>>>> ? >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> Matt >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI] >>>>>>>>>>>>> : >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is the chain in mydomain_com_bundle.crt? Have you tried it with >>>>>>>>>>>>>> the >>>>>>>>>>>>>> cert only (disclaimer: I?ve never done this). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dan >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Feb 13, 2017, at 4:08 PM, Matt . >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Guys, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm trying to install a 3rd party certificate using: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When I run the install command for the certificate itself: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ]# ipa-server-certinstall -w -d mydomain_com.key >>>>>>>>>>>>>>> mydomain_com_bundle.crt >>>>>>>>>>>>>>> Directory Manager password: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Enter private key unlock password: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> list index out of range >>>>>>>>>>>>>>> The ipa-server-certinstall command failed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If I do a #ipa-certupdate the Server-Cert is removed from >>>>>>>>>>>>>>> /etc/httpd/alias and the install fails because of this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What can I do to solve this ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Matt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 Mon Feb 20 14:20:29 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 20 Feb 2017 09:20:29 -0500 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> Message-ID: Matt . wrote: > Hi, > > The install seems to be OK this way, but I'm still confused about the > duplicated and the RootCA. What does this show? #3 certutil -L -d /etc/httpd/alias -n COMODORSAAddTrustCA I'm guessing it will show two certs with different serial numbers, which means this is a-ok. rob > > 2017-02-18 14:47 GMT+01:00 Matt . : >> Hi Florance, >> >> >> I'm actually stil investigating this as the following occurs. >> >> I have removed all unneeded certs and installed the 2 intermediates >> for Comodo and did an ipa-certupdate which results in this: >> >> #certutil -L -d /etc/httpd/alias >> >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> >> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >> AddTrustExternalCARoot C,, >> ipaCert u,u,u >> COMODORSAAddTrustCA C,, >> COMODORSAAddTrustCA C,, >> IPA.MYDOMAIN.TLD IPA CA CT,C,C >> >> >> I'm curious why the COMODORSAAddTrustCA is there twice, if I remove >> both and start over they are duplicated again. Also the >> AddTrustExternalCARoot comes back again even when this was not >> installed anymore as it's not needed. >> >> I'm able to install my cert after the update: >> >> >> #certutil -L -d /etc/httpd/alias >> >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> >> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >> AddTrustExternalCARoot C,, >> ipaCert u,u,u >> COMODORSAAddTrustCA C,, >> COMODORSAAddTrustCA C,, >> IPA.MYDOMAIN.TLD IPA CA CT,C,C >> CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control Validated u,u,u >> >> >> >> Now this works great for the WebGui which uses the right Certificate >> for the ssl connection but ldaps on port 636 seems to use: >> >> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >> Limited,L=Salford,ST=Greater Manchester,C=GB >> >> >> Do you have any clue about this ? >> >> I'm also curious about what IPA syncs between all hosts, it seems to >> be only the Intermediate certs and not the install domains >> certificate, this needs to be installed manually after a local >> #ipa-certupdate on each node ? >> >> I hope you can clearify this out. >> >> >> Thanks, >> >> Matt >> >> >> 2017-02-17 0:15 GMT+01:00 Matt . : >>> Hi Flo, >>> >>> Sure I can, I will look through the steps closely tomorrow and will >>> create some lineup here. >>> >>> Cheers, >>> >>> Matt >>> >>> 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud : >>>> On 02/16/2017 09:55 PM, Matt . wrote: >>>>> >>>>> Hi Flo! (if I may call you like that, saves some characters in typing >>>>> but with this extra line it doesn't anymore :)) >>>>> >>>>> This works perfectly, thank you very much. >>>>> >>>> Hi Matt, >>>> >>>> glad I could help. What did you do differently that could explain the >>>> failure, though? Maybe the cert installation needs some hardening. >>>> >>>> Flo. >>>> >>>>> No questions further actually :) >>>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >>>>>> From dkupka at redhat.com Mon Feb 20 14:41:25 2017 From: dkupka at redhat.com (David Kupka) Date: Mon, 20 Feb 2017 15:41:25 +0100 Subject: [Freeipa-users] sysaccounts max length In-Reply-To: References: Message-ID: <20170220144125.GA25765@dkupka.usersys.redhat.com> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote: > Hi Guys, > > Does anyone know what the max length is for a sysaccount username is ? > > Thanks, > > Matt > > -- > 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 Hello! From man 8 useradd: Usernames may only be up to 32 characters long. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From rcritten at redhat.com Mon Feb 20 14:53:04 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 20 Feb 2017 09:53:04 -0500 Subject: [Freeipa-users] sysaccounts max length In-Reply-To: <20170220144125.GA25765@dkupka.usersys.redhat.com> References: <20170220144125.GA25765@dkupka.usersys.redhat.com> Message-ID: <4868fb73-708a-5f5b-0e94-e9909b209f4c@redhat.com> David Kupka wrote: > On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote: >> Hi Guys, >> >> Does anyone know what the max length is for a sysaccount username is ? >> >> Thanks, >> >> Matt >> >> -- >> 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 > Hello! > > From man 8 useradd: > > Usernames may only be up to 32 characters long. This is a sysaccount so it has no login capabilities. I'm not aware of any RFC-specific maximum length for attributes. There may be implementation-specific limitations. Why do you ask? Is something not working? rob From yamakasi.014 at gmail.com Mon Feb 20 15:09:37 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 20 Feb 2017 16:09:37 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> Message-ID: Hi Rob, Yes it does, I understood that there was some reason the duplicate might exist, but I wonder more why does the RootCA show up when I removed it and comes back after adding the two intermediates ? Thanks Matt 2017-02-20 15:20 GMT+01:00 Rob Crittenden : > Matt . wrote: >> Hi, >> >> The install seems to be OK this way, but I'm still confused about the >> duplicated and the RootCA. > > What does this show? > > #3 certutil -L -d /etc/httpd/alias -n COMODORSAAddTrustCA > > I'm guessing it will show two certs with different serial numbers, which > means this is a-ok. > > rob > >> >> 2017-02-18 14:47 GMT+01:00 Matt . : >>> Hi Florance, >>> >>> >>> I'm actually stil investigating this as the following occurs. >>> >>> I have removed all unneeded certs and installed the 2 intermediates >>> for Comodo and did an ipa-certupdate which results in this: >>> >>> #certutil -L -d /etc/httpd/alias >>> >>> Certificate Nickname Trust Attributes >>> SSL,S/MIME,JAR/XPI >>> >>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >>> AddTrustExternalCARoot C,, >>> ipaCert u,u,u >>> COMODORSAAddTrustCA C,, >>> COMODORSAAddTrustCA C,, >>> IPA.MYDOMAIN.TLD IPA CA CT,C,C >>> >>> >>> I'm curious why the COMODORSAAddTrustCA is there twice, if I remove >>> both and start over they are duplicated again. Also the >>> AddTrustExternalCARoot comes back again even when this was not >>> installed anymore as it's not needed. >>> >>> I'm able to install my cert after the update: >>> >>> >>> #certutil -L -d /etc/httpd/alias >>> >>> Certificate Nickname Trust Attributes >>> SSL,S/MIME,JAR/XPI >>> >>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >>> AddTrustExternalCARoot C,, >>> ipaCert u,u,u >>> COMODORSAAddTrustCA C,, >>> COMODORSAAddTrustCA C,, >>> IPA.MYDOMAIN.TLD IPA CA CT,C,C >>> CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control Validated u,u,u >>> >>> >>> >>> Now this works great for the WebGui which uses the right Certificate >>> for the ssl connection but ldaps on port 636 seems to use: >>> >>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>> Limited,L=Salford,ST=Greater Manchester,C=GB >>> >>> >>> Do you have any clue about this ? >>> >>> I'm also curious about what IPA syncs between all hosts, it seems to >>> be only the Intermediate certs and not the install domains >>> certificate, this needs to be installed manually after a local >>> #ipa-certupdate on each node ? >>> >>> I hope you can clearify this out. >>> >>> >>> Thanks, >>> >>> Matt >>> >>> >>> 2017-02-17 0:15 GMT+01:00 Matt . : >>>> Hi Flo, >>>> >>>> Sure I can, I will look through the steps closely tomorrow and will >>>> create some lineup here. >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud : >>>>> On 02/16/2017 09:55 PM, Matt . wrote: >>>>>> >>>>>> Hi Flo! (if I may call you like that, saves some characters in typing >>>>>> but with this extra line it doesn't anymore :)) >>>>>> >>>>>> This works perfectly, thank you very much. >>>>>> >>>>> Hi Matt, >>>>> >>>>> glad I could help. What did you do differently that could explain the >>>>> failure, though? Maybe the cert installation needs some hardening. >>>>> >>>>> Flo. >>>>> >>>>>> No questions further actually :) >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >>>>>>> > From igor.leao at ubee.in Mon Feb 20 15:44:07 2017 From: igor.leao at ubee.in (=?UTF-8?Q?Igor_Le=C3=A3o?=) Date: Mon, 20 Feb 2017 12:44:07 -0300 Subject: [Freeipa-users] Client for CoreOS Message-ID: Is it possible to run a FreeIPA client on CoreOS? The OS misses some libraries and I didn't succeeded installing them. Has anyone faced this scenario? Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon Feb 20 16:22:33 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 20 Feb 2017 17:22:33 +0100 Subject: [Freeipa-users] Client for CoreOS In-Reply-To: References: Message-ID: <20170220162233.GB27985@10.4.128.1> On (20/02/17 12:44), Igor Le?o wrote: >Is it possible to run a FreeIPA client on CoreOS? >The OS misses some libraries and I didn't succeeded installing them. > >Has anyone faced this scenario? > You need to run everything in container even installer. You might inspire in docker version of container. https://hub.docker.com/r/fedora/sssd/ I am not sure whether it's possible to run with rocket. LS From yamakasi.014 at gmail.com Mon Feb 20 19:04:24 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 20 Feb 2017 20:04:24 +0100 Subject: [Freeipa-users] sysaccounts max length In-Reply-To: <4868fb73-708a-5f5b-0e94-e9909b209f4c@redhat.com> References: <20170220144125.GA25765@dkupka.usersys.redhat.com> <4868fb73-708a-5f5b-0e94-e9909b209f4c@redhat.com> Message-ID: Hi All, Yes as I stated I see software, multiple, having issues with usernames larger then 28 characters. Cheers, Matt 2017-02-20 15:53 GMT+01:00 Rob Crittenden : > David Kupka wrote: >> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote: >>> Hi Guys, >>> >>> Does anyone know what the max length is for a sysaccount username is ? >>> >>> Thanks, >>> >>> Matt >>> >>> -- >>> 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 >> Hello! >> >> From man 8 useradd: >> >> Usernames may only be up to 32 characters long. > > This is a sysaccount so it has no login capabilities. > > I'm not aware of any RFC-specific maximum length for attributes. There > may be implementation-specific limitations. > > Why do you ask? Is something not working? > > rob From rcritten at redhat.com Mon Feb 20 20:21:02 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 20 Feb 2017 15:21:02 -0500 Subject: [Freeipa-users] sysaccounts max length In-Reply-To: References: <20170220144125.GA25765@dkupka.usersys.redhat.com> <4868fb73-708a-5f5b-0e94-e9909b209f4c@redhat.com> Message-ID: <716b8a29-79c9-e426-712f-0a177f9abd53@redhat.com> Matt . wrote: > Hi All, > > Yes as I stated I see software, multiple, having issues with usernames > larger then 28 characters. You didn't say you had issues you just asked what the max length is. rob > > Cheers, > > Matt > > 2017-02-20 15:53 GMT+01:00 Rob Crittenden : >> David Kupka wrote: >>> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote: >>>> Hi Guys, >>>> >>>> Does anyone know what the max length is for a sysaccount username is ? >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> -- >>>> 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 >>> Hello! >>> >>> From man 8 useradd: >>> >>> Usernames may only be up to 32 characters long. >> >> This is a sysaccount so it has no login capabilities. >> >> I'm not aware of any RFC-specific maximum length for attributes. There >> may be implementation-specific limitations. >> >> Why do you ask? Is something not working? >> >> rob From robert.l.harris at gmail.com Mon Feb 20 20:26:31 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Mon, 20 Feb 2017 20:26:31 +0000 Subject: [Freeipa-users] Installing on Ubuntu In-Reply-To: <0415223c-2158-f84e-4e29-bc9b5d9f657c@ubuntu.com> References: <0415223c-2158-f84e-4e29-bc9b5d9f657c@ubuntu.com> Message-ID: python2 -c 'from ipaserver.install import installutils; print "yes" if installutils.is_ipa_configured() else "no";' Traceback (most recent call last): File "", line 1, in ImportError: No module named ipaserver.install On Fri, Feb 17, 2017 at 10:33 PM Timo Aaltonen wrote: > On 18.02.2017 03:24, Robert L. Harris wrote: > > > > I have an Ubuntu 16.04 test system which is currently clean. I'm > > trying to install freeipa-server via apt and I'm getting an error about > > files missing : > > > > Setting up freeipa-server (4.3.1-0ubuntu1) ... > > Running ipa-server-upgrade... > > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > > command ipa-server-upgrade manually. > > Unexpected error - see /var/log/ipaupgrade.log for details: > > IOError: [Errno 2] No such file or directory: > > u'/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif' > > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > > more information > > dpkg: error processing package freeipa-server (--configure): > > subprocess installed post-installation script returned error exit > status 1 > > dpkg: dependency problems prevent configuration of freeipa-server-dns: > > freeipa-server-dns depends on freeipa-server (>= 4.3.1-0ubuntu1); > however: > > Package freeipa-server is not configured yet. > > It shouldn't run ipa-server-upgrade on a clean install. What does: > python2 -c 'from ipaserver.install import installutils; print "yes" if > installutils.is_ipa_configured() else "no";' > > return? > > > -- > t > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at benroberts.net Mon Feb 20 20:42:09 2017 From: me at benroberts.net (Ben Roberts) Date: Mon, 20 Feb 2017 20:42:09 +0000 Subject: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records In-Reply-To: <461679326.20722033.1486709481115.JavaMail.zimbra@redhat.com> References: <461679326.20722033.1486709481115.JavaMail.zimbra@redhat.com> Message-ID: Hi all, I think I've gotten to the bottom of this and fortunately it was misunderstanding on my part rather than an error in either piece of software. I incorrectly thought the local bind masters were serving up the DS record from within the child zone when queried, but they were of course serving up the records from the parent zone. Had I been delegating the child zone to a different physical server, this would have been more obvious to me. I was expecting the external slave to serve up DS records for my signed zone, but it doesn't because the zone does not contain the DS records for itself and so they are not transferred via AXFR; and because the external was not authoritative for the parent zone so didn't return them from there either. Not being a recursive resolve, I now realise the external slave will never respond with any DS records for this zone. Finally, in my example zone with child delegation, the DS records for the delegated zone ARE correctly included in the AXFR of the parent and I was mistaken in thinking they were not. I am not yet replicating these to the external slave so was basing my understanding of what was happening based on the AXFR results alone. Had I been able to replicate these to the slave, I would have spotted my mistake when getting back DS records from the parent zone. Thanks for your time and apologies for my confusion! Ben On 10 February 2017 at 06:51, Martin Basti wrote: > Hello, > > I'm not sure how your DNS data are structured, but usually (properly) DS record is located in parent zone, so AXFR for subdomain.exmale.com should not return DS record, but AXFR for example.com should return DS record of subdomain.example.com. > > Martin > > ----- Original Message ----- > From: "Ben Roberts" > To: "Tomas Krizek" > Cc: freeipa-users at redhat.com > Sent: Thursday, February 9, 2017 10:53:38 AM > Subject: Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records > > Hi Tomas, > >> when I add a DS record to LDAP (without any DNSSEC configuration), >> it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1. >> >> I suppose you have DNSSEC configured. Could you be affected by the >> limitations mentioned in [1]? > > Yes, dnssec is otherwise fully configured (the only bit I don't yet > have is the DS records for the "example.local" parent domain > registered upstream, but that shouldn't have any impact here. I don't > think the linked limitations apply, I'm not attempting to use the CDS > or CDNSKEY record types, and am manually specifying the DS records for > the child zone. > > This is with bind 9.11 and bind-dyndb-ldap 11.0. > > Regards, > Ben Roberts > > -- > 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 yamakasi.014 at gmail.com Mon Feb 20 20:45:39 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 20 Feb 2017 21:45:39 +0100 Subject: [Freeipa-users] sysaccounts max length In-Reply-To: <716b8a29-79c9-e426-712f-0a177f9abd53@redhat.com> References: <20170220144125.GA25765@dkupka.usersys.redhat.com> <4868fb73-708a-5f5b-0e94-e9909b209f4c@redhat.com> <716b8a29-79c9-e426-712f-0a177f9abd53@redhat.com> Message-ID: Oh sorry, I thought I did, must have been some conceptmail then :) 2017-02-20 21:21 GMT+01:00 Rob Crittenden : > Matt . wrote: >> Hi All, >> >> Yes as I stated I see software, multiple, having issues with usernames >> larger then 28 characters. > > You didn't say you had issues you just asked what the max length is. > > rob > >> >> Cheers, >> >> Matt >> >> 2017-02-20 15:53 GMT+01:00 Rob Crittenden : >>> David Kupka wrote: >>>> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote: >>>>> Hi Guys, >>>>> >>>>> Does anyone know what the max length is for a sysaccount username is ? >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> -- >>>>> 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 >>>> Hello! >>>> >>>> From man 8 useradd: >>>> >>>> Usernames may only be up to 32 characters long. >>> >>> This is a sysaccount so it has no login capabilities. >>> >>> I'm not aware of any RFC-specific maximum length for attributes. There >>> may be implementation-specific limitations. >>> >>> Why do you ask? Is something not working? >>> >>> rob > From rcritten at redhat.com Mon Feb 20 21:22:20 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 20 Feb 2017 16:22:20 -0500 Subject: [Freeipa-users] sysaccounts max length In-Reply-To: References: <20170220144125.GA25765@dkupka.usersys.redhat.com> <4868fb73-708a-5f5b-0e94-e9909b209f4c@redhat.com> <716b8a29-79c9-e426-712f-0a177f9abd53@redhat.com> Message-ID: <540c1521-5442-46ba-d092-e7a67ca44ea8@redhat.com> Matt . wrote: > Oh sorry, I thought I did, must have been some conceptmail then :) You still haven't said what problems you are having. rob > > > > 2017-02-20 21:21 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> Hi All, >>> >>> Yes as I stated I see software, multiple, having issues with usernames >>> larger then 28 characters. >> >> You didn't say you had issues you just asked what the max length is. >> >> rob >> >>> >>> Cheers, >>> >>> Matt >>> >>> 2017-02-20 15:53 GMT+01:00 Rob Crittenden : >>>> David Kupka wrote: >>>>> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote: >>>>>> Hi Guys, >>>>>> >>>>>> Does anyone know what the max length is for a sysaccount username is ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> -- >>>>>> 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 >>>>> Hello! >>>>> >>>>> From man 8 useradd: >>>>> >>>>> Usernames may only be up to 32 characters long. >>>> >>>> This is a sysaccount so it has no login capabilities. >>>> >>>> I'm not aware of any RFC-specific maximum length for attributes. There >>>> may be implementation-specific limitations. >>>> >>>> Why do you ask? Is something not working? >>>> >>>> rob >> From flo at redhat.com Tue Feb 21 08:03:53 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 21 Feb 2017 09:03:53 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: References: <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> Message-ID: <1651351b-a6f4-7ded-d7be-48cd42bc2c3f@redhat.com> On 02/20/2017 04:09 PM, Matt . wrote: > Hi Rob, > > Yes it does, I understood that there was some reason the duplicate > might exist, but I wonder more why does the RootCA show up when I > removed it and comes back after adding the two intermediates ? > Hi Matt, when ipa-cacert-manage install is run, it adds an LDAP entry for the new CA certificate below cn=certificates,cn=ipa,cn=etc,$BASEDN. When ipa-certupdate is run, it adds all the certificates found in cn=certificates,cn=ipa,cn=etc,$BASEDN to /etc/httpd/alias. So even if you remove one certificate from /etc/httpd/alias, the next ipa-certupdate command will re-add this CA cert if it is still present in LDAP. Hope this clarifies, Flo. > Thanks > > Matt > > > 2017-02-20 15:20 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> Hi, >>> >>> The install seems to be OK this way, but I'm still confused about the >>> duplicated and the RootCA. >> >> What does this show? >> >> #3 certutil -L -d /etc/httpd/alias -n COMODORSAAddTrustCA >> >> I'm guessing it will show two certs with different serial numbers, which >> means this is a-ok. >> >> rob >> >>> >>> 2017-02-18 14:47 GMT+01:00 Matt . : >>>> Hi Florance, >>>> >>>> >>>> I'm actually stil investigating this as the following occurs. >>>> >>>> I have removed all unneeded certs and installed the 2 intermediates >>>> for Comodo and did an ipa-certupdate which results in this: >>>> >>>> #certutil -L -d /etc/httpd/alias >>>> >>>> Certificate Nickname Trust Attributes >>>> SSL,S/MIME,JAR/XPI >>>> >>>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>>> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >>>> AddTrustExternalCARoot C,, >>>> ipaCert u,u,u >>>> COMODORSAAddTrustCA C,, >>>> COMODORSAAddTrustCA C,, >>>> IPA.MYDOMAIN.TLD IPA CA CT,C,C >>>> >>>> >>>> I'm curious why the COMODORSAAddTrustCA is there twice, if I remove >>>> both and start over they are duplicated again. Also the >>>> AddTrustExternalCARoot comes back again even when this was not >>>> installed anymore as it's not needed. >>>> >>>> I'm able to install my cert after the update: >>>> >>>> >>>> #certutil -L -d /etc/httpd/alias >>>> >>>> Certificate Nickname Trust Attributes >>>> SSL,S/MIME,JAR/XPI >>>> >>>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>>> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >>>> AddTrustExternalCARoot C,, >>>> ipaCert u,u,u >>>> COMODORSAAddTrustCA C,, >>>> COMODORSAAddTrustCA C,, >>>> IPA.MYDOMAIN.TLD IPA CA CT,C,C >>>> CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control Validated u,u,u >>>> >>>> >>>> >>>> Now this works great for the WebGui which uses the right Certificate >>>> for the ssl connection but ldaps on port 636 seems to use: >>>> >>>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>>> Limited,L=Salford,ST=Greater Manchester,C=GB >>>> >>>> >>>> Do you have any clue about this ? >>>> >>>> I'm also curious about what IPA syncs between all hosts, it seems to >>>> be only the Intermediate certs and not the install domains >>>> certificate, this needs to be installed manually after a local >>>> #ipa-certupdate on each node ? >>>> >>>> I hope you can clearify this out. >>>> >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> >>>> 2017-02-17 0:15 GMT+01:00 Matt . : >>>>> Hi Flo, >>>>> >>>>> Sure I can, I will look through the steps closely tomorrow and will >>>>> create some lineup here. >>>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud : >>>>>> On 02/16/2017 09:55 PM, Matt . wrote: >>>>>>> >>>>>>> Hi Flo! (if I may call you like that, saves some characters in typing >>>>>>> but with this extra line it doesn't anymore :)) >>>>>>> >>>>>>> This works perfectly, thank you very much. >>>>>>> >>>>>> Hi Matt, >>>>>> >>>>>> glad I could help. What did you do differently that could explain the >>>>>> failure, though? Maybe the cert installation needs some hardening. >>>>>> >>>>>> Flo. >>>>>> >>>>>>> No questions further actually :) >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >>>>>>>> >> From t.ruiten at rdmedia.com Tue Feb 21 08:37:18 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Tue, 21 Feb 2017 09:37:18 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: <3ea10958-6805-1f14-94d7-14124fd37eeb@redhat.com> Message-ID: Flo, Do you have any pointers? On 20 February 2017 at 10:05, Tiemen Ruiten wrote: > Hello Flo, > > Thanks for your response. I ran that command and I seem to have a > different problem (connectors are defined as you indicated): > > [tiemen at copernicum ~]$ sudo getcert list -d /etc/dirsrv/slapd-IPA-RDMEDIA- >> COM/ >> [sudo] password for tiemen: >> Number of certificates and requests being tracked: 2. >> Request ID '20170217130857': >> status: CA_UNREACHABLE >> ca-error: Server at https://moscovium.ipa.rdmedia.com/ipa/xml failed >> request, will retry: 4301 (RPC failed at server. Certificate operation >> cannot be completed: FAILURE (*CA not found: >> 1ba8130c-56b8-4bd9-ae8a-8b0333d71b80*)). >> stuck: no >> key pair storage: type=NSSDB,location='/etc/ >> dirsrv/slapd-IPA-RDMEDIA-COM',nickname='Server-Cert',token='NSS >> Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt' >> certificate: type=NSSDB,location='/etc/dirsrv/slapd-IPA-RDMEDIA-COM', >> nickname='Server-Cert' >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes > > > > > > > > On 20 February 2017 at 09:28, Florence Blanc-Renaud > wrote: > >> On 02/17/2017 10:36 AM, Tiemen Ruiten wrote: >> >>> I went through that bugreport, particularly this section... >>> >>> OK, I think I found the error. On the logs I get something like this >>> *before* the failing dirsrv restart: >>> >>> 2017-01-14T03:41:28Z DEBUG [27/44]: retrieving DS Certificate >>> 2017-01-14T03:41:28Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2017-01-14T03:41:28Z DEBUG Starting external process >>> 2017-01-14T03:41:28Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM >>> IPA CA -a >>> 2017-01-14T03:41:28Z DEBUG Process finished, return code=255 >>> 2017-01-14T03:41:28Z DEBUG stdout= >>> 2017-01-14T03:41:28Z DEBUG stderr=certutil: Could not find cert: >>> EXAMPLE.COM IPA CA >>> : PR_FILE_NOT_FOUND_ERROR: File not found >>> >>> >> Hi, >> >> this error shows that the server certificate for the LDAP server is not >> present in the NSS database. I am pretty sure that if you run >> $ getcert list -d /etc/dirsrv/slapd-DOMAIN >> you will get an error like this one: >> status: CA_UNREACHABLE >> ca-error: Server at https://ipa.EXAMPLE.COM/ipa/xml failed >> request, will retry: 4301 (RPC failed at server. Certificate operation >> cannot be completed: Unable to communicate with CMS (503)). >> >> Make sure that the file /etc/pki/pki-tomcat/server.xml (on all the >> masters) defines the AJP connector like this: >> > protocol="AJP/1.3" >> redirectPort="8443" >> address="localhost" /> >> and that the /etc/hosts file (on all the masters) properly defines >> localhost: >> 127.0.0.1 localhost localhost.localdomain localhost4 >> localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 >> localhost6.localdomain6 >> Then restart the PKI service on the masters: >> systemctl stop pki-tomcatd at pki-tomcat.service >> >> After this, you should be able to re-run ipa-replica-install without any >> problem. >> HTH, >> Flo. >> >> So, when the process stopped, I run the command again: >>> >>> # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM >>> IPA CA -a >>> certutil: Could not find cert: EXAMPLE.COM >>> : PR_FILE_NOT_FOUND_ERROR: File not found >>> >>> and thought "wait... something is missing there": >>> >>> # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n "EXAMPLE.COM >>> IPA CA" -a >>> -----BEGIN CERTIFICATE----- >>> >>> -----END CERTIFICATE----- >>> >>> So, could this be the problem? >>> >>> >>> ...and indeed when I run >>> >>> [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM >>> IPA CA -a >>> [sudo] password for tiemen: >>> certutil: Could not find cert: IPA.RDMEDIA.COM < >>> http://IPA.RDMEDIA.COM> >>> : PR_FILE_NOT_FOUND_ERROR: File not found >>> >>> >>> and when I run >>> >>> [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n "IPA.RDMEDIA.COM >>> IPA CA" -a >>> -----BEGIN CERTIFICATE----- >>> >>> -----END CERTIFICATE----- >>> >>> valid certificate output. Where can I change this command to quote this >>> string? >>> >>> >>> On 16 February 2017 at 17:29, Jeff Goddard >> > wrote: >>> >>> Might be another instance of this: >>> https://fedorahosted.org/freeipa/ticket/6613 >>> >>> >>> Jeff >>> >>> On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten >>> > wrote: >>> >>> Hello, >>> >>> I'm trying to add a third replica to a FreeIPA 4.4 domain (level >>> 1), but I'm getting this error: >>> >>> [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w >>> "XXXXXXXXXX" --mkhomedir --setup-dns --forwarder 8.8.8.8 >>> --forwarder 8.8.4.4 >>> Checking DNS forwarders, please wait ... >>> Run connection check to master >>> Connection check OK >>> 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 (dirsrv). Estimated time: 1 >>> minute >>> [1/44]: creating directory server user >>> [2/44]: creating directory server instance >>> [3/44]: updating configuration in dse.ldif >>> [4/44]: restarting directory server >>> [5/44]: adding default schema >>> [6/44]: enabling memberof plugin >>> [7/44]: enabling winsync plugin >>> [8/44]: configuring replication version plugin >>> [9/44]: enabling IPA enrollment plugin >>> [10/44]: enabling ldapi >>> [11/44]: configuring uniqueness plugin >>> [12/44]: configuring uuid plugin >>> [13/44]: configuring modrdn plugin >>> [14/44]: configuring DNS plugin >>> [15/44]: enabling entryUSN plugin >>> [16/44]: configuring lockout plugin >>> [17/44]: configuring topology plugin >>> [18/44]: creating indices >>> [19/44]: enabling referential integrity plugin >>> [20/44]: configuring certmap.conf >>> [21/44]: configure autobind for root >>> [22/44]: configure new location for managed entries >>> [23/44]: configure dirsrv ccache >>> [24/44]: enabling SASL mapping fallback >>> [25/44]: restarting directory server >>> [26/44]: creating DS keytab >>> [27/44]: retrieving DS Certificate >>> [28/44]: restarting directory server >>> ipa : CRITICAL Failed to restart the directory >>> server (Command '/bin/systemctl restart >>> dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit >>> status 1). See the installation log for details. >>> [29/44]: setting up initial replication >>> [error] error: [Errno 111] Connection refused >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR >>> [Errno 111] Connection refused >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR >>> The ipa-replica-install command failed. See >>> /var/log/ipareplica-install.log for more information >>> >>> >>> In /var/log/ipareplica-install.log we find: >>> >>> 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS >>> Certificate >>> 2017-02-16T15:53:59Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM >>> IPA CA -a >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find >>> cert: IPA.RDMEDIA.COM IPA CA >>> : PR_FILE_NOT_FOUND_ERROR: File not found* >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> 2017-02-16T15:53:59Z DEBUG stderr= >>> 2017-02-16T15:53:59Z DEBUG Starting external process >>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM >>> IPA CA -t CT,C,C -a >>> >>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:53:59Z DEBUG stdout= >>> 2017-02-16T15:53:59Z DEBUG stderr= >>> 2017-02-16T15:53:59Z DEBUG certmonger request is in state >>> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1) >>> 2017-02-16T15:54:04Z DEBUG certmonger request is in state >>> dbus.String(u'CA_UNREACHABLE', variant_level=1) >>> 2017-02-16T15:54:04Z DEBUG flushing >>> ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket from >>> SchemaCache >>> 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache >>> url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>> conn=>> 0x74efd40> >>> 2017-02-16T15:54:05Z DEBUG duration: 5 seconds >>> 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory >>> server >>> 2017-02-16T15:54:05Z DEBUG Starting external process >>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system >>> daemon-reload >>> 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 >>> 2017-02-16T15:54:05Z DEBUG stdout= >>> 2017-02-16T15:54:05Z DEBUG stderr= >>> 2017-02-16T15:54:05Z DEBUG Starting external process >>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart >>> dirsrv at IPA-RDMEDIA-COM.service >>> 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 >>> 2017-02-16T15:54:06Z DEBUG stdout= >>> 2017-02-16T15:54:06Z DEBUG stderr=Job for >>> dirsrv at IPA-RDMEDIA-COM.service failed because the control >>> process exited with error code. See "systemctl status >>> dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for >>> details. >>> 2017-02-16T15:54:06Z CRITICAL Failed to restart the >>> directory server (Command '/bin/systemctl restart >>> dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit >>> status 1). See the installation log for details. >>> 2017-02-16T15:54:06Z DEBUG duration: 1 seconds >>> 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial >>> replication >>> 2017-02-16T15:54:16Z DEBUG Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >>> py", >>> line 449, in start_creation >>> run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >>> py", >>> line 439, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstan >>> ce.py", >>> line 405, in __setup_replica >>> self.dm_password) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/replicat >>> ion.py", >>> line 118, in enable_replication_version_checking >>> conn.do_simple_bind(bindpw=dirman_passwd) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>> line 1665, in do_simple_bind >>> self.__bind_with_wait(self.simple_bind, timeout, binddn, >>> bindpw) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>> line 1660, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>> line 1643, in __wait_for_connection >>> wait_for_open_socket(lurl.hostport, timeout) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >>> line 1286, in wait_for_open_socket >>> raise e >>> error: [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] >>> Connection refused >>> 2017-02-16T15:54:16Z DEBUG Destroyed connection >>> context.ldap2_78478480 >>> 2017-02-16T15:54:16Z 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/ipapython/install/cli.py", >>> line 318, in run >>> cfgr.run() >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 310, in run >>> self.execute() >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 332, in execute >>> for nothing in self._executor(): >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 372, in __runner >>> self._handle_exception(exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 394, in _handle_exception >>> six.reraise(*exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 362, in __runner >>> step() >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 359, in >>> step = lambda: next(self.__gen) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line >>> 81, in run_generator_with_yield_from >>> six.reraise(*exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line >>> 59, in run_generator_with_yield_from >>> value = gen.send(prev_value) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 586, in _configure >>> next(executor) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 372, in __runner >>> self._handle_exception(exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 449, in _handle_exception >>> self.__parent._handle_exception(exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 394, in _handle_exception >>> six.reraise(*exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 446, in _handle_exception >>> super(ComponentBase, self)._handle_exception(exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 394, in _handle_exception >>> six.reraise(*exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 362, in __runner >>> step() >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >>> line >>> 359, in >>> step = lambda: next(self.__gen) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line >>> 81, in run_generator_with_yield_from >>> six.reraise(*exc_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >>> line >>> 59, in run_generator_with_yield_from >>> value = gen.send(prev_value) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/install/common.p >>> y", >>> line 63, in _install >>> for nothing in self._installer(self.parent): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/r >>> eplicainstall.py", >>> line 1714, in main >>> promote(self) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/r >>> eplicainstall.py", >>> line 364, in decorated >>> func(installer) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/r >>> eplicainstall.py", >>> line 1415, in promote >>> promote=True, pkcs12_info=dirsrv_pkcs12_info) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/r >>> eplicainstall.py", >>> line 127, in install_replica_ds >>> api=remote_api, >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstan >>> ce.py", >>> line 399, in create_replica >>> self.start_creation(runtime=60) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >>> py", >>> line 449, in start_creation >>> run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service. >>> py", >>> line 439, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstan >>> ce.py", >>> line 405, in __setup_replica >>> self.dm_password) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/replicat >>> ion.py", >>> line 118, in enable_replication_version_checking >>> conn.do_simple_bind(bindpw=dirman_passwd) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>> line 1665, in do_simple_bind >>> self.__bind_with_wait(self.simple_bind, timeout, binddn, >>> bindpw) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>> line 1660, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>> line 1643, in __wait_for_connection >>> wait_for_open_socket(lurl.hostport, timeout) >>> File >>> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >>> line 1286, in wait_for_open_socket >>> raise e >>> 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command >>> failed, exception: error: [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused >>> 2017-02-16T15:54:16Z ERROR The ipa-replica-install command >>> failed. See /var/log/ipareplica-install.log for more >>> information >>> >>> >>> How can I troubleshoot this? >>> >>> >>> >>> -- >>> Tiemen Ruiten >>> Systems Engineer >>> R&D Media >>> >>> -- >>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Tiemen Ruiten >>> Systems Engineer >>> R&D Media >>> >>> >>> >> > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Tue Feb 21 08:38:36 2017 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 21 Feb 2017 10:38:36 +0200 Subject: [Freeipa-users] Installing on Ubuntu In-Reply-To: References: <0415223c-2158-f84e-4e29-bc9b5d9f657c@ubuntu.com> Message-ID: On 20.02.2017 22:26, Robert L. Harris wrote: > > python2 -c 'from ipaserver.install import installutils; print "yes" if > installutils.is_ipa_configured() else "no";' > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named ipaserver.install Then how did you manage to get it installed.. freeipa-server depends on python-ipaserver so you should have it available :) -- t From dan.paris at cgi.com Tue Feb 21 10:27:40 2017 From: dan.paris at cgi.com (Paris, Dan) Date: Tue, 21 Feb 2017 10:27:40 +0000 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA Message-ID: <063A1ABE401EB14FABF212F5328F5CE993C60E92@se-ex024.groupinfra.com> Hi FreeIPA-users, My colleague Nick Piper emailed previously regarding the subject matter. We are still attempting to find a solution that meets our requirements and are considering manually building an ldif file to import into our master IdM server. In the reply to our original query Alexander Bokovoy mentioned: "In short, there is no support for IPA-IPA trust or replication. There are many reasons for that, including some complex technical issues on how this could be reliably working." Would you be able to provide some detail around these technical issues and provide some guidance as to if exporting an ldif file would meet our needs? Thanks in advance, Dan Dan Paris | Leading Engineer 250 Brook Drive, Reading, RG2 6UA | United Kingdom M: +44 7920783573 dan.paris at cgi.com | www.cgi.com Registered in England & Wales (registered number 947968) Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United Kingdom -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at 0xc0dedbad.com Tue Feb 21 12:36:40 2017 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Tue, 21 Feb 2017 23:36:40 +1100 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! Message-ID: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> I don't know why the certs did not auto-renew originally, but now I am very stuck trying to get my CA functional again. I've tried setting the clock back to a week or two before the certs were due to expire, but I'm still having no luck getting the CA functional. This is a Ubuntu server, so some paths are different to what may be found on RPM-based distros. Any urgent help would be greatly appreciated - I've been bashing against this for a couple of hours now with no luck, and the hour is getting late. Below is my current (anonymized) `getcert list` of the problem certs, where you will see my current ca-error: Request ID '20160616123036': status: CA_UNREACHABLE ca-error: Error 77 connecting to https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). stuck: no key pair storage: type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt' certificate: type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=IPA RA,O=EXAMPLE.COM expires: 2017-02-11 05:52:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/lib/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20160616123427': status: CA_UNREACHABLE ca-error: Error 77 connecting to https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Audit,O=EXAMPLE.COM expires: 2017-02-11 05:52:03 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib/ipa/certmonger/stop_pkicad post-save command: /usr/lib/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160616123428': status: CA_UNREACHABLE ca-error: Error 77 connecting to https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=OCSP Subsystem,O=EXAMPLE.COM expires: 2017-02-11 05:52:01 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/lib/ipa/certmonger/stop_pkicad post-save command: /usr/lib/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160616123429': status: CA_UNREACHABLE ca-error: Error 77 connecting to https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Subsystem,O=EXAMPLE.COM expires: 2017-02-11 05:52:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib/ipa/certmonger/stop_pkicad post-save command: /usr/lib/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes All I get in the logs (with debug enabled) is: Jan 20 06:52:52 ipaserver.example.com dogtag-ipa-ca-renew-agent-submit[2121]: Forwarding request to dogtag-ipa-renew-agent Jan 20 06:52:52 ipaserver.example.com dogtag-ipa-renew-agent-submit[2307]: GET https://ipaserver.example.com:8443/ca/agent/ca/profileReview?requestId=69960009&xml=true Jan 20 06:52:52 ipaserver.example.com dogtag-ipa-renew-agent-submit[2307]: (null) Jan 20 06:52:52 ipaserver.example.com dogtag-ipa-ca-renew-agent-submit[2121]: dogtag-ipa-renew-agent returned 3 Jan 20 06:52:52 ipaserver.example.com certmonger[2016]: 2017-01-20 06:52:52 [2016] Error 77 connecting to https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). From iulian.roman at gmail.com Tue Feb 21 15:25:11 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Tue, 21 Feb 2017 16:25:11 +0100 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server Message-ID: Hello, Does anybody know if the rfc2307aix schema is supported in IPA server (i use red hat IDM version) ? If yes, is there any documentation available ? Was it tested ? I plan for a big migration and full support of the AIX user attributes is one of the prerequisites. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 21 15:31:02 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 21 Feb 2017 10:31:02 -0500 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server In-Reply-To: References: Message-ID: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> Iulian Roman wrote: > Hello, > > Does anybody know if the rfc2307aix schema is supported in IPA server (i > use red hat IDM version) ? If yes, is there any documentation available > ? Was it tested ? No, it isn't supported (it's the first I've ever heard of it). Looking at the schema I doubt it is something that would ever be fully supported. rob > > I plan for a big migration and full support of the AIX user attributes > is one of the prerequisites. From yamakasi.014 at gmail.com Tue Feb 21 15:31:51 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 21 Feb 2017 16:31:51 +0100 Subject: [Freeipa-users] Cannot install 3rd party certificate In-Reply-To: <1651351b-a6f4-7ded-d7be-48cd42bc2c3f@redhat.com> References: <06df2789-8f11-005e-1ce4-6ca6090696aa@redhat.com> <7fa47189-e8f2-3d4d-b1a4-d4e6d5713994@redhat.com> <1651351b-a6f4-7ded-d7be-48cd42bc2c3f@redhat.com> Message-ID: Hi Flo, Yes it does! Thanks for that. Is it not possible to remove a certificate fully as it always syncs this way ? Or remove it from /etc/httpd/alias, then from ldap and then sync again ? Cheers, Matt 2017-02-21 9:03 GMT+01:00 Florence Blanc-Renaud : > On 02/20/2017 04:09 PM, Matt . wrote: >> >> Hi Rob, >> >> Yes it does, I understood that there was some reason the duplicate >> might exist, but I wonder more why does the RootCA show up when I >> removed it and comes back after adding the two intermediates ? >> > Hi Matt, > > when ipa-cacert-manage install is run, it adds an LDAP entry for the new CA > certificate below cn=certificates,cn=ipa,cn=etc,$BASEDN. > When ipa-certupdate is run, it adds all the certificates found in > cn=certificates,cn=ipa,cn=etc,$BASEDN to /etc/httpd/alias. > So even if you remove one certificate from /etc/httpd/alias, the next > ipa-certupdate command will re-add this CA cert if it is still present in > LDAP. > > Hope this clarifies, > Flo. > > > >> Thanks >> >> Matt >> >> >> 2017-02-20 15:20 GMT+01:00 Rob Crittenden : >>> >>> Matt . wrote: >>>> >>>> Hi, >>>> >>>> The install seems to be OK this way, but I'm still confused about the >>>> duplicated and the RootCA. >>> >>> >>> What does this show? >>> >>> #3 certutil -L -d /etc/httpd/alias -n COMODORSAAddTrustCA >>> >>> I'm guessing it will show two certs with different serial numbers, which >>> means this is a-ok. >>> >>> rob >>> >>>> >>>> 2017-02-18 14:47 GMT+01:00 Matt . : >>>>> >>>>> Hi Florance, >>>>> >>>>> >>>>> I'm actually stil investigating this as the following occurs. >>>>> >>>>> I have removed all unneeded certs and installed the 2 intermediates >>>>> for Comodo and did an ipa-certupdate which results in this: >>>>> >>>>> #certutil -L -d /etc/httpd/alias >>>>> >>>>> Certificate Nickname Trust >>>>> Attributes >>>>> >>>>> SSL,S/MIME,JAR/XPI >>>>> >>>>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>>>> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >>>>> AddTrustExternalCARoot C,, >>>>> ipaCert u,u,u >>>>> COMODORSAAddTrustCA C,, >>>>> COMODORSAAddTrustCA C,, >>>>> IPA.MYDOMAIN.TLD IPA CA CT,C,C >>>>> >>>>> >>>>> I'm curious why the COMODORSAAddTrustCA is there twice, if I remove >>>>> both and start over they are duplicated again. Also the >>>>> AddTrustExternalCARoot comes back again even when this was not >>>>> installed anymore as it's not needed. >>>>> >>>>> I'm able to install my cert after the update: >>>>> >>>>> >>>>> #certutil -L -d /etc/httpd/alias >>>>> >>>>> Certificate Nickname Trust >>>>> Attributes >>>>> >>>>> SSL,S/MIME,JAR/XPI >>>>> >>>>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>>>> Limited,L=Salford,ST=Greater Manchester,C=GB C,, >>>>> AddTrustExternalCARoot C,, >>>>> ipaCert u,u,u >>>>> COMODORSAAddTrustCA C,, >>>>> COMODORSAAddTrustCA C,, >>>>> IPA.MYDOMAIN.TLD IPA CA CT,C,C >>>>> CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control >>>>> Validated u,u,u >>>>> >>>>> >>>>> >>>>> Now this works great for the WebGui which uses the right Certificate >>>>> for the ssl connection but ldaps on port 636 seems to use: >>>>> >>>>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA >>>>> Limited,L=Salford,ST=Greater Manchester,C=GB >>>>> >>>>> >>>>> Do you have any clue about this ? >>>>> >>>>> I'm also curious about what IPA syncs between all hosts, it seems to >>>>> be only the Intermediate certs and not the install domains >>>>> certificate, this needs to be installed manually after a local >>>>> #ipa-certupdate on each node ? >>>>> >>>>> I hope you can clearify this out. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> >>>>> 2017-02-17 0:15 GMT+01:00 Matt . : >>>>>> >>>>>> Hi Flo, >>>>>> >>>>>> Sure I can, I will look through the steps closely tomorrow and will >>>>>> create some lineup here. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud : >>>>>>> >>>>>>> On 02/16/2017 09:55 PM, Matt . wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Flo! (if I may call you like that, saves some characters in >>>>>>>> typing >>>>>>>> but with this extra line it doesn't anymore :)) >>>>>>>> >>>>>>>> This works perfectly, thank you very much. >>>>>>>> >>>>>>> Hi Matt, >>>>>>> >>>>>>> glad I could help. What did you do differently that could explain the >>>>>>> failure, though? Maybe the cert installation needs some hardening. >>>>>>> >>>>>>> Flo. >>>>>>> >>>>>>>> No questions further actually :) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud : >>>>>>>>> >>>>>>>>> >>> > From robert.l.harris at gmail.com Tue Feb 21 15:33:14 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Tue, 21 Feb 2017 15:33:14 +0000 Subject: [Freeipa-users] Installing on Ubuntu In-Reply-To: References: <0415223c-2158-f84e-4e29-bc9b5d9f657c@ubuntu.com> Message-ID: This was a clean install of Ubuntu. If I install freeipa-server I get the error from the original email. If I do a "apt install freeipa-server" I do see it will install python-ipaserver. When I let it run it downloads and everything and starts setting everything up. I get this: Setting up tomcat7-user (7.0.68-1ubuntu0.1) ... Setting up velocity (1.7-4) ... Setting up pki-server (10.2.6+git20160317-1) ... Job for pki-tomcatd.service failed because the control process exited with error code. See "systemctl status pki-tomcatd.service" and "journalctl -xe" for details. invoke-rc.d: initscript pki-tomcatd, action "start" failed. ... because no CA instance has been configured yet. pki-tomcatd-nuxwdog.target is a disabled or a static unit, not starting it. pki-tomcatd.target is a disabled or a static unit, not starting it. Setting up pki-ca (10.2.6+git20160317-1) ... Setting up pki-kra (10.2.6+git20160317-1) ... . It continues til I get this: . Setting up opendnssec (1:1.4.9-2) ... dpkg: dependency problems prevent configuration of freeipa-server-dns: freeipa-server-dns depends on freeipa-server (>= 4.3.1-0ubuntu1); however: Package freeipa-server is not configured yet. dpkg: error processing package freeipa-server-dns (--configure): dependency problems - leaving unconfigured No apport report written because the error message indicates its a followup error from a previous failure. Setting up libverto-libevent1:amd64 (0.2.4-2.1ubuntu2) ... Setting up libverto1:amd64 (0.2.4-2.1ubuntu2) ... . Continues a bit longer til: . Processing triggers for ureadahead (0.100.0-19) ... Errors were encountered while processing: 389-ds-base freeipa-server freeipa-server-dns E: Sub-process /usr/bin/dpkg returned an error code (1) If I run the python command you gave me at this point I get this: python2 -c 'from ipaserver.install import installutils; print "yes" if installutils.is_ipa_configured() else "no";' yes On Tue, Feb 21, 2017 at 1:38 AM Timo Aaltonen wrote: > On 20.02.2017 22:26, Robert L. Harris wrote: > > > > python2 -c 'from ipaserver.install import installutils; print "yes" if > > installutils.is_ipa_configured() else "no";' > > Traceback (most recent call last): > > File "", line 1, in > > ImportError: No module named ipaserver.install > > Then how did you manage to get it installed.. freeipa-server depends on > python-ipaserver so you should have it available :) > > > -- > t > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keesb at ghs.com Tue Feb 21 15:57:23 2017 From: keesb at ghs.com (Kees Bakker) Date: Tue, 21 Feb 2017 16:57:23 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks Message-ID: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home *(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d????????? ? ? ? ? ? nfshome -- Kees From t.ruiten at rdmedia.com Tue Feb 21 17:25:09 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Tue, 21 Feb 2017 18:25:09 +0100 Subject: [Freeipa-users] can't add replica: failed to start the directory server In-Reply-To: References: <3ea10958-6805-1f14-94d7-14124fd37eeb@redhat.com> Message-ID: Can anyone help? At this point I'm stuck and I may have to consider alternatives :( On 21 February 2017 at 09:37, Tiemen Ruiten wrote: > Flo, > > Do you have any pointers? > > On 20 February 2017 at 10:05, Tiemen Ruiten wrote: > >> Hello Flo, >> >> Thanks for your response. I ran that command and I seem to have a >> different problem (connectors are defined as you indicated): >> >> [tiemen at copernicum ~]$ sudo getcert list -d >>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ >>> [sudo] password for tiemen: >>> Number of certificates and requests being tracked: 2. >>> Request ID '20170217130857': >>> status: CA_UNREACHABLE >>> ca-error: Server at https://moscovium.ipa.rdmedia.com/ipa/xml failed >>> request, will retry: 4301 (RPC failed at server. Certificate operation >>> cannot be completed: FAILURE (*CA not found: >>> 1ba8130c-56b8-4bd9-ae8a-8b0333d71b80*)). >>> stuck: no >>> key pair storage: type=NSSDB,location='/etc/dirs >>> rv/slapd-IPA-RDMEDIA-COM',nickname='Server-Cert',token='NSS Certificate >>> DB',pinfile='/etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt' >>> certificate: type=NSSDB,location='/etc/dirs >>> rv/slapd-IPA-RDMEDIA-COM',nickname='Server-Cert' >>> CA: IPA >>> issuer: >>> subject: >>> expires: unknown >>> pre-save command: >>> post-save command: >>> track: yes >>> auto-renew: yes >> >> >> >> >> >> >> >> On 20 February 2017 at 09:28, Florence Blanc-Renaud >> wrote: >> >>> On 02/17/2017 10:36 AM, Tiemen Ruiten wrote: >>> >>>> I went through that bugreport, particularly this section... >>>> >>>> OK, I think I found the error. On the logs I get something like this >>>> *before* the failing dirsrv restart: >>>> >>>> 2017-01-14T03:41:28Z DEBUG [27/44]: retrieving DS Certificate >>>> 2017-01-14T03:41:28Z DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2017-01-14T03:41:28Z DEBUG Starting external process >>>> 2017-01-14T03:41:28Z DEBUG args=/usr/bin/certutil -d >>>> /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM >>>> IPA CA -a >>>> 2017-01-14T03:41:28Z DEBUG Process finished, return code=255 >>>> 2017-01-14T03:41:28Z DEBUG stdout= >>>> 2017-01-14T03:41:28Z DEBUG stderr=certutil: Could not find cert: >>>> EXAMPLE.COM IPA CA >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> >>> Hi, >>> >>> this error shows that the server certificate for the LDAP server is not >>> present in the NSS database. I am pretty sure that if you run >>> $ getcert list -d /etc/dirsrv/slapd-DOMAIN >>> you will get an error like this one: >>> status: CA_UNREACHABLE >>> ca-error: Server at https://ipa.EXAMPLE.COM/ipa/xml failed >>> request, will retry: 4301 (RPC failed at server. Certificate operation >>> cannot be completed: Unable to communicate with CMS (503)). >>> >>> Make sure that the file /etc/pki/pki-tomcat/server.xml (on all the >>> masters) defines the AJP connector like this: >>> >> protocol="AJP/1.3" >>> redirectPort="8443" >>> address="localhost" /> >>> and that the /etc/hosts file (on all the masters) properly defines >>> localhost: >>> 127.0.0.1 localhost localhost.localdomain localhost4 >>> localhost4.localdomain4 >>> ::1 localhost localhost.localdomain localhost6 >>> localhost6.localdomain6 >>> Then restart the PKI service on the masters: >>> systemctl stop pki-tomcatd at pki-tomcat.service >>> >>> After this, you should be able to re-run ipa-replica-install without any >>> problem. >>> HTH, >>> Flo. >>> >>> So, when the process stopped, I run the command again: >>>> >>>> # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM >>>> IPA CA -a >>>> certutil: Could not find cert: EXAMPLE.COM >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> and thought "wait... something is missing there": >>>> >>>> # /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n " >>>> EXAMPLE.COM IPA CA" -a >>>> -----BEGIN CERTIFICATE----- >>>> >>>> -----END CERTIFICATE----- >>>> >>>> So, could this be the problem? >>>> >>>> >>>> ...and indeed when I run >>>> >>>> [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM >>>> IPA CA -a >>>> [sudo] password for tiemen: >>>> certutil: Could not find cert: IPA.RDMEDIA.COM < >>>> http://IPA.RDMEDIA.COM> >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> >>>> and when I run >>>> >>>> [tiemen at copernicum ipapython]$ sudo /usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n "IPA.RDMEDIA.COM >>>> IPA CA" -a >>>> -----BEGIN CERTIFICATE----- >>>> >>>> -----END CERTIFICATE----- >>>> >>>> valid certificate output. Where can I change this command to quote this >>>> string? >>>> >>>> >>>> On 16 February 2017 at 17:29, Jeff Goddard >>> > wrote: >>>> >>>> Might be another instance of this: >>>> https://fedorahosted.org/freeipa/ticket/6613 >>>> >>>> >>>> Jeff >>>> >>>> On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten >>>> > wrote: >>>> >>>> Hello, >>>> >>>> I'm trying to add a third replica to a FreeIPA 4.4 domain (level >>>> 1), but I'm getting this error: >>>> >>>> [tiemen at copernicum ~]$ sudo ipa-replica-install -P admin -w >>>> "XXXXXXXXXX" --mkhomedir --setup-dns --forwarder 8.8.8.8 >>>> --forwarder 8.8.4.4 >>>> Checking DNS forwarders, please wait ... >>>> Run connection check to master >>>> Connection check OK >>>> 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 (dirsrv). Estimated time: 1 >>>> minute >>>> [1/44]: creating directory server user >>>> [2/44]: creating directory server instance >>>> [3/44]: updating configuration in dse.ldif >>>> [4/44]: restarting directory server >>>> [5/44]: adding default schema >>>> [6/44]: enabling memberof plugin >>>> [7/44]: enabling winsync plugin >>>> [8/44]: configuring replication version plugin >>>> [9/44]: enabling IPA enrollment plugin >>>> [10/44]: enabling ldapi >>>> [11/44]: configuring uniqueness plugin >>>> [12/44]: configuring uuid plugin >>>> [13/44]: configuring modrdn plugin >>>> [14/44]: configuring DNS plugin >>>> [15/44]: enabling entryUSN plugin >>>> [16/44]: configuring lockout plugin >>>> [17/44]: configuring topology plugin >>>> [18/44]: creating indices >>>> [19/44]: enabling referential integrity plugin >>>> [20/44]: configuring certmap.conf >>>> [21/44]: configure autobind for root >>>> [22/44]: configure new location for managed entries >>>> [23/44]: configure dirsrv ccache >>>> [24/44]: enabling SASL mapping fallback >>>> [25/44]: restarting directory server >>>> [26/44]: creating DS keytab >>>> [27/44]: retrieving DS Certificate >>>> [28/44]: restarting directory server >>>> ipa : CRITICAL Failed to restart the directory >>>> server (Command '/bin/systemctl restart >>>> dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit >>>> status 1). See the installation log for details. >>>> [29/44]: setting up initial replication >>>> [error] error: [Errno 111] Connection refused >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> ipa.ipapython.install.cli.install_tool(Replica): ERROR >>>> [Errno 111] Connection refused >>>> ipa.ipapython.install.cli.install_tool(Replica): ERROR >>>> The ipa-replica-install command failed. See >>>> /var/log/ipareplica-install.log for more information >>>> >>>> >>>> In /var/log/ipareplica-install.log we find: >>>> >>>> 2017-02-16T15:53:59Z DEBUG [27/44]: retrieving DS >>>> Certificate >>>> 2017-02-16T15:53:59Z DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2017-02-16T15:53:59Z DEBUG Starting external process >>>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM >>>> IPA CA -a >>>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=255 >>>> 2017-02-16T15:53:59Z DEBUG stdout= >>>> *2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find >>>> cert: IPA.RDMEDIA.COM IPA CA >>>> : PR_FILE_NOT_FOUND_ERROR: File not found* >>>> 2017-02-16T15:53:59Z DEBUG Starting external process >>>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt >>>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>>> 2017-02-16T15:53:59Z DEBUG stdout= >>>> 2017-02-16T15:53:59Z DEBUG stderr= >>>> 2017-02-16T15:53:59Z DEBUG Starting external process >>>> 2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d >>>> /etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM >>>> IPA CA -t CT,C,C -a >>>> >>>> 2017-02-16T15:53:59Z DEBUG Process finished, return code=0 >>>> 2017-02-16T15:53:59Z DEBUG stdout= >>>> 2017-02-16T15:53:59Z DEBUG stderr= >>>> 2017-02-16T15:53:59Z DEBUG certmonger request is in state >>>> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', >>>> variant_level=1) >>>> 2017-02-16T15:54:04Z DEBUG certmonger request is in state >>>> dbus.String(u'CA_UNREACHABLE', variant_level=1) >>>> 2017-02-16T15:54:04Z DEBUG flushing >>>> ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket from >>>> SchemaCache >>>> 2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache >>>> url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket >>>> conn=>>> 0x74efd40> >>>> 2017-02-16T15:54:05Z DEBUG duration: 5 seconds >>>> 2017-02-16T15:54:05Z DEBUG [28/44]: restarting directory >>>> server >>>> 2017-02-16T15:54:05Z DEBUG Starting external process >>>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system >>>> daemon-reload >>>> 2017-02-16T15:54:05Z DEBUG Process finished, return code=0 >>>> 2017-02-16T15:54:05Z DEBUG stdout= >>>> 2017-02-16T15:54:05Z DEBUG stderr= >>>> 2017-02-16T15:54:05Z DEBUG Starting external process >>>> 2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart >>>> dirsrv at IPA-RDMEDIA-COM.service >>>> 2017-02-16T15:54:06Z DEBUG Process finished, return code=1 >>>> 2017-02-16T15:54:06Z DEBUG stdout= >>>> 2017-02-16T15:54:06Z DEBUG stderr=Job for >>>> dirsrv at IPA-RDMEDIA-COM.service failed because the control >>>> process exited with error code. See "systemctl status >>>> dirsrv at IPA-RDMEDIA-COM.service" and "journalctl -xe" for >>>> details. >>>> 2017-02-16T15:54:06Z CRITICAL Failed to restart the >>>> directory server (Command '/bin/systemctl restart >>>> dirsrv at IPA-RDMEDIA-COM.service' returned non-zero exit >>>> status 1). See the installation log for details. >>>> 2017-02-16T15:54:06Z DEBUG duration: 1 seconds >>>> 2017-02-16T15:54:06Z DEBUG [29/44]: setting up initial >>>> replication >>>> 2017-02-16T15:54:16Z DEBUG Traceback (most recent call >>>> last): >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/service.py", >>>> line 449, in start_creation >>>> run_step(full_msg, method) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/service.py", >>>> line 439, in run_step >>>> method() >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/dsinstance.py", >>>> line 405, in __setup_replica >>>> self.dm_password) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/replication.py", >>>> line 118, in enable_replication_version_checking >>>> conn.do_simple_bind(bindpw=dirman_passwd) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>> line 1665, in do_simple_bind >>>> self.__bind_with_wait(self.simple_bind, timeout, >>>> binddn, >>>> bindpw) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>> line 1660, in __bind_with_wait >>>> self.__wait_for_connection(timeout) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>> line 1643, in __wait_for_connection >>>> wait_for_open_socket(lurl.hostport, timeout) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >>>> line 1286, in wait_for_open_socket >>>> raise e >>>> error: [Errno 111] Connection refused >>>> 2017-02-16T15:54:16Z DEBUG [error] error: [Errno 111] >>>> Connection refused >>>> 2017-02-16T15:54:16Z DEBUG Destroyed connection >>>> context.ldap2_78478480 >>>> 2017-02-16T15:54:16Z 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-packa >>>> ges/ipapython/install/cli.py", >>>> line 318, in run >>>> cfgr.run() >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 310, in run >>>> self.execute() >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 332, in execute >>>> for nothing in self._executor(): >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 372, in __runner >>>> self._handle_exception(exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 394, in _handle_exception >>>> six.reraise(*exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 362, in __runner >>>> step() >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 359, in >>>> step = lambda: next(self.__gen) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/util.py", line >>>> 81, in run_generator_with_yield_from >>>> six.reraise(*exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/util.py", line >>>> 59, in run_generator_with_yield_from >>>> value = gen.send(prev_value) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 586, in _configure >>>> next(executor) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 372, in __runner >>>> self._handle_exception(exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 449, in _handle_exception >>>> self.__parent._handle_exception(exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 394, in _handle_exception >>>> six.reraise(*exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 446, in _handle_exception >>>> super(ComponentBase, self)._handle_exception(exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 394, in _handle_exception >>>> six.reraise(*exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 362, in __runner >>>> step() >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/core.py", line >>>> 359, in >>>> step = lambda: next(self.__gen) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/util.py", line >>>> 81, in run_generator_with_yield_from >>>> six.reraise(*exc_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/util.py", line >>>> 59, in run_generator_with_yield_from >>>> value = gen.send(prev_value) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipapython/install/common.py", >>>> line 63, in _install >>>> for nothing in self._installer(self.parent): >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/server/replicainstall.py", >>>> line 1714, in main >>>> promote(self) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/server/replicainstall.py", >>>> line 364, in decorated >>>> func(installer) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/server/replicainstall.py", >>>> line 1415, in promote >>>> promote=True, pkcs12_info=dirsrv_pkcs12_info) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/server/replicainstall.py", >>>> line 127, in install_replica_ds >>>> api=remote_api, >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/dsinstance.py", >>>> line 399, in create_replica >>>> self.start_creation(runtime=60) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/service.py", >>>> line 449, in start_creation >>>> run_step(full_msg, method) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/service.py", >>>> line 439, in run_step >>>> method() >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/dsinstance.py", >>>> line 405, in __setup_replica >>>> self.dm_password) >>>> File >>>> "/usr/lib/python2.7/site-packa >>>> ges/ipaserver/install/replication.py", >>>> line 118, in enable_replication_version_checking >>>> conn.do_simple_bind(bindpw=dirman_passwd) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>> line 1665, in do_simple_bind >>>> self.__bind_with_wait(self.simple_bind, timeout, >>>> binddn, >>>> bindpw) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>> line 1660, in __bind_with_wait >>>> self.__wait_for_connection(timeout) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>> line 1643, in __wait_for_connection >>>> wait_for_open_socket(lurl.hostport, timeout) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >>>> line 1286, in wait_for_open_socket >>>> raise e >>>> 2017-02-16T15:54:16Z DEBUG The ipa-replica-install command >>>> failed, exception: error: [Errno 111] Connection refused >>>> 2017-02-16T15:54:16Z ERROR [Errno 111] Connection refused >>>> 2017-02-16T15:54:16Z ERROR The ipa-replica-install command >>>> failed. See /var/log/ipareplica-install.log for more >>>> information >>>> >>>> >>>> How can I troubleshoot this? >>>> >>>> >>>> >>>> -- >>>> Tiemen Ruiten >>>> Systems Engineer >>>> R&D Media >>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Tiemen Ruiten >>>> Systems Engineer >>>> R&D Media >>>> >>>> >>>> >>> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> > > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Tue Feb 21 18:49:46 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 21 Feb 2017 13:49:46 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> Message-ID: On 02/21/2017 10:57 AM, Kees Bakker wrote: > Hey, > > Maybe one of the NFS users on this list could give me a hint what > could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. > > I've set up an NFS server and I can mount the NFS directory on my client. So, I'm > guessing that setting up Kerberos principal was done correctly. > > However, only root can actually access the mounted contents. Any other user > only sees question marks as shown below. > > The mount command is simple. > $ sudo mount -v -t nfs srv1.example.com:/home /nfshome > mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 > mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' > > On the server side /etc/exports looks like this. > /home *(rw,sync,sec=krb5i,no_subtree_check) > > $ sudo mount |grep nfs > srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) > > $ sudo ls -ld /nfshome > drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome > $ sudo ls -l /nfshome > total 0 > drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb > > $ ls -l /nfshome > ls: cannot access '/nfshome': Permission denied > $ ls -l / | grep nfshome > ls: cannot access '/nfshome': Permission denied > d????????? ? ? ? ? ? nfshome > sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) brendan From tjaalton at ubuntu.com Tue Feb 21 20:02:56 2017 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 21 Feb 2017 22:02:56 +0200 Subject: [Freeipa-users] Installing on Ubuntu In-Reply-To: References: <0415223c-2158-f84e-4e29-bc9b5d9f657c@ubuntu.com> Message-ID: On 21.02.2017 17:33, Robert L. Harris wrote: > This was a clean install of Ubuntu. If I install freeipa-server I get > the error from the original email. If I do a "apt install > freeipa-server" I do see it will install python-ipaserver. When I let > it run it downloads and everything and starts setting everything up. I > get this: > > Processing triggers for ureadahead (0.100.0-19) ... > Errors were encountered while processing: > 389-ds-base > freeipa-server > freeipa-server-dns > E: Sub-process /usr/bin/dpkg returned an error code (1) And I installed it on a clean chroot and the packages installed fine without issues. Note that the pki-server spam is expected and not an error. > If I run the python command you gave me at this point I get this: > > python2 -c 'from ipaserver.install import installutils; print "yes" if > installutils.is_ipa_configured() else "no";' > yes This means that you have some files around which a clean install should not have. Check the contents of /var/lib/ipa/sysrestore. From iulian.roman at gmail.com Tue Feb 21 20:03:18 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Tue, 21 Feb 2017 21:03:18 +0100 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server In-Reply-To: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> References: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> Message-ID: On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden wrote: > Iulian Roman wrote: > > Hello, > > > > Does anybody know if the rfc2307aix schema is supported in IPA server (i > > use red hat IDM version) ? If yes, is there any documentation available > > ? Was it tested ? > > No, it isn't supported (it's the first I've ever heard of it). Looking > at the schema I doubt it is something that would ever be fully supported. > > is there any possibility to extend the existing schema with additional attributes/object classes ? IPA integrates seamless in the Linux environment and it would be nice to make that possible also for the Unix environment. Enterprise environment is quite heterogeneous and a solution which would facilitate the consolidation of authentication and authorization methods is still something many companies are looking for. There are different solutions for different platforms , with different features, but none which can be used cross platform. I hope IPA will try to bridge this gap in the near future. rob > > > > > I plan for a big migration and full support of the AIX user attributes > > is one of the prerequisites. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Tue Feb 21 20:10:09 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Tue, 21 Feb 2017 12:10:09 -0800 Subject: [Freeipa-users] ldapsearch for AD users Message-ID: Hello, I've got the FreeIPA server with AD trust (Server 2008 R2) setup and running. I can login successfully on linux clients using AD credentials. I'm now trying to setup my Isilon storage appliance with mixed mode file sharing. The filer has joined the AD so it provides Windows users access to the files. However, being a legacy client, it uses simple bind to query ldap for uid and gid. I was able to setup FreeIPA as the ldap server but it doesn't seem to return the uid and gid for AD objects. The query my storage is using is as follows: ldapsearch -x -W -z 10 -H ldap://ipa.server.com -b 'cn=compat,dc=ipa,dc=server,dc=com' -D 'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' '(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=nisNetgroup)(objectClass=person))' The following command will obtain all the IDs for the native FreeIPA users / groups but don't return any results for AD users. Is there a way to get this done? I can't install any clients on the Isilon as it uses a BSD based proprietary software. I can manually map FreeIPA assigned uids / gids but that's tedious and error prone. Any help would be appreciated. Regards, H. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.l.harris at gmail.com Tue Feb 21 21:14:07 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Tue, 21 Feb 2017 21:14:07 +0000 Subject: [Freeipa-users] Installing on Ubuntu In-Reply-To: References: <0415223c-2158-f84e-4e29-bc9b5d9f657c@ubuntu.com> Message-ID: Ok, I removed the files in that directory, manually removed 389-ds-base, cleaned up the user/group and some left over directories and all installed/configured correctly. -R On Tue, Feb 21, 2017 at 1:03 PM Timo Aaltonen wrote: > On 21.02.2017 17:33, Robert L. Harris wrote: > > This was a clean install of Ubuntu. If I install freeipa-server I get > > the error from the original email. If I do a "apt install > > freeipa-server" I do see it will install python-ipaserver. When I let > > it run it downloads and everything and starts setting everything up. I > > get this: > > > > Processing triggers for ureadahead (0.100.0-19) ... > > Errors were encountered while processing: > > 389-ds-base > > freeipa-server > > freeipa-server-dns > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > And I installed it on a clean chroot and the packages installed fine > without issues. Note that the pki-server spam is expected and not an error. > > > If I run the python command you gave me at this point I get this: > > > > python2 -c 'from ipaserver.install import installutils; print "yes" if > > installutils.is_ipa_configured() else "no";' > > yes > > This means that you have some files around which a clean install should > not have. Check the contents of /var/lib/ipa/sysrestore. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Wed Feb 22 01:24:08 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 21 Feb 2017 20:24:08 -0500 Subject: [Freeipa-users] IDM server doesn't boot after update to RHEL 7.3 In-Reply-To: References: Message-ID: Any systemd experts that can help in figuring out what's going on here ? Here's a shortened log up to that error if it makes it more convenient: https://gist.github.com/pgera/00f1ae31f77b9e9aa652db2be0e29574 On Fri, Feb 17, 2017 at 8:40 PM, Prasun Gera wrote: > I now have a detailed debug log for this failed boot which I've attached > with the mail. The issue seems to be specific to this system. The replica > was updated to 7.3 too, and it works fine. I've zipped the log because it's > quite big. The original workaround still holds true. i.e. I boot in rescue > mode, start sssd, and then call isolate graphical.target which makes > everything work normally. With the graphical target as default, the system > doesn't boot. Somehow sssd is involved in the mix. > > Can someone please have a look at the log ? > > On Thu, Nov 10, 2016 at 12:53 PM, Prasun Gera > wrote: > >> Yes, from my experiments, it gets stuck at some point where it has to >> start avahi. And it fails to start it because it is dependent on something >> that is not started yet (which is started when sssd is started). Googling >> for that error pointed took me to http://www.calculate-linux.org >> /boards/15/topics/26673, which seems to be somewhat related I >> think. I'll post the journal messages soon. Is there some sort of a systemd >> diff utility which can compare the start sequence of services from two >> different systems ? Since my replica is on 7.2, which afaik works fine, >> doing a diff between the two might highlight if something has changed in >> the start sequence. >> >> On Thu, Nov 10, 2016 at 12:35 PM, Petr Vobornik >> wrote: >> >>> On 11/09/2016 12:53 PM, Prasun Gera wrote: >>> > It looks like something is messed up in the systemd configuration >>> after 7.3. My >>> > system doesn't boot at all. The boot screen would display the message: >>> "Failed >>> > to register match for Disconnected message: Connection timed out". >>> After some >>> > trial and error, I've managed to boot it. Here's what works right now: >>> 1) Boot >>> > into system rescue target with debug shell 2) start sssd 3) isolate >>> graphical.target >>> > >>> > I have a replica which I haven't upgraded to 7.3 yet. So I can compare >>> the two >>> > systems to isolate the problem. >>> > >>> >>> I'm afraid that without more info(messages/journal) nobody will be able >>> to help. >>> >>> But based on the description it seems that it didn't even get to step >>> where IPA is started. >>> >>> -- >>> Petr Vobornik >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Feb 22 06:29:58 2017 From: dkupka at redhat.com (David Kupka) Date: Wed, 22 Feb 2017 07:29:58 +0100 Subject: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA In-Reply-To: <063A1ABE401EB14FABF212F5328F5CE993C60E92@se-ex024.groupinfra.com> References: <063A1ABE401EB14FABF212F5328F5CE993C60E92@se-ex024.groupinfra.com> Message-ID: <20170222062957.GA4336@dkupka.usersys.redhat.com> On Tue, Feb 21, 2017 at 10:27:40AM +0000, Paris, Dan wrote: > Hi FreeIPA-users, > > My colleague Nick Piper emailed previously regarding the subject matter. > > We are still attempting to find a solution that meets our requirements and are considering manually building an ldif file to import into our master IdM server. In the reply to our original query Alexander Bokovoy mentioned: "In short, there is no support for IPA-IPA trust or replication. There are many reasons for that, including some complex technical issues on how this could be reliably working." Would you be able to provide some detail around these technical issues and provide some guidance as to if exporting an ldif file would meet our needs? > > Thanks in advance, > Dan > > Dan Paris | Leading Engineer > 250 Brook Drive, Reading, RG2 6UA | United Kingdom > M: +44 7920783573 > dan.paris at cgi.com | www.cgi.com > Registered in England & Wales (registered number 947968) > Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United Kingdom > -- > 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 Hi Dan! The biggest missing part on the way to FreeIPA-FreeIPA trust is the Global Catalog [1]. There might be (and probably are) other parts that FreeIPA lacks but I don't know the details. Regarding using ldif for synchronization. I don't think that's good idea for several reasons: 1) It will be hard and error prone to keep the data in sync. Even in case you would claim that corporate FreeIPA is authoritative source and all changes made in project FreeIPA will be lost you would need to periodically export, optionally compare and replace potentionally huge number of entries (users, groups, sudo rules, HBAC rules, ...). 2) To be able to obtain Kerberos ticket for user you would need to copy also Kerberos master key which is used to encrypt keys for users. This is quite sensitive material. By the way have you considered having just single FreeIPA deployment as I proposed in [2]? Why is separate deployment of FreeIPA for the project required? [1] https://technet.microsoft.com/en-us/library/cc730749(v=ws.11).aspx [2] https://www.redhat.com/archives/freeipa-users/2017-February/msg00136.html -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Feb 22 06:49:47 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 22 Feb 2017 07:49:47 +0100 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: Message-ID: <5981875f-6f06-cd8e-0b1d-bca1070bd9a6@redhat.com> On 02/21/2017 09:10 PM, Hanoz Elavia wrote: > Hello, > > I've got the FreeIPA server with AD trust (Server 2008 R2) setup and > running. I can login successfully on linux clients using AD credentials. > I'm now trying to setup my Isilon storage appliance with mixed mode file > sharing. > > The filer has joined the AD so it provides Windows users access to the > files. However, being a legacy client, it uses simple bind to query ldap > for uid and gid. I was able to setup FreeIPA as the ldap server but it > doesn't seem to return the uid and gid for AD objects. > > The query my storage is using is as follows: > > ldapsearch -x -W -z 10 -H ldap://ipa.server.com > -b 'cn=compat,dc=ipa,dc=server,dc=com' -D > 'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' > '(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=nisNetgroup)(objectClass=person))' > > The following command will obtain all the IDs for the native FreeIPA > users / groups but don't return any results for AD users. Is there a way > to get this done? I can't install any clients on the Isilon as it uses a > BSD based proprietary software. I can manually map FreeIPA assigned uids > / gids but that's tedious and error prone. Any help would be appreciated. > > Regards, > > H. > > Hi Hanoz, please bear in mind that in AD trust scenario the AD users are *not* stored on IPA server so you have to query AD DC directly for AD user attributes. -- Martin^3 Babinsky From abokovoy at redhat.com Wed Feb 22 07:28:52 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Feb 2017 09:28:52 +0200 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: Message-ID: <20170222072852.u3r5zusplcxvtiow@redhat.com> On ti, 21 helmi 2017, Hanoz Elavia wrote: >Hello, > >I've got the FreeIPA server with AD trust (Server 2008 R2) setup and >running. I can login successfully on linux clients using AD credentials. >I'm now trying to setup my Isilon storage appliance with mixed mode file >sharing. > >The filer has joined the AD so it provides Windows users access to the >files. However, being a legacy client, it uses simple bind to query ldap >for uid and gid. I was able to setup FreeIPA as the ldap server but it >doesn't seem to return the uid and gid for AD objects. > >The query my storage is using is as follows: > >ldapsearch -x -W -z 10 -H ldap://ipa.server.com -b >'cn=compat,dc=ipa,dc=server,dc=com' -D >'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' >'(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=nisNetgroup)(objectClass=person))' > >The following command will obtain all the IDs for the native FreeIPA users >/ groups but don't return any results for AD users. Is there a way to get >this done? I can't install any clients on the Isilon as it uses a BSD based >proprietary software. I can manually map FreeIPA assigned uids / gids but >that's tedious and error prone. Any help would be appreciated. There is none. Compat tree is built with RFC2307 queries in mind. RFC2307 clients issue a request with a specific user or group name and that triggers lookup of AD user/group through SSSD and insertion into the compat tree. A part of the trigger is how LDAP filter is built (see RFC for those). If your software does not use the same filter, you wouldn't get a response. -- / Alexander Bokovoy From freeipa at 0xc0dedbad.com Wed Feb 22 07:48:20 2017 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Wed, 22 Feb 2017 18:48:20 +1100 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! In-Reply-To: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> References: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> Message-ID: <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> Okay, with much debugging and hoop-jumping, I can say that certmonger on Debian/Ubuntu is currently in a rather broken state, at least in a server role. It links against libcurl3-nss, however on Debian/-derivs there is no build of nss-pem, so anything built against libcurl3-nss cannot parse PEM formatted certs. This results in a failure to process the IPA CA from the filesystem, causing the certmonger agent to fail verification of the server cert, producing the curl 'Error 77 connecting to: Problem with the SSL CA cert (path? access rights?)' return, which makes it impossible to renew certificates, and resulted in wedging my deployment as described. Does the FreeIPA issue tracker accept distro-specific reports, or is there somewhere more appropriate I should be sending this? As it stands, operating a CA on Debian/Ubuntu will break in painful and unexpected fashion, and should be avoided. On 21/02/17 23:36, Peter Fern wrote: > I don't know why the certs did not auto-renew originally, but now I am > very stuck trying to get my CA functional again. I've tried setting the > clock back to a week or two before the certs were due to expire, but I'm > still having no luck getting the CA functional. > > This is a Ubuntu server, so some paths are different to what may be > found on RPM-based distros. Any urgent help would be greatly > appreciated - I've been bashing against this for a couple of hours now > with no luck, and the hour is getting late. > > Below is my current (anonymized) `getcert list` of the problem certs, > where you will see my current ca-error: > > Request ID '20160616123036': > status: CA_UNREACHABLE > ca-error: Error 77 connecting to > https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem > with the SSL CA cert (path? access rights?). > stuck: no > key pair storage: > type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=IPA RA,O=EXAMPLE.COM > expires: 2017-02-11 05:52:26 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre > post-save command: /usr/lib/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20160616123427': > status: CA_UNREACHABLE > ca-error: Error 77 connecting to > https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem > with the SSL CA cert (path? access rights?). > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Audit,O=EXAMPLE.COM > expires: 2017-02-11 05:52:03 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/lib/ipa/certmonger/stop_pkicad > post-save command: /usr/lib/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20160616123428': > status: CA_UNREACHABLE > ca-error: Error 77 connecting to > https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem > with the SSL CA cert (path? access rights?). > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=OCSP Subsystem,O=EXAMPLE.COM > expires: 2017-02-11 05:52:01 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > eku: id-kp-OCSPSigning > pre-save command: /usr/lib/ipa/certmonger/stop_pkicad > post-save command: /usr/lib/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20160616123429': > status: CA_UNREACHABLE > ca-error: Error 77 connecting to > https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem > with the SSL CA cert (path? access rights?). > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Subsystem,O=EXAMPLE.COM > expires: 2017-02-11 05:52:01 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib/ipa/certmonger/stop_pkicad > post-save command: /usr/lib/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > > > All I get in the logs (with debug enabled) is: > > Jan 20 06:52:52 ipaserver.example.com > dogtag-ipa-ca-renew-agent-submit[2121]: Forwarding request to > dogtag-ipa-renew-agent > Jan 20 06:52:52 ipaserver.example.com > dogtag-ipa-renew-agent-submit[2307]: GET > https://ipaserver.example.com:8443/ca/agent/ca/profileReview?requestId=69960009&xml=true > Jan 20 06:52:52 ipaserver.example.com > dogtag-ipa-renew-agent-submit[2307]: (null) > Jan 20 06:52:52 ipaserver.example.com > dogtag-ipa-ca-renew-agent-submit[2121]: dogtag-ipa-renew-agent returned 3 > Jan 20 06:52:52 ipaserver.example.com certmonger[2016]: 2017-01-20 > 06:52:52 [2016] Error 77 connecting to > https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem > with the SSL CA cert (path? access rights?). > From flo at redhat.com Wed Feb 22 08:05:38 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 22 Feb 2017 09:05:38 +0100 Subject: [Freeipa-users] FreeIPA Help In-Reply-To: References: <0F1CBE17-4E56-4D31-8BCE-DDCDB5086DB8@redhat.com> Message-ID: On 02/22/2017 04:41 AM, Daniel Schimpfoessl wrote: > Is there a way for me to export my data (users, groups, ...), rebuild > the server and import the data again? > > Daniel > Hi Daniel, please keep the mailing list in CC as the content may also benefit other users with similar issues. Does anyone have suggestions in order to fix the broken CA? Thanks, Flo > 2017-02-09 12:33 GMT-06:00 Florence Renaud >: > > Hi Daniel, > > You can try to contact the mailing list for Dogtag (the certificate > system): pki-users at redhat.com > > If possible, state which certificates were renewed (the CA cert, or > the one used by Dogtag server/http server/ldap server), and how > (automatically by certmonger when approaching the expiration or > manually, then provide the command used). > > A customer recently hit an issue when renewing the CA cert, where > the subject name in the renewed cert was encoded differently and > thus not recognised as the same identity even though using the same > private key. > https://fedorahosted.org/pki/ticket/2587 > > > Flo. > > > > Envoy? de mon iPad > Le 8 f?vr. 2017 ? 19:48, Daniel Schimpfoessl > > a ?crit : > >> Flo, >> >> can you help me understand how to best get further help? >> https://www.redhat.com/archives/freeipa-users/2017-January/msg00422.html >> >> >> Thanks, >> >> Daniel > > From keesb at ghs.com Wed Feb 22 10:23:17 2017 From: keesb at ghs.com (Kees Bakker) Date: Wed, 22 Feb 2017 11:23:17 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> Message-ID: <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> On 21-02-17 19:49, Brendan Kearney wrote: > On 02/21/2017 10:57 AM, Kees Bakker wrote: >> Hey, >> >> Maybe one of the NFS users on this list could give me a hint what >> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >> >> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >> guessing that setting up Kerberos principal was done correctly. >> >> However, only root can actually access the mounted contents. Any other user >> only sees question marks as shown below. >> >> The mount command is simple. >> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >> >> On the server side /etc/exports looks like this. >> /home *(rw,sync,sec=krb5i,no_subtree_check) >> >> $ sudo mount |grep nfs >> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >> >> $ sudo ls -ld /nfshome >> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >> $ sudo ls -l /nfshome >> total 0 >> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >> >> $ ls -l /nfshome >> ls: cannot access '/nfshome': Permission denied >> $ ls -l / | grep nfshome >> ls: cannot access '/nfshome': Permission denied >> d????????? ? ? ? ? ? nfshome >> > sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb at client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: keesb at EXAMPLE.COM Valid starting Expires Service principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) Furthermore, I'm guessing that the host principle which I got after ipa-client-install is good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I did not do.) # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ -- Kees From ente.trompete at protonmail.com Wed Feb 22 10:45:36 2017 From: ente.trompete at protonmail.com (Ente Trompete) Date: Wed, 22 Feb 2017 05:45:36 -0500 Subject: [Freeipa-users] FreeIPA Fedora 25 and IPA CentOS 7.3 Message-ID: Hi, I have currently running one IdM Server (package version 4.4.0-14) on CentOS 7.3 (x86_64). The first which I must ask is: which FreeIPA Version is basis of this version because on https://www.freeipa.org/page/Main_Page under News only v4.4.1 ? v.4.4.3 are listed. The next question which I have is: can I install a Fedora 25 and use the included FreeIPA v4.4.1-3 to create a replica of the existing 4.4.0-14? My problem is that I will use an ARM32 computer as replica and Centos 7.3 runs properly on it but the repositories includes only ipa-client packages. No ipa-server* package (BTW also for ARM64 is only ipa-server-common available). But in the repositories of Fedora 25 ARM32 I can found all. TIA, Silvio Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 22 10:59:45 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Feb 2017 12:59:45 +0200 Subject: [Freeipa-users] FreeIPA Fedora 25 and IPA CentOS 7.3 In-Reply-To: References: Message-ID: <20170222105945.kpue4rdllzcjtjlp@redhat.com> On ke, 22 helmi 2017, Ente Trompete wrote: >Hi, > > >I have currently running one IdM Server (package version 4.4.0-14) on >CentOS 7.3 (x86_64). The first which I must ask is: which FreeIPA >Version is basis of this version because on >https://www.freeipa.org/page/Main_Page under News only v4.4.1 ? v.4.4.3 >are listed. Read this: https://www.redhat.com/archives/freeipa-users/2016-February/msg00429.html I hope it will help you in understanding how package versions in RHEL and CentOS related to upstream FreeIPA versions. > > >The next question which I have is: can I install a Fedora 25 and use >the included FreeIPA v4.4.1-3 to create a replica of the existing >4.4.0-14? My problem is that I will use an ARM32 computer as replica >and Centos 7.3 runs properly on it but the repositories includes only >ipa-client packages. No ipa-server* package (BTW also for ARM64 is only >ipa-server-common available). But in the repositories of Fedora 25 >ARM32 I can found all. Packages in Fedora are 'freeipa-*', packages in RHEL/CentOS are 'ipa-*'. CentOS uses whatever corresponding RHEL version provides. I don't think RHEL has ARM build for ipa-server packages. I think RHEL officially supports ipa-server only on x86-64. -- / Alexander Bokovoy From wouter.hummelink at kpn.com Wed Feb 22 12:03:58 2017 From: wouter.hummelink at kpn.com (wouter.hummelink at kpn.com) Date: Wed, 22 Feb 2017 12:03:58 +0000 Subject: [Freeipa-users] Katello IPA auth and Cross realm trust. Message-ID: <2CA71D6C07ADB544847562573DC6BF062B2E2402@CPEMS-KPN309.KPNCNL.LOCAL> Hello all, I'm trying to get IPA auth on Katello to work properly, however the infopipe is unable to access the right information without additional configuration. With these changes I got the infopipe to work, but then user logins started to fail due to invalid user errors. I've added the following to the domain/xxx section on the katello server [domain/XXX] ldap_user_extra_attrs=email:mail, lastname:sn, firstname:givenname [ifp] allowed_uids=apache, root user_attributes=+email, +firstname, +lastname And on the ipa server: [nss] user_attributes=+mail, +sn, +givenname [domain/XXX] ldap_user_extra_attrs=mail, sn, givenname However, the suggested change on the IPA server (from the satellite installation guide) results in user lookup failures on client systems (not exclusive to the katello host) # id user at TRUSTED.DOMAIN id: user at TRUSTED.DOMAIN: no such user SSSD logs do reveal a hint about whats going on: [filtered for brevity, modified for privacy] (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(krbPrincipalName=user at TRUSTED.DOMAIN)(mail=user at TRUSTED.DOMAIN)(krbPrincipalName=user\\@TRUSTED.DOMAIN at IPA.DOMAIN))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=linux,dc=infra,dc=local]. (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [mail] (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [is_email_from_domain] (0x4000): Email [sander.lambrechts at kpn.com] is not from domain [TRUSTED.DOMAIN]. (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [is_email_from_domain] (0x4000): Email [sander.lambrechts at kpn.com] is not from domain [TRUSTED.DOMAIN]. (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [Attribute or value exists](20)[attribute 'mail': value #1 on 'name=user at TRUSTED.DOMAIN,cn=users,cn=TRUSTED.DOMAIN,cn=sysdb' provided more than once] (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [Attribute or value exists](20)[attribute 'mail': value #1 on 'name=user at TRUSTED.DOMAIN,cn=users,cn=TRUSTED.DOMAIN,cn=sysdb' provided more than once] Am I running into a bug or have I misconfigured this somewhere? Met vriendelijke groet, Wouter Hummelink Technical Consultant - Enterprise Webhosting T: +31-6-12882447 E: wouter.hummelink at kpn.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjuhasz at chemaxon.com Wed Feb 22 12:13:29 2017 From: sjuhasz at chemaxon.com (Sandor Juhasz) Date: Wed, 22 Feb 2017 13:13:29 +0100 (CET) Subject: [Freeipa-users] How to check if ldap was updated? Message-ID: <1462251152.774273.1487765609495.JavaMail.zimbra@chemaxon.com> Hi, i would like to know if there is any endpoint, command, plugin, api or other way to check if ldap was modified. I would like to trigger jobs, if user/group attributes are updated and polling ldap continuously is not he best way i guess. S?ndor Juh?sz System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Feb 22 12:55:14 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 22 Feb 2017 13:55:14 +0100 Subject: [Freeipa-users] How to check if ldap was updated? In-Reply-To: <1462251152.774273.1487765609495.JavaMail.zimbra@chemaxon.com> References: <1462251152.774273.1487765609495.JavaMail.zimbra@chemaxon.com> Message-ID: <9a0549c5-0db5-e07c-4a33-29c879e2f99f@redhat.com> On 22.02.2017 13:13, Sandor Juhasz wrote: > Hi, > > i would like to know if there is any endpoint, command, plugin, api or > other way to check if ldap was modified. > I would like to trigger jobs, if user/group attributes are updated and > polling ldap continuously is not he best > way i guess. > > *S?ndor Juh?sz* > System Administrator > *ChemAxon**Ltd*. > Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 > Cell: +36704258964 > > Hello, * *we don't have any command/api to detect if LDAP was changed. for this you can use syncrepl or persistent ldapsearch attached to users/groups subtree. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Feb 22 12:57:58 2017 From: sbose at redhat.com (Sumit Bose) Date: Wed, 22 Feb 2017 13:57:58 +0100 Subject: [Freeipa-users] Katello IPA auth and Cross realm trust. In-Reply-To: <2CA71D6C07ADB544847562573DC6BF062B2E2402@CPEMS-KPN309.KPNCNL.LOCAL> References: <2CA71D6C07ADB544847562573DC6BF062B2E2402@CPEMS-KPN309.KPNCNL.LOCAL> Message-ID: <20170222125758.GC3404@p.Speedport_W_724V_Typ_A_05011603_00_011> On Wed, Feb 22, 2017 at 12:03:58PM +0000, wouter.hummelink at kpn.com wrote: > Hello all, > > I'm trying to get IPA auth on Katello to work properly, however the infopipe is unable to access the right information without additional configuration. > With these changes I got the infopipe to work, but then user logins started to fail due to invalid user errors. > > I've added the following to the domain/xxx section on the katello server > > [domain/XXX] > ldap_user_extra_attrs=email:mail, lastname:sn, firstname:givenname Current version of SSSD already read the email attribute from the server (check ldap_user_email in man sssd-ldap). So you can either remove email from your ldap_user_extra_attrs or set 'ldap_user_email = noSuchAttr' to avoid the collision. HTH bye, Sumit > > [ifp] > > allowed_uids=apache, root > user_attributes=+email, +firstname, +lastname > > > And on the ipa server: > [nss] > user_attributes=+mail, +sn, +givenname > > [domain/XXX] > ldap_user_extra_attrs=mail, sn, givenname > > However, the suggested change on the IPA server (from the satellite installation guide) results in user lookup failures on client systems (not exclusive to the katello host) > > # id user at TRUSTED.DOMAIN > id: user at TRUSTED.DOMAIN: no such user > > SSSD logs do reveal a hint about whats going on: > [filtered for brevity, modified for privacy] > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(krbPrincipalName=user at TRUSTED.DOMAIN)(mail=user at TRUSTED.DOMAIN)(krbPrincipalName=user\\@TRUSTED.DOMAIN at IPA.DOMAIN))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=linux,dc=infra,dc=local]. > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [mail] > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [is_email_from_domain] (0x4000): Email [sander.lambrechts at kpn.com] is not from domain [TRUSTED.DOMAIN]. > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [is_email_from_domain] (0x4000): Email [sander.lambrechts at kpn.com] is not from domain [TRUSTED.DOMAIN]. > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [Attribute or value exists](20)[attribute 'mail': value #1 on 'name=user at TRUSTED.DOMAIN,cn=users,cn=TRUSTED.DOMAIN,cn=sysdb' provided more than once] > (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [Attribute or value exists](20)[attribute 'mail': value #1 on 'name=user at TRUSTED.DOMAIN,cn=users,cn=TRUSTED.DOMAIN,cn=sysdb' provided more than once] > > Am I running into a bug or have I misconfigured this somewhere? > > Met vriendelijke groet, > Wouter Hummelink > Technical Consultant - Enterprise Webhosting > T: +31-6-12882447 > E: wouter.hummelink at kpn.com > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From bpk678 at gmail.com Wed Feb 22 13:05:14 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Wed, 22 Feb 2017 08:05:14 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> Message-ID: On 02/22/2017 05:23 AM, Kees Bakker wrote: > On 21-02-17 19:49, Brendan Kearney wrote: >> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>> Hey, >>> >>> Maybe one of the NFS users on this list could give me a hint what >>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>> >>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>> guessing that setting up Kerberos principal was done correctly. >>> >>> However, only root can actually access the mounted contents. Any other user >>> only sees question marks as shown below. >>> >>> The mount command is simple. >>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>> >>> On the server side /etc/exports looks like this. >>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>> >>> $ sudo mount |grep nfs >>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>> >>> $ sudo ls -ld /nfshome >>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>> $ sudo ls -l /nfshome >>> total 0 >>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>> >>> $ ls -l /nfshome >>> ls: cannot access '/nfshome': Permission denied >>> $ ls -l / | grep nfshome >>> ls: cannot access '/nfshome': Permission denied >>> d????????? ? ? ? ? ? nfshome >>> >> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) > Thanks for the reply. > > In this case the user _is_ authenticated. > keesb at client1:~$ klist > Ticket cache: KEYRING:persistent:60001:60001 > Default principal: keesb at EXAMPLE.COM > > Valid starting Expires Service principal > 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. > > What other grants could be needed? HBAC Rules? > > Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it > doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. then the user should be able to pull the ticket for auth. > > Furthermore, I'm guessing that the host principle which I got after ipa-client-install is > good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I > did not do.) > # klist -ke > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- -------------------------------------------------------------------------- > 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) > 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) > > [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA > [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ http://www.itp.uzh.ch/~dpotter/howto/kerberos From igor.leao at ubee.in Tue Feb 21 17:55:41 2017 From: igor.leao at ubee.in (=?UTF-8?Q?Igor_Le=C3=A3o?=) Date: Tue, 21 Feb 2017 14:55:41 -0300 Subject: [Freeipa-users] Client for CoreOS In-Reply-To: <20170220162233.GB27985@10.4.128.1> References: <20170220162233.GB27985@10.4.128.1> Message-ID: Thanks, Lukas. Hope it works. 2017-02-20 13:22 GMT-03:00 Lukas Slebodnik : > On (20/02/17 12:44), Igor Le?o wrote: > >Is it possible to run a FreeIPA client on CoreOS? > >The OS misses some libraries and I didn't succeeded installing them. > > > >Has anyone faced this scenario? > > > You need to run everything in container even installer. > > You might inspire in docker version of container. > https://hub.docker.com/r/fedora/sssd/ > > I am not sure whether it's possible to run with rocket. > > LS > -- Igor Le?o Site Reliability Engineer Mobile: +55 81 99727-1083 Skype: *igorvpcleao* Office: +55 81 4042-9757 Website: inlocomedia.com [image: inlocomedia] [image: LinkedIn] [image: Facebook] [image: Twitter] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Wed Feb 22 14:32:59 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 22 Feb 2017 08:32:59 -0600 (CST) Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <20170222072852.u3r5zusplcxvtiow@redhat.com> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> Message-ID: <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> > There is none. Compat tree is built with RFC2307 queries in mind. > RFC2307 clients issue a request with a specific user or group name and > that triggers lookup of AD user/group through SSSD and insertion into > the compat tree. A part of the trigger is how LDAP filter is built (see > RFC for those). If your software does not use the same filter, you > wouldn't get a response. Are you saying that there is an LDAP query you can use to retrieve the UID/GID of a user/group that is known via an AD trust as long as the filter is correct? I ran into this same situation (with a storage appliance) and thought that the problem was that the UIDs/GIDs were calculated but never stored, but I hadn't stopped to think about how whether sssd (on the local machine) retrieves them from FreeIPA or does the calculation. From abokovoy at redhat.com Wed Feb 22 14:50:55 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Feb 2017 16:50:55 +0200 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> Message-ID: <20170222145055.vwovjrnvjaxkpwkh@redhat.com> On ke, 22 helmi 2017, Jason B. Nance wrote: >> There is none. Compat tree is built with RFC2307 queries in mind. >> RFC2307 clients issue a request with a specific user or group name and >> that triggers lookup of AD user/group through SSSD and insertion into >> the compat tree. A part of the trigger is how LDAP filter is built (see >> RFC for those). If your software does not use the same filter, you >> wouldn't get a response. > >Are you saying that there is an LDAP query you can use to retrieve the >UID/GID of a user/group that is known via an AD trust as long as the >filter is correct? I ran into this same situation (with a storage >appliance) and thought that the problem was that the UIDs/GIDs were >calculated but never stored, but I hadn't stopped to think about how >whether sssd (on the local machine) retrieves them from FreeIPA or does >the calculation. Read https://pagure.io/slapi-nis/blob/master/f/doc/ipa/sch-ipa.txt -- / Alexander Bokovoy From h.elavia at atomiccartoons.com Wed Feb 22 15:05:22 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 07:05:22 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <20170222145055.vwovjrnvjaxkpwkh@redhat.com> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> Message-ID: Thanks guys, I think there might be a way to modify the LDAP query. I'm speaking to the EMC / Dell support personnel today to see what can be done. Regards, Hanoz *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Wed, Feb 22, 2017 at 6:50 AM, Alexander Bokovoy wrote: > On ke, 22 helmi 2017, Jason B. Nance wrote: > >> There is none. Compat tree is built with RFC2307 queries in mind. >>> RFC2307 clients issue a request with a specific user or group name and >>> that triggers lookup of AD user/group through SSSD and insertion into >>> the compat tree. A part of the trigger is how LDAP filter is built (see >>> RFC for those). If your software does not use the same filter, you >>> wouldn't get a response. >>> >> >> Are you saying that there is an LDAP query you can use to retrieve the >> UID/GID of a user/group that is known via an AD trust as long as the >> filter is correct? I ran into this same situation (with a storage >> appliance) and thought that the problem was that the UIDs/GIDs were >> calculated but never stored, but I hadn't stopped to think about how >> whether sssd (on the local machine) retrieves them from FreeIPA or does >> the calculation. >> > Read https://pagure.io/slapi-nis/blob/master/f/doc/ipa/sch-ipa.txt > > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Wed Feb 22 15:11:37 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 07:11:37 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> Message-ID: Hey Alex, Thanks for the link, isn't RFC 2307 implemented as Services for Unix in Windows 2008 R2? Apologies for not mentioning this earlier but I haven't enabled that mainly because SSSD now maps the IDs. Also, in the newer version of the Windows Server, SFU seems to have been discontinued. Since there is a possibility of us having to upgrade in the future, I tried to keep SFU out of the picture. Please let me know your thoughts. Here's some additional info regarding the environment: Windows ADs: Windows Server 2008 R2 FreeIPA Server: CentOS 7.2 x86_64 FreeIPA Server Version: 4.4.0.14 FreeIPA Client Version: 4.4.0.14 SSSD Version: 1.14.0-43 Thanks, Hanoz *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Wed, Feb 22, 2017 at 7:05 AM, Hanoz Elavia wrote: > Thanks guys, > > I think there might be a way to modify the LDAP query. I'm speaking to the > EMC / Dell support personnel today to see what can be done. > > Regards, > > Hanoz > > > *Hanoz Elavia |* IT Manager > *O:* 604-734-2866 *|* *www.atomiccartoons.com > * > 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 > > On Wed, Feb 22, 2017 at 6:50 AM, Alexander Bokovoy > wrote: > >> On ke, 22 helmi 2017, Jason B. Nance wrote: >> >>> There is none. Compat tree is built with RFC2307 queries in mind. >>>> RFC2307 clients issue a request with a specific user or group name and >>>> that triggers lookup of AD user/group through SSSD and insertion into >>>> the compat tree. A part of the trigger is how LDAP filter is built (see >>>> RFC for those). If your software does not use the same filter, you >>>> wouldn't get a response. >>>> >>> >>> Are you saying that there is an LDAP query you can use to retrieve the >>> UID/GID of a user/group that is known via an AD trust as long as the >>> filter is correct? I ran into this same situation (with a storage >>> appliance) and thought that the problem was that the UIDs/GIDs were >>> calculated but never stored, but I hadn't stopped to think about how >>> whether sssd (on the local machine) retrieves them from FreeIPA or does >>> the calculation. >>> >> Read https://pagure.io/slapi-nis/blob/master/f/doc/ipa/sch-ipa.txt >> >> >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 22 15:22:44 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Feb 2017 17:22:44 +0200 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> Message-ID: <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> On ke, 22 helmi 2017, Hanoz Elavia wrote: >Hey Alex, > >Thanks for the link, isn't RFC 2307 implemented as Services for Unix in >Windows 2008 R2? Apologies for not mentioning this earlier but I haven't >enabled that mainly because SSSD now maps the IDs. Also, in the newer >version of the Windows Server, SFU seems to have been discontinued. I think you are confused by the names. What Compat tree provides is an interface on IPA side to look up identities of AD users and groups over LDAP. Compat tree will do lookup through SSSD on your behalf. This means we don't depend on how Windows side provides or does not provide attributes. Everything SSSD can resolve, can be returned, be it stored in AD LDAP, generated by SSSD, or stored in ID overrides in IPA. But the query format is the one described in RFC 2307 because this is what all nss implementations like nss_ldap or similar ones use in UNIX-like environments. Windows Server is merely implementing the same LDAP schema to allow interoperability with the same clients. Think of Compat Tree in IPA as doing the same, just dynamically. -- / Alexander Bokovoy From keesb at ghs.com Wed Feb 22 15:26:56 2017 From: keesb at ghs.com (Kees Bakker) Date: Wed, 22 Feb 2017 16:26:56 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> Message-ID: On 22-02-17 14:05, Brendan Kearney wrote: > On 02/22/2017 05:23 AM, Kees Bakker wrote: >> On 21-02-17 19:49, Brendan Kearney wrote: >>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>> Hey, >>>> >>>> Maybe one of the NFS users on this list could give me a hint what >>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>> >>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>> guessing that setting up Kerberos principal was done correctly. >>>> >>>> However, only root can actually access the mounted contents. Any other user >>>> only sees question marks as shown below. >>>> >>>> The mount command is simple. >>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>> >>>> On the server side /etc/exports looks like this. >>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>> >>>> $ sudo mount |grep nfs >>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>> >>>> $ sudo ls -ld /nfshome >>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>> $ sudo ls -l /nfshome >>>> total 0 >>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>> >>>> $ ls -l /nfshome >>>> ls: cannot access '/nfshome': Permission denied >>>> $ ls -l / | grep nfshome >>>> ls: cannot access '/nfshome': Permission denied >>>> d????????? ? ? ? ? ? nfshome >>>> >>> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) >> Thanks for the reply. >> >> In this case the user _is_ authenticated. >> keesb at client1:~$ klist >> Ticket cache: KEYRING:persistent:60001:60001 >> Default principal: keesb at EXAMPLE.COM >> >> Valid starting Expires Service principal >> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM > no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >> >> What other grants could be needed? HBAC Rules? >> >> Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it >> doesn't help to get access for the user.) > there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root at srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) 1 host/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) Is this what you mean? > then the user should be able to pull the ticket for auth. Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? keesb at client1$ kinit nfs/srv1.example.com at EXAMPLE.COM Password for nfs/srv1.example.com at EXAMPLE.COM: But I don't have a password for that. Hmm. >> >> Furthermore, I'm guessing that the host principle which I got after ipa-client-install is >> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I >> did not do.) >> # klist -ke >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- -------------------------------------------------------------------------- >> 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >> 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >> >> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ > > http://www.itp.uzh.ch/~dpotter/howto/kerberos > From h.elavia at atomiccartoons.com Wed Feb 22 16:25:52 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 08:25:52 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> Message-ID: Thanks Alex, Does it also means that I'll have to install the FreeIPA server with --enable-compat ? I didn't do that. Regards, Hanoz *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Wed, Feb 22, 2017 at 7:22 AM, Alexander Bokovoy wrote: > On ke, 22 helmi 2017, Hanoz Elavia wrote: > >> Hey Alex, >> >> Thanks for the link, isn't RFC 2307 implemented as Services for Unix in >> Windows 2008 R2? Apologies for not mentioning this earlier but I haven't >> enabled that mainly because SSSD now maps the IDs. Also, in the newer >> version of the Windows Server, SFU seems to have been discontinued. >> > I think you are confused by the names. What Compat tree provides is an > interface on IPA side to look up identities of AD users and groups over > LDAP. Compat tree will do lookup through SSSD on your behalf. This means > we don't depend on how Windows side provides or does not provide > attributes. > Everything SSSD can resolve, can be returned, be it stored in AD LDAP, > generated by SSSD, or stored in ID overrides in IPA. > > But the query format is the one described in RFC 2307 because this is > what all nss implementations like nss_ldap or similar ones use in > UNIX-like environments. Windows Server is merely implementing the same > LDAP schema to allow interoperability with the same clients. Think of > Compat Tree in IPA as doing the same, just dynamically. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Wed Feb 22 16:33:40 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Wed, 22 Feb 2017 11:33:40 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> Message-ID: <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> On 02/22/2017 10:26 AM, Kees Bakker wrote: > On 22-02-17 14:05, Brendan Kearney wrote: >> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>> On 21-02-17 19:49, Brendan Kearney wrote: >>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>> Hey, >>>>> >>>>> Maybe one of the NFS users on this list could give me a hint what >>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>> >>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>> guessing that setting up Kerberos principal was done correctly. >>>>> >>>>> However, only root can actually access the mounted contents. Any other user >>>>> only sees question marks as shown below. >>>>> >>>>> The mount command is simple. >>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>> >>>>> On the server side /etc/exports looks like this. >>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>> >>>>> $ sudo mount |grep nfs >>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>> >>>>> $ sudo ls -ld /nfshome >>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>> $ sudo ls -l /nfshome >>>>> total 0 >>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>> >>>>> $ ls -l /nfshome >>>>> ls: cannot access '/nfshome': Permission denied >>>>> $ ls -l / | grep nfshome >>>>> ls: cannot access '/nfshome': Permission denied >>>>> d????????? ? ? ? ? ? nfshome >>>>> >>>> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) >>> Thanks for the reply. >>> >>> In this case the user _is_ authenticated. >>> keesb at client1:~$ klist >>> Ticket cache: KEYRING:persistent:60001:60001 >>> Default principal: keesb at EXAMPLE.COM >>> >>> Valid starting Expires Service principal >>> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM >> no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. > (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) > >>> What other grants could be needed? HBAC Rules? >>> >>> Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it >>> doesn't help to get access for the user.) >> there are principals to create and keytabs to be updated on hte NFS sever, if not done already. > I did create a principal for the NFS server (using ipa service-add) and > add to the keytab on the NFS server (using ipa-getkeytab) ... > root at srv1# klist -ke > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- -------------------------------------------------------------------------- > 1 host/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) > 1 host/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) > 1 nfs/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) > 1 nfs/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) > > Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? > >> then the user should be able to pull the ticket for auth. > Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? > > keesb at client1$ kinit nfs/srv1.example.com at EXAMPLE.COM > Password for nfs/srv1.example.com at EXAMPLE.COM: > > But I don't have a password for that. Hmm. there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. > >>> Furthermore, I'm guessing that the host principle which I got after ipa-client-install is >>> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I >>> did not do.) >>> # klist -ke >>> Keytab name: FILE:/etc/krb5.keytab >>> KVNO Principal >>> ---- -------------------------------------------------------------------------- >>> 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>> 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>> >>> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ >> http://www.itp.uzh.ch/~dpotter/howto/kerberos >> From abokovoy at redhat.com Wed Feb 22 16:34:23 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Feb 2017 18:34:23 +0200 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> Message-ID: <20170222163423.h37n56eserowtxa6@redhat.com> On ke, 22 helmi 2017, Hanoz Elavia wrote: >Thanks Alex, > >Does it also means that I'll have to install the FreeIPA server with >--enable-compat ? I didn't do that. check ipa-compat-manage tool. > >Regards, > >Hanoz > > >*Hanoz Elavia |* IT Manager >*O:* 604-734-2866 *|* *www.atomiccartoons.com >* >112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 > >On Wed, Feb 22, 2017 at 7:22 AM, Alexander Bokovoy >wrote: > >> On ke, 22 helmi 2017, Hanoz Elavia wrote: >> >>> Hey Alex, >>> >>> Thanks for the link, isn't RFC 2307 implemented as Services for Unix in >>> Windows 2008 R2? Apologies for not mentioning this earlier but I haven't >>> enabled that mainly because SSSD now maps the IDs. Also, in the newer >>> version of the Windows Server, SFU seems to have been discontinued. >>> >> I think you are confused by the names. What Compat tree provides is an >> interface on IPA side to look up identities of AD users and groups over >> LDAP. Compat tree will do lookup through SSSD on your behalf. This means >> we don't depend on how Windows side provides or does not provide >> attributes. >> Everything SSSD can resolve, can be returned, be it stored in AD LDAP, >> generated by SSSD, or stored in ID overrides in IPA. >> >> But the query format is the one described in RFC 2307 because this is >> what all nss implementations like nss_ldap or similar ones use in >> UNIX-like environments. Windows Server is merely implementing the same >> LDAP schema to allow interoperability with the same clients. Think of >> Compat Tree in IPA as doing the same, just dynamically. >> >> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From Steven.Auerbach at flbog.edu Wed Feb 22 16:38:50 2017 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Wed, 22 Feb 2017 16:38:50 +0000 Subject: [Freeipa-users] sudo NOPASSWD for a single command Message-ID: We have a script stored on a particular server in our realm that executes a number of non-privileged commands and are wanting to add /sbin/vgs command. The script uses SSH to then execute the same set of commands on all the servers in the realm. The owner of the script is in the administrator group and there are sudoer commands for the administrator group in general. We need to place a rule for this one command for either this group or the script owner to run NOPASSWD. Where and how would I specify that in the IPA admin console? Steven Auerbach Systems Administrator State University System of Florida Board of Governors 325 W. Gaines Street, Suite 1625 Tallahassee, Florida 32399 (850) 245-9592 Steven.auerbach at flbog.edu | www.flbog.edu [email_sig] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4102 bytes Desc: image001.jpg URL: From h.elavia at atomiccartoons.com Wed Feb 22 16:40:38 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 08:40:38 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <20170222163423.h37n56eserowtxa6@redhat.com> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> Message-ID: Hey Alex, Thanks, I ran ipa-compat-manage status and it shows Plugin enabled. I'll have a look at the link and see if we can change the query to obtain the info required. Regards, Hanoz *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Wed, Feb 22, 2017 at 8:34 AM, Alexander Bokovoy wrote: > On ke, 22 helmi 2017, Hanoz Elavia wrote: > >> Thanks Alex, >> >> Does it also means that I'll have to install the FreeIPA server with >> --enable-compat ? I didn't do that. >> > > check ipa-compat-manage tool. > > >> Regards, >> >> Hanoz >> >> >> *Hanoz Elavia |* IT Manager >> *O:* 604-734-2866 *|* *www.atomiccartoons.com >> * >> 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 >> >> On Wed, Feb 22, 2017 at 7:22 AM, Alexander Bokovoy >> wrote: >> >> On ke, 22 helmi 2017, Hanoz Elavia wrote: >>> >>> Hey Alex, >>>> >>>> Thanks for the link, isn't RFC 2307 implemented as Services for Unix in >>>> Windows 2008 R2? Apologies for not mentioning this earlier but I haven't >>>> enabled that mainly because SSSD now maps the IDs. Also, in the newer >>>> version of the Windows Server, SFU seems to have been discontinued. >>>> >>>> I think you are confused by the names. What Compat tree provides is an >>> interface on IPA side to look up identities of AD users and groups over >>> LDAP. Compat tree will do lookup through SSSD on your behalf. This means >>> we don't depend on how Windows side provides or does not provide >>> attributes. >>> Everything SSSD can resolve, can be returned, be it stored in AD LDAP, >>> generated by SSSD, or stored in ID overrides in IPA. >>> >>> But the query format is the one described in RFC 2307 because this is >>> what all nss implementations like nss_ldap or similar ones use in >>> UNIX-like environments. Windows Server is merely implementing the same >>> LDAP schema to allow interoperability with the same clients. Think of >>> Compat Tree in IPA as doing the same, just dynamically. >>> >>> >>> -- >>> / Alexander Bokovoy >>> >>> > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Wed Feb 22 16:58:35 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 22 Feb 2017 10:58:35 -0600 (CST) Subject: [Freeipa-users] sudo NOPASSWD for a single command In-Reply-To: References: Message-ID: <1351947637.1781.1487782715833.JavaMail.zimbra@tresgeek.net> > We have a script stored on a particular server in our realm that executes a > number of non-privileged commands and are wanting to add /sbin/vgs command. The > script uses SSH to then execute the same set of commands on all the servers in > the realm. > The owner of the script is in the administrator group and there are sudoer > commands for the administrator group in general. We need to place a rule for > this one command for either this group or the script owner to run NOPASSWD. > Where and how would I specify that in the IPA admin console? Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> Sudo -> Sudo Commands)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Feb 22 17:03:00 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 22 Feb 2017 18:03:00 +0100 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server In-Reply-To: References: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> Message-ID: <120e6725-3891-6bbd-5ae3-7ad187a872e2@stroeder.com> Iulian Roman wrote: > On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden > wrote: > > Iulian Roman wrote: > > Hello, > > > > Does anybody know if the rfc2307aix schema is supported in IPA server (i > > use red hat IDM version) ? If yes, is there any documentation available > > ? Was it tested ? > > No, it isn't supported (it's the first I've ever heard of it). Looking > at the schema I doubt it is something that would ever be fully supported. > > is there any possibility to extend the existing schema with additional > attributes/object Do you really use this specific AIX schema? If yes, which attributes for which purpose? Last time I've checked this schema when integrating AIX clients my conclusion was that this schema is rather useless and proprietary bloat. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From iulian.roman at gmail.com Wed Feb 22 17:27:32 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Wed, 22 Feb 2017 18:27:32 +0100 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server In-Reply-To: <120e6725-3891-6bbd-5ae3-7ad187a872e2@stroeder.com> References: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> <120e6725-3891-6bbd-5ae3-7ad187a872e2@stroeder.com> Message-ID: On Wed, Feb 22, 2017 at 6:03 PM, Michael Str?der wrote: > Iulian Roman wrote: > > On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden > > wrote: > > > > Iulian Roman wrote: > > > Hello, > > > > > > Does anybody know if the rfc2307aix schema is supported in IPA > server (i > > > use red hat IDM version) ? If yes, is there any documentation > available > > > ? Was it tested ? > > > > No, it isn't supported (it's the first I've ever heard of it). > Looking > > at the schema I doubt it is something that would ever be fully > supported. > > > > is there any possibility to extend the existing schema with additional > > attributes/object > > Do you really use this specific AIX schema? > If yes, which attributes for which purpose? > > I do need the aixAuxAccount and aixAuxGroup object classes . they implement some password restrictions needed for security/compliance + some other security related attributes. Personally i do not consider them a must - they are rather some nice to have features - but i have to migrate an environment which does use them. And i would like as well to make the migration as transparent as possible (therefore without "missing features"). > Last time I've checked this schema when integrating AIX clients my > conclusion was that > this schema is rather useless and proprietary bloat. > > Ciao, Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perq at me.com Wed Feb 22 17:35:43 2017 From: perq at me.com (Per Qvindesland) Date: Wed, 22 Feb 2017 17:35:43 +0000 Subject: [Freeipa-users] Debian client installation In-Reply-To: <4aa5e734-406e-a080-7d62-3f4433a0996e@ubuntu.com> References: <9650A9F7-BC3E-4FA8-B2EC-9A98FF249630@me.com> <4aa5e734-406e-a080-7d62-3f4433a0996e@ubuntu.com> Message-ID: <9D807AF0-6918-4AB4-9AE0-3CDCE330385F@me.com> Hi Thanks for the answer. Is there any workaround for this that anyone can suggest? Regards Per Sent from my Commodore 64 > On 18 Feb 2017, at 05:34, Timo Aaltonen wrote: > >> On 17.02.2017 17:37, Per Qvindesland wrote: >> Hi All >> >> I have installed free ipa client by using http://www.pakjiddat.pk/articles/all/installing-freeipa-client-on-debian which works, but I am unable to get the sudo to work, on debian 7.11 machines, sssd installed version is 1.9.6 which I think is pretty old. >> >> Does anyone have any suggestions on how to get sudo to work on debian 7? perhaps another more updated how to? > > you need sudo built with sssd support, which that repo is lacking. > > > -- > t From h.elavia at atomiccartoons.com Wed Feb 22 18:08:03 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 10:08:03 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> Message-ID: Hey Alexander, So based on the RFC 2307 documentation, I built a test server and ran the following command: ldapsearch -x -W -H 'ldap://ipa.server.com' -b 'cn=compat,dc=ipa,dc=server,dc=com' -D 'uid=admin,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' -s sub 'uid= ad_user at server.com' It worked as expected. Then once I rebooted the test server it stopped working. Any idea which service might be failing ? Regards, Hanoz On Wed, Feb 22, 2017 at 8:40 AM, Hanoz Elavia wrote: > Hey Alex, > > Thanks, I ran ipa-compat-manage status and it shows Plugin enabled. I'll > have a look at the link and see if we can change the query to obtain the > info required. > > Regards, > > Hanoz > > > *Hanoz Elavia |* IT Manager > *O:* 604-734-2866 *|* *www.atomiccartoons.com > * > 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 > > On Wed, Feb 22, 2017 at 8:34 AM, Alexander Bokovoy > wrote: > >> On ke, 22 helmi 2017, Hanoz Elavia wrote: >> >>> Thanks Alex, >>> >>> Does it also means that I'll have to install the FreeIPA server with >>> --enable-compat ? I didn't do that. >>> >> >> check ipa-compat-manage tool. >> >> >>> Regards, >>> >>> Hanoz >>> >>> >>> *Hanoz Elavia |* IT Manager >>> *O:* 604-734-2866 *|* *www.atomiccartoons.com >>> * >>> 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 >>> >>> On Wed, Feb 22, 2017 at 7:22 AM, Alexander Bokovoy >>> wrote: >>> >>> On ke, 22 helmi 2017, Hanoz Elavia wrote: >>>> >>>> Hey Alex, >>>>> >>>>> Thanks for the link, isn't RFC 2307 implemented as Services for Unix in >>>>> Windows 2008 R2? Apologies for not mentioning this earlier but I >>>>> haven't >>>>> enabled that mainly because SSSD now maps the IDs. Also, in the newer >>>>> version of the Windows Server, SFU seems to have been discontinued. >>>>> >>>>> I think you are confused by the names. What Compat tree provides is an >>>> interface on IPA side to look up identities of AD users and groups over >>>> LDAP. Compat tree will do lookup through SSSD on your behalf. This means >>>> we don't depend on how Windows side provides or does not provide >>>> attributes. >>>> Everything SSSD can resolve, can be returned, be it stored in AD LDAP, >>>> generated by SSSD, or stored in ID overrides in IPA. >>>> >>>> But the query format is the one described in RFC 2307 because this is >>>> what all nss implementations like nss_ldap or similar ones use in >>>> UNIX-like environments. Windows Server is merely implementing the same >>>> LDAP schema to allow interoperability with the same clients. Think of >>>> Compat Tree in IPA as doing the same, just dynamically. >>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 22 18:26:29 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Feb 2017 13:26:29 -0500 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! In-Reply-To: <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> References: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> Message-ID: <49e4b790-0288-2fa1-b5c3-bf0483d5757d@redhat.com> Peter Fern wrote: > Okay, with much debugging and hoop-jumping, I can say that certmonger on > Debian/Ubuntu is currently in a rather broken state, at least in a > server role. > > It links against libcurl3-nss, however on Debian/-derivs there is no > build of nss-pem, so anything built against libcurl3-nss cannot parse > PEM formatted certs. This results in a failure to process the IPA CA > from the filesystem, causing the certmonger agent to fail verification > of the server cert, producing the curl 'Error 77 connecting to: Problem > with the SSL CA cert (path? access rights?)' return, which makes it > impossible to renew certificates, and resulted in wedging my deployment > as described. > > Does the FreeIPA issue tracker accept distro-specific reports, or is > there somewhere more appropriate I should be sending this? As it > stands, operating a CA on Debian/Ubuntu will break in painful and > unexpected fashion, and should be avoided. Very nice job in tracking this down. You can certainly open a ticket against freeipa or certmonger but I think this is more a packaging issue in Debian, et al (although granted a very non-obvious one). It's been many moons since I worked on nss-pem but from what I can tell it should be buildable outside of NSS so can ship as a separate package. You might try building it locally to see if it resolves the issues for you. It resides at https://github.com/kdudka/nss-pem I don't know who does the certmonger packaging, is that you Timo? rob > > On 21/02/17 23:36, Peter Fern wrote: >> I don't know why the certs did not auto-renew originally, but now I am >> very stuck trying to get my CA functional again. I've tried setting the >> clock back to a week or two before the certs were due to expire, but I'm >> still having no luck getting the CA functional. >> >> This is a Ubuntu server, so some paths are different to what may be >> found on RPM-based distros. Any urgent help would be greatly >> appreciated - I've been bashing against this for a couple of hours now >> with no luck, and the hour is getting late. >> >> Below is my current (anonymized) `getcert list` of the problem certs, >> where you will see my current ca-error: >> >> Request ID '20160616123036': >> status: CA_UNREACHABLE >> ca-error: Error 77 connecting to >> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem >> with the SSL CA cert (path? access rights?). >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=IPA RA,O=EXAMPLE.COM >> expires: 2017-02-11 05:52:26 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre >> post-save command: /usr/lib/ipa/certmonger/renew_ra_cert >> track: yes >> auto-renew: yes >> Request ID '20160616123427': >> status: CA_UNREACHABLE >> ca-error: Error 77 connecting to >> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem >> with the SSL CA cert (path? access rights?). >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Audit,O=EXAMPLE.COM >> expires: 2017-02-11 05:52:03 UTC >> key usage: digitalSignature,nonRepudiation >> pre-save command: /usr/lib/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20160616123428': >> status: CA_UNREACHABLE >> ca-error: Error 77 connecting to >> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem >> with the SSL CA cert (path? access rights?). >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=OCSP Subsystem,O=EXAMPLE.COM >> expires: 2017-02-11 05:52:01 UTC >> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >> eku: id-kp-OCSPSigning >> pre-save command: /usr/lib/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib/ipa/certmonger/renew_ca_cert >> "ocspSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20160616123429': >> status: CA_UNREACHABLE >> ca-error: Error 77 connecting to >> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem >> with the SSL CA cert (path? access rights?). >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Subsystem,O=EXAMPLE.COM >> expires: 2017-02-11 05:52:01 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: /usr/lib/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib/ipa/certmonger/renew_ca_cert >> "subsystemCert cert-pki-ca" >> track: yes >> auto-renew: yes >> >> >> >> All I get in the logs (with debug enabled) is: >> >> Jan 20 06:52:52 ipaserver.example.com >> dogtag-ipa-ca-renew-agent-submit[2121]: Forwarding request to >> dogtag-ipa-renew-agent >> Jan 20 06:52:52 ipaserver.example.com >> dogtag-ipa-renew-agent-submit[2307]: GET >> https://ipaserver.example.com:8443/ca/agent/ca/profileReview?requestId=69960009&xml=true >> Jan 20 06:52:52 ipaserver.example.com >> dogtag-ipa-renew-agent-submit[2307]: (null) >> Jan 20 06:52:52 ipaserver.example.com >> dogtag-ipa-ca-renew-agent-submit[2121]: dogtag-ipa-renew-agent returned 3 >> Jan 20 06:52:52 ipaserver.example.com certmonger[2016]: 2017-01-20 >> 06:52:52 [2016] Error 77 connecting to >> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem >> with the SSL CA cert (path? access rights?). >> > From abokovoy at redhat.com Wed Feb 22 19:38:46 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Feb 2017 21:38:46 +0200 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <1534665880.782.1487773979256.JavaMail.zimbra@tresgeek.net> <20170222145055.vwovjrnvjaxkpwkh@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> Message-ID: <20170222193846.wjxofl533tzlldw2@redhat.com> On ke, 22 helmi 2017, Hanoz Elavia wrote: >Hey Alexander, > >So based on the RFC 2307 documentation, I built a test server and ran the >following command: > > ldapsearch -x -W -H 'ldap://ipa.server.com' -b >'cn=compat,dc=ipa,dc=server,dc=com' -D >'uid=admin,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' -s sub 'uid= >ad_user at server.com' > >It worked as expected. Then once I rebooted the test server it stopped >working. Any idea which service might be failing ? As I said, these are dynamic entries. You should use proper queries. I mentioned RFC2307, use section 5.2 to get proper queries. For example, for user that would be (&(objectClass=posixAccount)(uid=%s)) where %s is ad_user at server.com according to your example. This is what would be intercepted and queried through SSSD. For example: $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool '(&(objectClass=posixAccount)(uid=user at ad.ipa.cool))' SASL/GSSAPI authentication started SASL username: admin at XS.IPA.COOL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectClass=posixAccount)(uid=user at ad.ipa.cool)) # requesting: ALL # # user at ad.ipa.cool, users, compat, xs.ipa.cool dn: uid=user at ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool objectClass: ipaOverrideTarget objectClass: posixAccount objectClass: top cn: YO! gidNumber: 967001113 gecos: YO! ipaAnchorUUID:: uidNumber: 967001113 loginShell: /bin/bash homeDirectory: /home/ad.ipa.cool/user uid: user at ad.ipa.cool # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 > >Regards, > >Hanoz > > > >On Wed, Feb 22, 2017 at 8:40 AM, Hanoz Elavia >wrote: > >> Hey Alex, >> >> Thanks, I ran ipa-compat-manage status and it shows Plugin enabled. I'll >> have a look at the link and see if we can change the query to obtain the >> info required. >> >> Regards, >> >> Hanoz >> >> >> *Hanoz Elavia |* IT Manager >> *O:* 604-734-2866 *|* *www.atomiccartoons.com >> * >> 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 >> >> On Wed, Feb 22, 2017 at 8:34 AM, Alexander Bokovoy >> wrote: >> >>> On ke, 22 helmi 2017, Hanoz Elavia wrote: >>> >>>> Thanks Alex, >>>> >>>> Does it also means that I'll have to install the FreeIPA server with >>>> --enable-compat ? I didn't do that. >>>> >>> >>> check ipa-compat-manage tool. >>> >>> >>>> Regards, >>>> >>>> Hanoz >>>> >>>> >>>> *Hanoz Elavia |* IT Manager >>>> *O:* 604-734-2866 *|* *www.atomiccartoons.com >>>> * >>>> 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 >>>> >>>> On Wed, Feb 22, 2017 at 7:22 AM, Alexander Bokovoy >>>> wrote: >>>> >>>> On ke, 22 helmi 2017, Hanoz Elavia wrote: >>>>> >>>>> Hey Alex, >>>>>> >>>>>> Thanks for the link, isn't RFC 2307 implemented as Services for Unix in >>>>>> Windows 2008 R2? Apologies for not mentioning this earlier but I >>>>>> haven't >>>>>> enabled that mainly because SSSD now maps the IDs. Also, in the newer >>>>>> version of the Windows Server, SFU seems to have been discontinued. >>>>>> >>>>>> I think you are confused by the names. What Compat tree provides is an >>>>> interface on IPA side to look up identities of AD users and groups over >>>>> LDAP. Compat tree will do lookup through SSSD on your behalf. This means >>>>> we don't depend on how Windows side provides or does not provide >>>>> attributes. >>>>> Everything SSSD can resolve, can be returned, be it stored in AD LDAP, >>>>> generated by SSSD, or stored in ID overrides in IPA. >>>>> >>>>> But the query format is the one described in RFC 2307 because this is >>>>> what all nss implementations like nss_ldap or similar ones use in >>>>> UNIX-like environments. Windows Server is merely implementing the same >>>>> LDAP schema to allow interoperability with the same clients. Think of >>>>> Compat Tree in IPA as doing the same, just dynamically. >>>>> >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>> -- >>> / Alexander Bokovoy >>> >> >> -- / Alexander Bokovoy From michael at stroeder.com Wed Feb 22 20:02:42 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 22 Feb 2017 21:02:42 +0100 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server In-Reply-To: References: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> <120e6725-3891-6bbd-5ae3-7ad187a872e2@stroeder.com> Message-ID: <430f2a60-3f95-150d-3b42-b2ade5c2ce33@stroeder.com> Iulian Roman wrote: > On Wed, Feb 22, 2017 at 6:03 PM, Michael Str?der > wrote: > > Iulian Roman wrote: > > On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden > > >> wrote: > > > > Iulian Roman wrote: > > > Does anybody know if the rfc2307aix schema is supported in IPA server > > > > No, it isn't supported (it's the first I've ever heard of it). Looking > > at the schema I doubt it is something that would ever be fully supported. > > > > is there any possibility to extend the existing schema with additional > > attributes/object > > Do you really use this specific AIX schema? > If yes, which attributes for which purpose? > > I do need the aixAuxAccount and aixAuxGroup object classes . they implement some > password restrictions needed for security/compliance Password policy is something best enforced centrally in the authentication server and password management system. So IMHO this serves as perfect example for proprietary attributes you won't need. How is authentication done? SSH keys, Kerberos, LDAP simple bind? > + some other security related attributes. > Personally i do not consider them a must - they are rather some nice to have features - > but i have to migrate an environment which does use them. And i would like as well to > make the migration as transparent as possible (therefore without "missing features"). Is the existing environment also an LDAP server with this particular AIX schema? Or are you trying to follow a migration path to LDAP suggested by IBM docs? Being in your position I'd first compile a list of functional and security requirements and ask then whether these requirements can be implemented with FreeIPA. I'm curious to learn whether "some other security related attributes" are still needed after all. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From lslebodn at redhat.com Wed Feb 22 20:24:44 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 22 Feb 2017 21:24:44 +0100 Subject: [Freeipa-users] FreeIPA Fedora 25 and IPA CentOS 7.3 In-Reply-To: <20170222105945.kpue4rdllzcjtjlp@redhat.com> References: <20170222105945.kpue4rdllzcjtjlp@redhat.com> Message-ID: <20170222202444.GC4758@10.4.128.1> On (22/02/17 12:59), Alexander Bokovoy wrote: >On ke, 22 helmi 2017, Ente Trompete wrote: >> The next question which I have is: can I install a Fedora 25 and use >> the included FreeIPA v4.4.1-3 to create a replica of the existing >> 4.4.0-14? My problem is that I will use an ARM32 computer as replica >> and Centos 7.3 runs properly on it but the repositories includes only >> ipa-client packages. No ipa-server* package (BTW also for ARM64 is only >> ipa-server-common available). But in the repositories of Fedora 25 >> ARM32 I can found all. >Packages in Fedora are 'freeipa-*', packages in RHEL/CentOS are 'ipa-*'. > There is not any problem to install ipa-server on fedora. There are provides. sh# cat /etc/os-release NAME=Fedora VERSION="26 (Server Edition)" ID=fedora VERSION_ID=26 PRETTY_NAME="Fedora 26 (Server Edition)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:26" HOME_URL="https://fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=rawhide PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy VARIANT="Server Edition" VARIANT_ID=server sh# dnf install ipa-server Last metadata expiration check: 1:48:26 ago on Wed Feb 22 19:33:40 2017 CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: freeipa-server x86_64 4.4.3-4.fc26 rawhide 380 k Installing dependencies: LS From lslebodn at redhat.com Wed Feb 22 20:41:48 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 22 Feb 2017 21:41:48 +0100 Subject: [Freeipa-users] Debian client installation In-Reply-To: <9D807AF0-6918-4AB4-9AE0-3CDCE330385F@me.com> References: <9650A9F7-BC3E-4FA8-B2EC-9A98FF249630@me.com> <4aa5e734-406e-a080-7d62-3f4433a0996e@ubuntu.com> <9D807AF0-6918-4AB4-9AE0-3CDCE330385F@me.com> Message-ID: <20170222204147.GD4758@10.4.128.1> On (22/02/17 17:35), Per Qvindesland wrote: >Hi > >Thanks for the answer. > >Is there any workaround for this that anyone can suggest? > There are two vesions of sudo packages in debian sudo and sudo-ldap. IIRC the 1st one is compiled with sssd support and 2nd one just with ldap support. Which one do you use ? You can check output of sudo --version | grep sss. If neither of pacakges are compiled with sssd by default in wheezy then you can try install packages from wheezy-backports. And then I would recommend to follow instructions in manual page sssd-sudo. LS From jason at tresgeek.net Wed Feb 22 21:50:06 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 22 Feb 2017 15:50:06 -0600 (CST) Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <20170222193846.wjxofl533tzlldw2@redhat.com> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> <20170222193846.wjxofl533tzlldw2@redhat.com> Message-ID: <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> > For example, for user that would be (&(objectClass=posixAccount)(uid=%s)) > where %s is ad_user at server.com according to your example. > > This is what would be intercepted and queried through SSSD. > > For example: > > $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool > '(&(objectClass=posixAccount)(uid=user at ad.ipa.cool))' > SASL/GSSAPI authentication started > SASL username: admin at XS.IPA.COOL > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectClass=posixAccount)(uid=user at ad.ipa.cool)) > # requesting: ALL > # > > # user at ad.ipa.cool, users, compat, xs.ipa.cool > dn: uid=user at ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool > objectClass: ipaOverrideTarget > objectClass: posixAccount > objectClass: top > cn: YO! > gidNumber: 967001113 > gecos: YO! > ipaAnchorUUID:: > uidNumber: 967001113 > loginShell: /bin/bash > homeDirectory: /home/ad.ipa.cool/user > uid: user at ad.ipa.cool > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 I'm not able to recreate this (on FreeIPA 4.4.0). "ipa-compat-manage status" says "Plugin Enabled", but searches for AD users yield no results: $ ldapsearch -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' -W -x -D 'cn=Directory Manager' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectClass=posixAccount)(uid=jnance at lab.gen.zone)) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 I'm currently logged into the machine with an AD account from a trust: [jnance at lab.gen.zone@sl2aospljmp0001 ~]$ whoami jnance at lab.gen.zone [jnance at lab.gen.zone@sl2aospljmp0001 ~]$ id uid=21104(jnance at lab.gen.zone) gid=21104(jnance at lab.gen.zone) groups=21104(jnance at lab.gen.zone),10009(lgz-lxusers),10011(lxeng),20512(domain admins at lab.gen.zone),20513(domain users at lab.gen.zone),21112(lxusers at lab.gen.zone),21117(lab_admins at lab.gen.zone) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 If I search for a user that is local to IPA it works: $ ldapsearch -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone '(&(objectClass=posixAccount)(uid=jnance-ipa))' -W -x -D 'cn=Directory Manager' -H 'ldaps://sl2mmgplidm0001.ipa.lab.gen.zone' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectClass=posixAccount)(uid=jnance-ipa)) # requesting: ALL # # jnance-ipa, users, compat, ipa.lab.gen.zone dn: uid=jnance-ipa,cn=users,cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone cn: Jason Nance objectClass: posixAccount objectClass: ipaOverrideTarget objectClass: top gidNumber: 10008 gecos: Jason Nance ipaAnchorUUID:: OklQQTppcGEubGFiLmdlbi56b25lOmQxYzU0NGI2LWU5YjktMTFlNi1iNWM1LT AwNTA1NjkxMGE0NA== uidNumber: 10008 loginShell: /bin/bash homeDirectory: /home/jnance-ipa uid: jnance-ipa # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 As a side note, I'm also not able to use GSSAPI auth as you did: $ kinit Password for jnance at LAB.GEN.ZONE: $ ldapsearch -Y GSSAPI -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) From ayoung at marketfactory.com Wed Feb 22 22:01:19 2017 From: ayoung at marketfactory.com (Aaron Young) Date: Wed, 22 Feb 2017 17:01:19 -0500 Subject: [Freeipa-users] lost master master and soa In-Reply-To: <4785748a-fda6-6842-b5ef-199da553e1e9@redhat.com> References: <4785748a-fda6-6842-b5ef-199da553e1e9@redhat.com> Message-ID: sorry for the late response, yes, this was helpful I ended up realizing that each IPA server is a kind of SOA and that I needed to get rid of the old master and much of it resolved itself...until the next problem surfaced that is keeping me from creating a new master (at least, with my limited knowledge) i'll start a new message about this to help the web searchers in the future On Tue, Feb 14, 2017 at 2:18 AM, Martin Babinsky wrote: > On 02/13/2017 10:12 PM, Aaron Young wrote: > >> hello >> >> So, I recently took over this site and a couple days into it, the first >> ipa server died because of disk corruption. >> >> Right now, I've built another ipa server to step into the topology as a >> replica, but I keep getting strange dns errors during update >> >> Looking at it closer, it appears that when nsupdate runs, it fails >> updating >> >> looking closer, I notice that the SOA comes back with the name of the >> missing server >> >> So, it seems like I should change that. So far I've been unable to >> >> I get messages back from nsupdate like >> >> "response to SOA query was unsuccessful" >> >> I'm not sure what information I should send to help with this >> >> My main question is, is there a way to force the change of the SOA? >> >> aaron >> -- >> Aaron Young >> MarketFactory, Manager of Site Reliability Engineering >> 425 Broadway, 3FL >> New York, NY 10013 >> Office: +1 212 625 9988 >> Direct +1 646 779 3710 >> US Support: +1 (212) 625-0688 | UK >> Support: +44 (0) 203 695-7997 >> >> >> > Hi Aaron, > > there may be some stale NS record on other IPA masters which serve your > DNS zone. you can verify this by running: > > # ipa dnsrecord-show @ > > and check the list of nameservers returned. > > To remove the record of the old master run > > # ipa dnsrecord-del @ --ns-rec > > Also, make sure you cleaned up old agreements, services, etc. of the old > master by running `ipa-replica-manage del --force --cleanup ` > on some other IPA master. > > You will also probably have to stand-up a new CA renewal/CRL master[1] on > one of remaining replicas if the first server died and you have CA > configured. > > [1] http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > > Hope this helps > > -- > Martin^3 Babinsky > -- Aaron Young MarketFactory, Manager of Site Reliability Engineering 425 Broadway, 3FL New York, NY 10013 Office: +1 212 625 9988 Direct +1 646 779 3710 US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Wed Feb 22 22:07:02 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 14:07:02 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> <20170222193846.wjxofl533tzlldw2@redhat.com> <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> Message-ID: Hey Jason, I realized I had made one more change. I setup the FreeIPA server again and this time I added the --enable-compat with my /usr/sbin/ipa-adtrust-install command. Yes, I cannot use GSSAPI as well. I use simple bind to run a LDAP query. On IPA clients I don't need to authenticate as IPA takes care of that. Hope this helps. Regards, Hanoz *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Wed, Feb 22, 2017 at 1:50 PM, Jason B. Nance wrote: > > For example, for user that would be (&(objectClass=posixAccount)( > uid=%s)) > > where %s is ad_user at server.com according to your example. > > > > This is what would be intercepted and queried through SSSD. > > > > For example: > > > > $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool > > '(&(objectClass=posixAccount)(uid=user at ad.ipa.cool))' > > SASL/GSSAPI authentication started > > SASL username: admin at XS.IPA.COOL > > SASL SSF: 56 > > SASL data security layer installed. > > # extended LDIF > > # > > # LDAPv3 > > # base with scope subtree > > # filter: (&(objectClass=posixAccount)(uid=user at ad.ipa.cool)) > > # requesting: ALL > > # > > > > # user at ad.ipa.cool, users, compat, xs.ipa.cool > > dn: uid=user at ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool > > objectClass: ipaOverrideTarget > > objectClass: posixAccount > > objectClass: top > > cn: YO! > > gidNumber: 967001113 > > gecos: YO! > > ipaAnchorUUID:: > > uidNumber: 967001113 > > loginShell: /bin/bash > > homeDirectory: /home/ad.ipa.cool/user > > uid: user at ad.ipa.cool > > > > # search result > > search: 4 > > result: 0 Success > > > > # numResponses: 2 > > # numEntries: 1 > > I'm not able to recreate this (on FreeIPA 4.4.0). "ipa-compat-manage > status" says "Plugin Enabled", but searches for AD users yield no results: > > $ ldapsearch -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone > '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' -W -x -D > 'cn=Directory Manager' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectClass=posixAccount)(uid=jnance at lab.gen.zone)) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > > I'm currently logged into the machine with an AD account from a trust: > > [jnance at lab.gen.zone@sl2aospljmp0001 ~]$ whoami > jnance at lab.gen.zone > [jnance at lab.gen.zone@sl2aospljmp0001 ~]$ id > uid=21104(jnance at lab.gen.zone) gid=21104(jnance at lab.gen.zone) > groups=21104(jnance at lab.gen.zone),10009(lgz-lxusers),10011(lxeng),20512(domain > admins at lab.gen.zone),20513(domain users at lab.gen.zone),21112( > lxusers at lab.gen.zone),21117(lab_admins at lab.gen.zone) context=unconfined_u: > unconfined_r:unconfined_t:s0-s0:c0.c1023 > > > If I search for a user that is local to IPA it works: > > $ ldapsearch -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone > '(&(objectClass=posixAccount)(uid=jnance-ipa))' -W -x -D 'cn=Directory > Manager' -H 'ldaps://sl2mmgplidm0001.ipa.lab.gen.zone' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectClass=posixAccount)(uid=jnance-ipa)) > # requesting: ALL > # > > # jnance-ipa, users, compat, ipa.lab.gen.zone > dn: uid=jnance-ipa,cn=users,cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone > cn: Jason Nance > objectClass: posixAccount > objectClass: ipaOverrideTarget > objectClass: top > gidNumber: 10008 > gecos: Jason Nance > ipaAnchorUUID:: OklQQTppcGEubGFiLmdlbi56b25lOm > QxYzU0NGI2LWU5YjktMTFlNi1iNWM1LT > AwNTA1NjkxMGE0NA== > uidNumber: 10008 > loginShell: /bin/bash > homeDirectory: /home/jnance-ipa > uid: jnance-ipa > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > As a side note, I'm also not able to use GSSAPI auth as you did: > > $ kinit > Password for jnance at LAB.GEN.ZONE: > $ ldapsearch -Y GSSAPI -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone > '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Wed Feb 22 22:08:35 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 14:08:35 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> <20170222193846.wjxofl533tzlldw2@redhat.com> <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> Message-ID: Hey Jason, Also, my bind DN is a native FreeIPA user and doesn't exist on the Active Directory. Regards, Hanoz *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Wed, Feb 22, 2017 at 2:07 PM, Hanoz Elavia wrote: > Hey Jason, > > I realized I had made one more change. I setup the FreeIPA server again > and this time I added the --enable-compat with my > /usr/sbin/ipa-adtrust-install command. > > Yes, I cannot use GSSAPI as well. I use simple bind to run a LDAP query. > On IPA clients I don't need to authenticate as IPA takes care of that. Hope > this helps. > > Regards, > > Hanoz > > > *Hanoz Elavia |* IT Manager > *O:* 604-734-2866 *|* *www.atomiccartoons.com > * > 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 > > On Wed, Feb 22, 2017 at 1:50 PM, Jason B. Nance > wrote: > >> > For example, for user that would be (&(objectClass=posixAccount)(u >> id=%s)) >> > where %s is ad_user at server.com according to your example. >> > >> > This is what would be intercepted and queried through SSSD. >> > >> > For example: >> > >> > $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool >> > '(&(objectClass=posixAccount)(uid=user at ad.ipa.cool))' >> > SASL/GSSAPI authentication started >> > SASL username: admin at XS.IPA.COOL >> > SASL SSF: 56 >> > SASL data security layer installed. >> > # extended LDIF >> > # >> > # LDAPv3 >> > # base with scope subtree >> > # filter: (&(objectClass=posixAccount)(uid=user at ad.ipa.cool)) >> > # requesting: ALL >> > # >> > >> > # user at ad.ipa.cool, users, compat, xs.ipa.cool >> > dn: uid=user at ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool >> > objectClass: ipaOverrideTarget >> > objectClass: posixAccount >> > objectClass: top >> > cn: YO! >> > gidNumber: 967001113 >> > gecos: YO! >> > ipaAnchorUUID:: >> > uidNumber: 967001113 >> > loginShell: /bin/bash >> > homeDirectory: /home/ad.ipa.cool/user >> > uid: user at ad.ipa.cool >> > >> > # search result >> > search: 4 >> > result: 0 Success >> > >> > # numResponses: 2 >> > # numEntries: 1 >> >> I'm not able to recreate this (on FreeIPA 4.4.0). "ipa-compat-manage >> status" says "Plugin Enabled", but searches for AD users yield no results: >> >> $ ldapsearch -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone >> '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' -W -x -D >> 'cn=Directory Manager' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (&(objectClass=posixAccount)(uid=jnance at lab.gen.zone)) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> >> >> I'm currently logged into the machine with an AD account from a trust: >> >> [jnance at lab.gen.zone@sl2aospljmp0001 ~]$ whoami >> jnance at lab.gen.zone >> [jnance at lab.gen.zone@sl2aospljmp0001 ~]$ id >> uid=21104(jnance at lab.gen.zone) gid=21104(jnance at lab.gen.zone) >> groups=21104(jnance at lab.gen.zone),10009(lgz-lxusers),10011(lxeng),20512(domain >> admins at lab.gen.zone),20513(domain users at lab.gen.zone),21112(lxus >> ers at lab.gen.zone),21117(lab_admins at lab.gen.zone) >> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >> >> >> If I search for a user that is local to IPA it works: >> >> $ ldapsearch -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone >> '(&(objectClass=posixAccount)(uid=jnance-ipa))' -W -x -D 'cn=Directory >> Manager' -H 'ldaps://sl2mmgplidm0001.ipa.lab.gen.zone' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (&(objectClass=posixAccount)(uid=jnance-ipa)) >> # requesting: ALL >> # >> >> # jnance-ipa, users, compat, ipa.lab.gen.zone >> dn: uid=jnance-ipa,cn=users,cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone >> cn: Jason Nance >> objectClass: posixAccount >> objectClass: ipaOverrideTarget >> objectClass: top >> gidNumber: 10008 >> gecos: Jason Nance >> ipaAnchorUUID:: OklQQTppcGEubGFiLmdlbi56b25lOm >> QxYzU0NGI2LWU5YjktMTFlNi1iNWM1LT >> AwNTA1NjkxMGE0NA== >> uidNumber: 10008 >> loginShell: /bin/bash >> homeDirectory: /home/jnance-ipa >> uid: jnance-ipa >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> >> As a side note, I'm also not able to use GSSAPI auth as you did: >> >> $ kinit >> Password for jnance at LAB.GEN.ZONE: >> $ ldapsearch -Y GSSAPI -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone >> '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' >> SASL/GSSAPI authentication started >> ldap_sasl_interactive_bind_s: Invalid credentials (49) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Wed Feb 22 22:19:48 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 22 Feb 2017 16:19:48 -0600 (CST) Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> <20170222193846.wjxofl533tzlldw2@redhat.com> <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> Message-ID: <1110466651.987.1487801988825.JavaMail.zimbra@tresgeek.net> > I realized I had made one more change. I setup the FreeIPA server again and this > time I added the --enable-compat with my /usr/sbin/ipa-adtrust-install command. Is it safe to re-run ipa-adtrust-install? I have existing trusts in place. Thanks, j -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Wed Feb 22 22:24:02 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Wed, 22 Feb 2017 14:24:02 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <1110466651.987.1487801988825.JavaMail.zimbra@tresgeek.net> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> <20170222193846.wjxofl533tzlldw2@redhat.com> <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> <1110466651.987.1487801988825.JavaMail.zimbra@tresgeek.net> Message-ID: Hey Jason, I am not sure about that. I just rebuilt my IPA server since it's only purpose is to authenticate users with the AD. As for the clients, I removed them from the FreeIPA server using ipa-client-install --uninstall and rebooted. Once they rebooted my saltstack state added them back to the server. Sorry, I can't help you much there. Regards, Hanoz *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Wed, Feb 22, 2017 at 2:19 PM, Jason B. Nance wrote: > > I realized I had made one more change. I setup the FreeIPA server again > and this time I added the --enable-compat with my > /usr/sbin/ipa-adtrust-install command. > > Is it safe to re-run ipa-adtrust-install? I have existing trusts in place. > > Thanks, > > j > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at marketfactory.com Wed Feb 22 22:26:37 2017 From: ayoung at marketfactory.com (Aaron Young) Date: Wed, 22 Feb 2017 17:26:37 -0500 Subject: [Freeipa-users] authenticating with dns Message-ID: Hello Everyone I recently lost the master master IPA server setup by the previous administrator. As it stands now, if I try to add a new client, in order to standup a new replica, I get errors while trying to setup DNS. This led me to look at how authentication worked (I'm new to IPA) and I learned about the kerberos tools I don't know if I'm familiar enough with the terminology to adequately describe what I'm experiencing, so I'll give you some of the commands and their results but first, a bit on the design before I got to this, we had a <-> b <-> c <-> d b was the master master a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 (not pictured, I discovered them later when c and d started having problems) a - nyc01ipa02 b - nyc01ipa01 c - ld4ipa01 d - ld4ipa02 currently, I have nyc02ipa02 <-> nyc01ipa02 the reason I have it limited like this is because all the other servers stopped replicating for one reason or another (mainly that they can't authenticate or in one case, there was a database record corruption) Anyway, here are some activities and logs from the latest round of fixes and information activities I've been engaging in 22:54:32 root at nyc01ipa02:~# kinit admin kinit: Clients credentials have been revoked while getting initial credentials Reading through this tells me that # kadmin: modprinc -unlock PRINCNAME will unlock an account...but if I can't get in.... 22:54:37 root at nyc01ipa02:~# kadmin Authenticating as principal root/admin at MF with password. kadmin: Client 'root/admin at MF' not found in Kerberos database while initializing kadmin interface on ld4ipa02, did a # ipa-client-install --uninstall then # ipa-client-install --force-join --enable-dns-updates --permit -f --ssh-trust-dns --request-cert --automount-location=LD4 --enable-dns-updates DNS did not update, here is the relevant portion from /var/log/ipaclient-install.log 2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt: 2017-02-20T18:46:49Z DEBUG debug update delete ld4ipa02.mf. IN A show send update delete ld4ipa02.mf. IN AAAA show send update add ld4ipa02.mf. 1200 IN A 10.102.100.140 show send 2017-02-20T18:46:49Z DEBUG Starting external process 2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt 2017-02-20T18:46:49Z DEBUG Process finished, return code=1 2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTION: ld4ipa02.mf. 0 ANY A 2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702 ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ld4ipa02.mf. IN SOA ;; AUTHORITY SECTION: mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600 Found zone name: mf The master is: ld4ipa01.mf start_gssrequest tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ld4ipa01.mf at MF not found in Kerberos database. 2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 2017-02-20T18:46:49Z ERROR Failed to update DNS records. 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN AAAA 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: 140.100.102.10.in-addr.arpa. IN PTR 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. 2017-02-20T18:46:49Z WARNING Missing A/AAAA record(s) for host ld4ipa02.mf: 10.102.100.140. 2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 10.102.100.140. Why isn't there an entry for "DNS/ld4ipa01.mf at MF" in the Kerberos database? klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns Keytab name: FILE:/etc/dirsrv/ds.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x696a502bc73d209acdd36c42242f7f8aff9dbba1073b34ea018ed3bd9cdfd970) 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe031464b6948ea34f4291d40fca7a21e) 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe94a1c98fe79b6317901435d9e9e0257cefe438ff2ec527f) 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6aaf4c7fa6b51b9de032b7c6428307b5) 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x5e0702f44aef9e0633e09eede7ca8041) 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6e3a9d29ee3f129a156ae6228ab7728df8ce5de923a61eba6a2e7802b8d230b6) Tried to test connectivity using ldapsearch found that I could connect to other hosts on 389 but not 636 # ldapsearch -H ldap://nyc02ipa02:389 -D "cn=directory manager" -W -b "" -s base # ldapsearch -H ldaps://nyc02ipa02:686 -D "cn=directory manager" -W -b "" -s base Testing the kvno 02:10:00 root at ld4ipa01:~# kvno DNS/ld4ipa01.mf at MF DNS/ld4ipa01.mf at MF: kvno = 2 02:10:52 root at ld4ipa02:~# kvno DNS/ld4ipa01.mf at MF kvno: Server DNS/ld4ipa01.mf at MF not found in Kerberos database while getting credentials for DNS/ld4ipa01.mf at MF Add this to any command line to get debug on kerberos commands KRB5_TRACE=/dev/stdout kvno DNS/ld4ipa01.mf at MF So, looking at the debug kvno from ld4ipa02, does not return tickets. It does this because it contacts the KDC which is nyc02ipa02, and nyc02ipa02 does not recognize ldipa02 as an IPA server. It doesn't recognize ld4ipa01 either. right now, if I try to connect nyc02ipa02 to ld4ipa01 I get 21:56:27 root at nyc02ipa02:~# ipa topologysegment-add domain ld4ipa01-to-nyc02ipa02 --leftnode ld4ipa01.mf --rightnode nyc02ipa02.mf ipa: ERROR: invalid 'leftnode': left node is not a topology node: ld4ipa01.mf ipa privilege-show 'DNS Servers' --all --raw dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=mf cn: DNS Servers description: DNS Servers member: krbprincipalname=DNS/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf member: krbprincipalname=ipa-dnskeysyncd/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf member: krbprincipalname=DNS/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf member: krbprincipalname=ipa-dnskeysyncd/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf member: krbprincipalname=ipa-ods-exporter/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf memberof: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=mf memberof: cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=mf objectClass: top objectClass: groupofnames objectClass: nestedgroup -- Aaron Young MarketFactory, Manager of Site Reliability Engineering 425 Broadway, 3FL New York, NY 10013 Office: +1 212 625 9988 Direct +1 646 779 3710 US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From splash at gmail.com Wed Feb 22 23:17:23 2017 From: splash at gmail.com (Diogenes S. Jesus) Date: Thu, 23 Feb 2017 00:17:23 +0100 Subject: [Freeipa-users] FreeIPA 4.3.1 ipa-replica-install wrong exit code? Message-ID: We are ansible-playbooking FreeIPA and we don't want to care about if freeipa is installed, we just want to ignore errors if it already is - but for that the exit code is relevant. Either the return code is wrong in the code or in the manual - according to the manual, it should be 3, but it's currently 1. ubuntu at ipa02:~$ sudo -i root at ipa02:~# http_proxy='' https_proxy='' ipa-replica-install --dirsrv-cert-file=/etc/ssl/private/ipa02.dev.pfx --http-cert-file=/etc/ssl/private/ipa02.dev.pfx --dirsrv-pin=export --http-pin=export ipa.ipapython.install.cli.install_tool(Replica): ERROR IPA server is already configured on this system. If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'. ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information root at ipa02:~# echo $? 1 root at ipa02:~# cat /var/log/ipareplica-install.log 2017-02-22T22:49:45Z DEBUG Logging to /var/log/ipareplica-install.log 2017-02-22T22:49:45Z DEBUG ipa-replica-install was invoked with arguments [] and options: {'no_dns_sshfp': None, 'skip_schema_check': None, 'setup_kra': None, 'ip_addresses': None, 'mkhomedir': None, 'no_pkinit': None, 'http_cert_files': ['/etc/ssl/private/ipa02.dev.pfx'], 'no_ntp': None, 'verbose': False, 'no_forwarders': None, 'keytab': None, 'ssh_trust_dns': None, 'domain_name': None, 'http_cert_name': None, 'dirsrv_cert_files': ['/etc/ssl/private/ipa02.dev.pfx'], 'no_dnssec_validation': None, 'no_reverse': None, 'pkinit_cert_files': None, 'unattended': False, 'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, 'no_sshd': None, 'no_ui_redirect': None, 'dirsrv_config_file': None, 'forwarders': None, 'pkinit_cert_name': None, 'setup_ca': None, 'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, 'dirsrv_cert_name': None, 'quiet': False, 'server': None, 'setup_dns': None, 'host_name': None, 'log_file': None, 'reverse_zones': None, 'allow_zone_overlap': None} 2017-02-22T22:49:45Z DEBUG IPA version 4.3.1 2017-02-22T22:49:45Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2017-02-22T22:49:45Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2017-02-22T22:49:45Z DEBUG httpd is configured 2017-02-22T22:49:45Z DEBUG kadmin is configured 2017-02-22T22:49:45Z DEBUG dirsrv is configured 2017-02-22T22:49:45Z DEBUG pki-tomcatd is not configured 2017-02-22T22:49:45Z DEBUG install is not configured 2017-02-22T22:49:45Z DEBUG krb5kdc is configured 2017-02-22T22:49:45Z DEBUG ntpd is configured 2017-02-22T22:49:45Z DEBUG named is not configured 2017-02-22T22:49:45Z DEBUG ipa_memcached is configured 2017-02-22T22:49:45Z DEBUG filestore has files 2017-02-22T22:49:45Z DEBUG File "/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/dist-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 308, in run self.validate() File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 317, in validate for nothing in self._validator(): File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 564, in _configure next(validator) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/dist-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", line 1650, in main promote_check(self) File "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", line 375, in decorated func(installer) File "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", line 397, in decorated func(installer) File "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", line 952, in promote_check sys.exit("IPA server is already configured on this system.\n" 2017-02-22T22:49:45Z DEBUG The ipa-replica-install command failed, exception: SystemExit: IPA server is already configured on this system. If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'. 2017-02-22T22:49:45Z ERROR IPA server is already configured on this system. If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'. 2017-02-22T22:49:45Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information ------ For those looking for a workaround meanwhile do: python -c 'import sys; from ipaserver.install.installutils import is_ipa_configured; sys.exit(is_ipa_configured())' As proposed here: https://fedorahosted.org/freeipa/ticket/4884 Dio -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.mathis+freeipa at betteradmin.com Wed Feb 22 23:47:52 2017 From: brian.mathis+freeipa at betteradmin.com (Brian Mathis) Date: Wed, 22 Feb 2017 18:47:52 -0500 Subject: [Freeipa-users] Recommended approach to VM snapshot prior to upgrade Message-ID: I have a 3-node cluster running FreeIPA 4.2 on RHEL 7.2. I would like to upgrade to RHEL 7.3 / IPA 4.4, and I want to make VM snapshots that I can rollback to in case there are issues. What is the recommended approach to this? Should services already be started when running the yum update? Can I shut down each ipa service one by one, snapshot, then upgrade? How would replication be affected if I had to rollback to the older snapshot after other nodes had been upgraded? Or is it better to shut down all ipa services on all nodes, make snapshots, then perform the upgrade? Obviously that would bring down the domain during the upgrade, but it would better ensure integrity. Thanks, ~ Brian Mathis @orev -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at 0xc0dedbad.com Thu Feb 23 00:04:28 2017 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Thu, 23 Feb 2017 11:04:28 +1100 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! In-Reply-To: <49e4b790-0288-2fa1-b5c3-bf0483d5757d@redhat.com> References: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> <49e4b790-0288-2fa1-b5c3-bf0483d5757d@redhat.com> Message-ID: <05b2653c-9d75-b45a-12f5-a64b6c652029@0xc0dedbad.com> On 23/02/17 05:26, Rob Crittenden wrote: > It's been many moons since I worked on nss-pem but from what I can tell > it should be buildable outside of NSS so can ship as a separate package. > You might try building it locally to see if it resolves the issues for > you. It resides at https://github.com/kdudka/nss-pem I had to modify an include path, and it links against some static libs (libfreebl.a, libnssb.a, libnssckfw.a) that are not included in the current Debian libnss3 packages, so a non-trivial packaging effort. And because certmonger appears to use nss directly, linking against a different libcurl variant is also probably not an option. There are other issues too - the default cert store path of /etc/httpd/alias is still used in the deb package, however the correct path is /etc/apache2/nssdb. From abokovoy at redhat.com Thu Feb 23 06:26:28 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Feb 2017 08:26:28 +0200 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> <20170222193846.wjxofl533tzlldw2@redhat.com> <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> Message-ID: <20170223062628.3scsvt3fpc5b5oky@redhat.com> On ke, 22 helmi 2017, Jason B. Nance wrote: >> For example, for user that would be (&(objectClass=posixAccount)(uid=%s)) >> where %s is ad_user at server.com according to your example. >> >> This is what would be intercepted and queried through SSSD. >> >> For example: >> >> $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool >> '(&(objectClass=posixAccount)(uid=user at ad.ipa.cool))' >> SASL/GSSAPI authentication started >> SASL username: admin at XS.IPA.COOL >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (&(objectClass=posixAccount)(uid=user at ad.ipa.cool)) >> # requesting: ALL >> # >> >> # user at ad.ipa.cool, users, compat, xs.ipa.cool >> dn: uid=user at ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool >> objectClass: ipaOverrideTarget >> objectClass: posixAccount >> objectClass: top >> cn: YO! >> gidNumber: 967001113 >> gecos: YO! >> ipaAnchorUUID:: >> uidNumber: 967001113 >> loginShell: /bin/bash >> homeDirectory: /home/ad.ipa.cool/user >> uid: user at ad.ipa.cool >> >> # search result >> search: 4 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 > >I'm not able to recreate this (on FreeIPA 4.4.0). "ipa-compat-manage >status" says "Plugin Enabled", but searches for AD users yield no >results: Sorry, I forgot mention yesterday that if you didn't use 'ipa-adtrust-install --enable-compat' then one thing is missing from compat tree configuration to allow resolution of AD users. Luckily, it is a simple ldapadd that can fix it. You can use ipa-ldap-updater: # cat 80-enable-compat-nsswitch.update dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config add:schema-compat-lookup-nsswitch: user dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config add:schema-compat-lookup-nsswitch: group # ipa-ldap-updater ./80-enable-compat-nsswitch.update and then restart 389-ds. >As a side note, I'm also not able to use GSSAPI auth as you did: > >$ kinit >Password for jnance at LAB.GEN.ZONE: >$ ldapsearch -Y GSSAPI -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' >SASL/GSSAPI authentication started >ldap_sasl_interactive_bind_s: Invalid credentials (49) I used IPA user, not AD user to bind with GSSAPI. In FreeIPA 4.4 it should also work with AD user as well but only if the user has ID override entry, even empty one: # ipa idoverrideuser-add 'Default Trust View' administrator at ad.ipa.cool and now administrator at ad.ipa.cool will be able to issue ldap searches against IPA LDAP server from Linux machines. Note that ldp.exe will still be unable to perform searches against IPA LDAP until https://github.com/cyrusimap/cyrus-sasl/pull/424 is released in a distribution. -- / Alexander Bokovoy From mbasti at redhat.com Thu Feb 23 07:30:46 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Feb 2017 08:30:46 +0100 Subject: [Freeipa-users] FreeIPA 4.3.1 ipa-replica-install wrong exit code? In-Reply-To: References: Message-ID: On 23.02.2017 00:17, Diogenes S. Jesus wrote: > We are ansible-playbooking FreeIPA and we don't want to care about if > freeipa is installed, we just want to ignore errors if it already is - > but for that the exit code is relevant. > Either the return code is wrong in the code or in the manual - > according to the manual, it should be 3, but it's currently 1. > > > ubuntu at ipa02:~$ sudo -i > root at ipa02:~# http_proxy='' https_proxy='' ipa-replica-install > --dirsrv-cert-file=/etc/ssl/private/ipa02.dev.pfx > --http-cert-file=/etc/ssl/private/ipa02.dev.pfx --dirsrv-pin=export > --http-pin=export > ipa.ipapython.install.cli.install_tool(Replica): ERROR IPA server is > already configured on this system. > If you want to reinstall the IPA server, please uninstall it first > using 'ipa-server-install --uninstall'. > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > root at ipa02:~# echo $? > 1 > > root at ipa02:~# cat /var/log/ipareplica-install.log > 2017-02-22T22:49:45Z DEBUG Logging to /var/log/ipareplica-install.log > 2017-02-22T22:49:45Z DEBUG ipa-replica-install was invoked with > arguments [] and options: {'no_dns_sshfp': None, 'skip_schema_check': > None, 'setup_kra': None, 'ip_addresses': None, 'mkhomedir': None, > 'no_pkinit': None, 'http_cert_files': > ['/etc/ssl/private/ipa02.dev.pfx'], 'no_ntp': None, 'verbose': False, > 'no_forwarders': None, 'keytab': None, 'ssh_trust_dns': None, > 'domain_name': None, 'http_cert_name': None, 'dirsrv_cert_files': > ['/etc/ssl/private/ipa02.dev.pfx'], 'no_dnssec_validation': None, > 'no_reverse': None, 'pkinit_cert_files': None, 'unattended': False, > 'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, > 'no_sshd': None, 'no_ui_redirect': None, 'dirsrv_config_file': None, > 'forwarders': None, 'pkinit_cert_name': None, 'setup_ca': None, > 'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, > 'dirsrv_cert_name': None, 'quiet': False, 'server': None, 'setup_dns': > None, 'host_name': None, 'log_file': None, 'reverse_zones': None, > 'allow_zone_overlap': None} > 2017-02-22T22:49:45Z DEBUG IPA version 4.3.1 > 2017-02-22T22:49:45Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2017-02-22T22:49:45Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2017-02-22T22:49:45Z DEBUG httpd is configured > 2017-02-22T22:49:45Z DEBUG kadmin is configured > 2017-02-22T22:49:45Z DEBUG dirsrv is configured > 2017-02-22T22:49:45Z DEBUG pki-tomcatd is not configured > 2017-02-22T22:49:45Z DEBUG install is not configured > 2017-02-22T22:49:45Z DEBUG krb5kdc is configured > 2017-02-22T22:49:45Z DEBUG ntpd is configured > 2017-02-22T22:49:45Z DEBUG named is not configured > 2017-02-22T22:49:45Z DEBUG ipa_memcached is configured > 2017-02-22T22:49:45Z DEBUG filestore has files > 2017-02-22T22:49:45Z DEBUG File > "/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 171, > in execute > return_value = self.run() > File "/usr/lib/python2.7/dist-packages/ipapython/install/cli.py", > line 318, in run > cfgr.run() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 308, in run > self.validate() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 317, in validate > for nothing in self._validator(): > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 564, in _configure > next(validator) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/dist-packages/ipapython/install/common.py", > line 63, in _install > for nothing in self._installer(self.parent): > File > "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", > line 1650, in main > promote_check(self) > File > "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", > line 375, in decorated > func(installer) > File > "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", > line 397, in decorated > func(installer) > File > "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", > line 952, in promote_check > sys.exit("IPA server is already configured on this system.\n" > > 2017-02-22T22:49:45Z DEBUG The ipa-replica-install command failed, > exception: SystemExit: IPA server is already configured on this system. > If you want to reinstall the IPA server, please uninstall it first > using 'ipa-server-install --uninstall'. > 2017-02-22T22:49:45Z ERROR IPA server is already configured on this > system. > If you want to reinstall the IPA server, please uninstall it first > using 'ipa-server-install --uninstall'. > 2017-02-22T22:49:45Z ERROR The ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > ------ > > For those looking for a workaround meanwhile do: > > python -c 'import sys; from ipaserver.install.installutils import > is_ipa_configured; sys.exit(is_ipa_configured())' > > > As proposed here: https://fedorahosted.org/freeipa/ticket/4884 > > > Dio > > Hello, return code 1 is expected for already installed server. Return code 3 on replica is somehow special it doesn't mean that replica is already installed but more or less issues that may happen during replica installation. If you think that we should return an extra return code for "IPA already installed", please file a RFE ticket. https://fedorahosted.org/freeipa/newticket Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Feb 23 08:17:18 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Feb 2017 09:17:18 +0100 Subject: [Freeipa-users] authenticating with dns In-Reply-To: References: Message-ID: On 22.02.2017 23:26, Aaron Young wrote: > Hello Everyone > > I recently lost the master master IPA server setup by the previous > administrator. > As it stands now, if I try to add a new client, in order to standup a > new replica, I get errors while trying to setup DNS. This led me to > look at how authentication worked (I'm new to IPA) and I learned about > the kerberos tools > > I don't know if I'm familiar enough with the terminology to adequately > describe what I'm experiencing, so I'll give you some of the commands > and their results > > but first, a bit on the design > > before I got to this, we had > > a <-> b <-> c <-> d > > b was the master master > > a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 > (not pictured, I discovered them later when c and d started having > problems) > > a - nyc01ipa02 > b - nyc01ipa01 > c - ld4ipa01 > d - ld4ipa02 > > currently, I have nyc02ipa02 <-> nyc01ipa02 > the reason I have it limited like this is because all the other > servers stopped replicating for one reason or another (mainly that > they can't authenticate or in one case, there was a database record > corruption) > Anyway, here are some activities and logs from the latest round of > fixes and information activities I've been engaging in > > 22:54:32 root at nyc01ipa02:~# kinit admin > kinit: Clients credentials have been revoked while getting initial > credentials > > Reading through this > tells > me that > > # kadmin: modprinc -unlock PRINCNAME > > will unlock an account...but if I can't get in.... > > 22:54:37 root at nyc01ipa02:~# kadmin > Authenticating as principal root/admin at MF with password. > kadmin: Client 'root/admin at MF' not found in Kerberos database > while initializing kadmin interface > > on ld4ipa02, did a > > # ipa-client-install --uninstall > > then > > # ipa-client-install --force-join --enable-dns-updates --permit -f > --ssh-trust-dns --request-cert --automount-location=LD4 > --enable-dns-updates > > DNS did not update, here is the relevant portion from > /var/log/ipaclient-install.log > > 2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt: > 2017-02-20T18:46:49Z DEBUG debug > > update delete ld4ipa02.mf. IN A > show > send > > update delete ld4ipa02.mf. IN AAAA > show > send > > update add ld4ipa02.mf. 1200 IN A 10.102.100.140 > show > send > > 2017-02-20T18:46:49Z DEBUG Starting external process > 2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > 2017-02-20T18:46:49Z DEBUG Process finished, return code=1 > 2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 > ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 > ;; UPDATE SECTION: > ld4ipa02.mf. 0 ANY A > > 2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702 > ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;ld4ipa02.mf. IN SOA > > ;; AUTHORITY SECTION: > mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600 > > Found zone name: mf > The master is: ld4ipa01.mf > start_gssrequest > tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ld4ipa01.mf at MF not found in Kerberos database. > > 2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 > 2017-02-20T18:46:49Z ERROR Failed to update DNS records. > 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A > 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. > 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN AAAA > 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. > 2017-02-20T18:46:49Z DEBUG DNS resolver: Query:140.100.102.10.in-addr.arpa . IN PTR > 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. > 2017-02-20T18:46:49Z WARNING Missing A/AAAA record(s) for host ld4ipa02.mf: 10.102.100.140. > 2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 10.102.100.140. > > Why isn't there an entry for "DNS/ld4ipa01.mf at MF" in the Kerberos > database? > > klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns > > Keytab name: FILE:/etc/dirsrv/ds.keytab > > KVNO Timestamp Principal > ---- ------------------- > ------------------------------------------------------ > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF > (0x696a502bc73d209acdd36c42242f7f8aff9dbba1073b34ea018ed3bd9cdfd970) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF > (0xe031464b6948ea34f4291d40fca7a21e) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF > (0xe94a1c98fe79b6317901435d9e9e0257cefe438ff2ec527f) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF > (0x6aaf4c7fa6b51b9de032b7c6428307b5) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF > (0x5e0702f44aef9e0633e09eede7ca8041) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF > (0x6e3a9d29ee3f129a156ae6228ab7728df8ce5de923a61eba6a2e7802b8d230b6) > > > Tried to test connectivity using ldapsearch found that I could > connect to other hosts on 389 but not 636 > > # ldapsearch -Hldap://nyc02ipa02:389 -D "cn=directory manager" -W -b "" -s base > > # ldapsearch -Hldaps://nyc02ipa02:686 -D "cn=directory manager" -W -b "" -s base > > Testing the kvno > > 02:10:00 root at ld4ipa01:~# kvno DNS/ld4ipa01.mf at MF > DNS/ld4ipa01.mf at MF: kvno = 2 > > 02:10:52 root at ld4ipa02:~# kvno DNS/ld4ipa01.mf at MF > kvno: Server DNS/ld4ipa01.mf at MF not found in Kerberos database > while getting credentials for DNS/ld4ipa01.mf at MF > > Add this to any command line to get debug on kerberos commands > > KRB5_TRACE=/dev/stdout kvno DNS/ld4ipa01.mf at MF > > So, looking at the debug > kvno from ld4ipa02, does not return tickets. It does this because it > contacts the KDC which is nyc02ipa02, and nyc02ipa02 does not > recognize ldipa02 as an IPA server. It doesn't recognize ld4ipa01 either. > > right now, if I try to connect nyc02ipa02 to ld4ipa01 I get > > 21:56:27 root at nyc02ipa02:~# ipa topologysegment-add domain > ld4ipa01-to-nyc02ipa02 --leftnode ld4ipa01.mf --rightnode > nyc02ipa02.mf > ipa: ERROR: invalid 'leftnode': left node is not a topology node: > ld4ipa01.mf > > ipa privilege-show 'DNS Servers' --all --raw > dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=mf > cn: DNS Servers > description: DNS Servers > member: krbprincipalname=DNS/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=ipa-dnskeysyncd/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=DNS/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=ipa-dnskeysyncd/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=ipa-ods-exporter/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf > memberof: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=mf > objectClass: top > objectClass: groupofnames > objectClass: nestedgroup > > -- > Aaron Young > MarketFactory, Manager of Site Reliability Engineering > 425 Broadway, 3FL > New York, NY 10013 > Office: +1 212 625 9988 > Direct +1 646 779 3710 > US Support: +1 (212) 625-0688 | UK > Support: +44 (0) 203 695-7997 > > Hello, please don't use kadmin utility, it is not integrated very well with IPA (or unsupported is a better word) and may break it even more. It looks that you have corrupted kerberos credentials for id4ipa01 I see you are installing client on id4ipa01, was IPA server removed properly previosly? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Thu Feb 23 08:25:18 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Thu, 23 Feb 2017 09:25:18 +0100 Subject: [Freeipa-users] FreeIPA 4.3.1 ipa-replica-install wrong exit code? In-Reply-To: References: Message-ID: <46ab1959-1913-52fb-66f3-f379cf7dde85@redhat.com> On 02/23/2017 08:30 AM, Martin Basti wrote: > > On 23.02.2017 00:17, Diogenes S. Jesus wrote: >> We are ansible-playbooking FreeIPA and we don't want to care about if >> freeipa is installed, we just want to ignore errors if it already is >> - but for that the exit code is relevant. >> Either the return code is wrong in the code or in the manual - >> according to the manual, it should be 3, but it's currently 1. >> >> >> ubuntu at ipa02:~$ sudo -i >> root at ipa02:~# http_proxy='' https_proxy='' ipa-replica-install >> --dirsrv-cert-file=/etc/ssl/private/ipa02.dev.pfx >> --http-cert-file=/etc/ssl/private/ipa02.dev.pfx --dirsrv-pin=export >> --http-pin=export >> ipa.ipapython.install.cli.install_tool(Replica): ERROR IPA server is >> already configured on this system. >> If you want to reinstall the IPA server, please uninstall it first >> using 'ipa-server-install --uninstall'. >> ipa.ipapython.install.cli.install_tool(Replica): ERROR The >> ipa-replica-install command failed. See >> /var/log/ipareplica-install.log for more information >> >> root at ipa02:~# echo $? >> 1 >> >> root at ipa02:~# cat /var/log/ipareplica-install.log >> 2017-02-22T22:49:45Z DEBUG Logging to /var/log/ipareplica-install.log >> 2017-02-22T22:49:45Z DEBUG ipa-replica-install was invoked with >> arguments [] and options: {'no_dns_sshfp': None, 'skip_schema_check': >> None, 'setup_kra': None, 'ip_addresses': None, 'mkhomedir': None, >> 'no_pkinit': None, 'http_cert_files': >> ['/etc/ssl/private/ipa02.dev.pfx'], 'no_ntp': None, 'verbose': False, >> 'no_forwarders': None, 'keytab': None, 'ssh_trust_dns': None, >> 'domain_name': None, 'http_cert_name': None, 'dirsrv_cert_files': >> ['/etc/ssl/private/ipa02.dev.pfx'], 'no_dnssec_validation': None, >> 'no_reverse': None, 'pkinit_cert_files': None, 'unattended': False, >> 'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, >> 'no_sshd': None, 'no_ui_redirect': None, 'dirsrv_config_file': None, >> 'forwarders': None, 'pkinit_cert_name': None, 'setup_ca': None, >> 'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, >> 'dirsrv_cert_name': None, 'quiet': False, 'server': None, >> 'setup_dns': None, 'host_name': None, 'log_file': None, >> 'reverse_zones': None, 'allow_zone_overlap': None} >> 2017-02-22T22:49:45Z DEBUG IPA version 4.3.1 >> 2017-02-22T22:49:45Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2017-02-22T22:49:45Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2017-02-22T22:49:45Z DEBUG httpd is configured >> 2017-02-22T22:49:45Z DEBUG kadmin is configured >> 2017-02-22T22:49:45Z DEBUG dirsrv is configured >> 2017-02-22T22:49:45Z DEBUG pki-tomcatd is not configured >> 2017-02-22T22:49:45Z DEBUG install is not configured >> 2017-02-22T22:49:45Z DEBUG krb5kdc is configured >> 2017-02-22T22:49:45Z DEBUG ntpd is configured >> 2017-02-22T22:49:45Z DEBUG named is not configured >> 2017-02-22T22:49:45Z DEBUG ipa_memcached is configured >> 2017-02-22T22:49:45Z DEBUG filestore has files >> 2017-02-22T22:49:45Z DEBUG File >> "/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 171, >> in execute >> return_value = self.run() >> File "/usr/lib/python2.7/dist-packages/ipapython/install/cli.py", >> line 318, in run >> cfgr.run() >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 308, in run >> self.validate() >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 317, in validate >> for nothing in self._validator(): >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 372, in __runner >> self._handle_exception(exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 394, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 362, in __runner >> step() >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 359, in >> step = lambda: next(self.__gen) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", >> line 81, in run_generator_with_yield_from >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", >> line 59, in run_generator_with_yield_from >> value = gen.send(prev_value) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 564, in _configure >> next(validator) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 372, in __runner >> self._handle_exception(exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 449, in _handle_exception >> self.__parent._handle_exception(exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 394, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 446, in _handle_exception >> super(ComponentBase, self)._handle_exception(exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 394, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 362, in __runner >> step() >> File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", >> line 359, in >> step = lambda: next(self.__gen) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", >> line 81, in run_generator_with_yield_from >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", >> line 59, in run_generator_with_yield_from >> value = gen.send(prev_value) >> File >> "/usr/lib/python2.7/dist-packages/ipapython/install/common.py", line >> 63, in _install >> for nothing in self._installer(self.parent): >> File >> "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", >> line 1650, in main >> promote_check(self) >> File >> "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", >> line 375, in decorated >> func(installer) >> File >> "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", >> line 397, in decorated >> func(installer) >> File >> "/usr/lib/python2.7/dist-packages/ipaserver/install/server/replicainstall.py", >> line 952, in promote_check >> sys.exit("IPA server is already configured on this system.\n" >> >> 2017-02-22T22:49:45Z DEBUG The ipa-replica-install command failed, >> exception: SystemExit: IPA server is already configured on this system. >> If you want to reinstall the IPA server, please uninstall it first >> using 'ipa-server-install --uninstall'. >> 2017-02-22T22:49:45Z ERROR IPA server is already configured on this >> system. >> If you want to reinstall the IPA server, please uninstall it first >> using 'ipa-server-install --uninstall'. >> 2017-02-22T22:49:45Z ERROR The ipa-replica-install command failed. >> See /var/log/ipareplica-install.log for more information >> >> ------ >> >> For those looking for a workaround meanwhile do: >> >> python -c 'import sys; from ipaserver.install.installutils import >> is_ipa_configured; sys.exit(is_ipa_configured())' >> >> >> As proposed here: https://fedorahosted.org/freeipa/ticket/4884 >> >> >> Dio >> >> > > > Hello, > > return code 1 is expected for already installed server. Return code 3 > on replica is somehow special it doesn't mean that replica is already > installed but more or less issues that may happen during replica > installation. > > If you think that we should return an extra return code for "IPA > already installed", please file a RFE ticket. > https://fedorahosted.org/freeipa/newticket > > Martin > > > > Hello, Thank you for raising your concern. The documentation there is quite puzzling from what I see, it should say that 3 is returned when the host with such a hostname already exists in the topology or when the remote server has a replication agreement to this host (the doc is completely wrong there). This does not imply replica is already installed on the given server. While I was going through the code, I found quite some more cases where 3 would be returned. So my advice is - check whether the returned value is not 0. I believe we should deprecate rval 3 as it is bound to only cause more confusion. If the installation failed, you need to go checking the logs anyway, right? HTH, Standa -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Feb 23 08:46:06 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Feb 2017 09:46:06 +0100 Subject: [Freeipa-users] Recommended approach to VM snapshot prior to upgrade In-Reply-To: References: Message-ID: <0c44704a-4f8e-bc9d-7b24-af2c6057303b@redhat.com> On 23.02.2017 00:47, Brian Mathis wrote: > I have a 3-node cluster running FreeIPA 4.2 on RHEL 7.2. I would like > to upgrade to RHEL 7.3 / IPA 4.4, and I want to make VM snapshots that > I can rollback to in case there are issues. What is the recommended > approach to this? > > Should services already be started when running the yum update? It doesn't matter, updater will stop/start services as needed > > Can I shut down each ipa service one by one, snapshot, then upgrade? > How would replication be affected if I had to rollback to the older > snapshot after other nodes had been upgraded? You have to rollback all snapshots for the whole topology and then you can start IPA, otherwise replication conflicts may happen. So I suggest to have snapshots of all servers before upgrade. > > Or is it better to shut down all ipa services on all nodes, make > snapshots, then perform the upgrade? Obviously that would bring down > the domain during the upgrade, but it would better ensure integrity. This is the best for integrity, but in case there is no/low activity on servers, then one by one snapshots may work too. > > Thanks, > > ~ Brian Mathis > @orev > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ente.trompete at protonmail.com Thu Feb 23 09:17:27 2017 From: ente.trompete at protonmail.com (Ente Trompete) Date: Thu, 23 Feb 2017 04:17:27 -0500 Subject: [Freeipa-users] FreeIPA Fedora 25 and IPA CentOS 7.3 In-Reply-To: <20170222202444.GC4758@10.4.128.1> References: <20170222105945.kpue4rdllzcjtjlp@redhat.com> <20170222202444.GC4758@10.4.128.1> Message-ID: <8-ihPWSy996oxn4S2q0pAl69S2jAdCBvROUaLCy7TEzYgkkVkart4QJKV6HPnljwjakk4Yef8wG5ZuMe9b0l4Wuo7khL9Gstpk1xOyO1WiA=@protonmail.com> Hi, THX for your answer but as you can see in your test, you get freeipa-server 4.4.3 installed and if you follow the link offered by Alexander Red Hat/CentOS uses another versioning as the FreeIPA project contained in Fedora. So to create a replica with freeipa-server 4.4.3 from a CentOS ipa-server 4.4.0- can work but must not. And with any patching of CentOS and/or Fedora new problems can appear. I must either switch also the primary replica to FreeIPA (Fedora) or can?t use ARM based computer for the second. Maybe a Gigabyte BRIX is a got alternative. Of course really more expensive and the Banna PI was then bought for the trash, maybe I can install Android and use it as TV box ;-). Br, Silvio Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- There is not any problem to install ipa-server on fedora. There are provides. sh# cat /etc/os-release NAME=Fedora ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Thu Feb 23 09:21:32 2017 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 23 Feb 2017 11:21:32 +0200 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! In-Reply-To: <05b2653c-9d75-b45a-12f5-a64b6c652029@0xc0dedbad.com> References: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> <49e4b790-0288-2fa1-b5c3-bf0483d5757d@redhat.com> <05b2653c-9d75-b45a-12f5-a64b6c652029@0xc0dedbad.com> Message-ID: On 23.02.2017 02:04, Peter Fern wrote: > On 23/02/17 05:26, Rob Crittenden wrote: >> It's been many moons since I worked on nss-pem but from what I can tell >> it should be buildable outside of NSS so can ship as a separate package. >> You might try building it locally to see if it resolves the issues for >> you. It resides at https://github.com/kdudka/nss-pem > > I had to modify an include path, and it links against some static libs > (libfreebl.a, libnssb.a, libnssckfw.a) that are not included in the > current Debian libnss3 packages, so a non-trivial packaging effort. And > because certmonger appears to use nss directly, linking against a > different libcurl variant is also probably not an option. > > There are other issues too - the default cert store path of > /etc/httpd/alias is still used in the deb package, however the correct > path is /etc/apache2/nssdb. Good stuff, neatly hardcoded in src/dogtag.c. Thanks for pointing this out, I'll get that fixed at least.. And as you noticed, packaging nss-pem is not a trivial task because of the way it uses private NSS api's that the libnss maintainer refuses to make public.. OpenSSL, anyone? :P From mbasti at redhat.com Thu Feb 23 09:27:37 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Feb 2017 10:27:37 +0100 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! In-Reply-To: References: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> <49e4b790-0288-2fa1-b5c3-bf0483d5757d@redhat.com> <05b2653c-9d75-b45a-12f5-a64b6c652029@0xc0dedbad.com> Message-ID: <63c68a7b-1c75-95cd-1d5c-0a1d61206d4b@redhat.com> On 23.02.2017 10:21, Timo Aaltonen wrote: > On 23.02.2017 02:04, Peter Fern wrote: >> On 23/02/17 05:26, Rob Crittenden wrote: >>> It's been many moons since I worked on nss-pem but from what I can tell >>> it should be buildable outside of NSS so can ship as a separate package. >>> You might try building it locally to see if it resolves the issues for >>> you. It resides at https://github.com/kdudka/nss-pem >> I had to modify an include path, and it links against some static libs >> (libfreebl.a, libnssb.a, libnssckfw.a) that are not included in the >> current Debian libnss3 packages, so a non-trivial packaging effort. And >> because certmonger appears to use nss directly, linking against a >> different libcurl variant is also probably not an option. >> >> There are other issues too - the default cert store path of >> /etc/httpd/alias is still used in the deb package, however the correct >> path is /etc/apache2/nssdb. > Good stuff, neatly hardcoded in src/dogtag.c. Thanks for pointing this > out, I'll get that fixed at least.. > > And as you noticed, packaging nss-pem is not a trivial task because of > the way it uses private NSS api's that the libnss maintainer refuses to > make public.. OpenSSL, anyone? :P > We are working on it :) in future IPA may need only openssl From iulian.roman at gmail.com Thu Feb 23 11:15:33 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Thu, 23 Feb 2017 12:15:33 +0100 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server In-Reply-To: <430f2a60-3f95-150d-3b42-b2ade5c2ce33@stroeder.com> References: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> <120e6725-3891-6bbd-5ae3-7ad187a872e2@stroeder.com> <430f2a60-3f95-150d-3b42-b2ade5c2ce33@stroeder.com> Message-ID: On Wed, Feb 22, 2017 at 9:02 PM, Michael Str?der wrote: > Iulian Roman wrote: > > On Wed, Feb 22, 2017 at 6:03 PM, Michael Str?der > > wrote: > > > > Iulian Roman wrote: > > > On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden < > rcritten at redhat.com > > > >> wrote: > > > > > > Iulian Roman wrote: > > > > Does anybody know if the rfc2307aix schema is supported in > IPA server > > > > > > No, it isn't supported (it's the first I've ever heard of it). > Looking > > > at the schema I doubt it is something that would ever be fully > supported. > > > > > > is there any possibility to extend the existing schema with > additional > > > attributes/object > > > > Do you really use this specific AIX schema? > > If yes, which attributes for which purpose? > > > > I do need the aixAuxAccount and aixAuxGroup object classes . they > implement some > > password restrictions needed for security/compliance > > Password policy is something best enforced centrally in the authentication > server and > password management system. So IMHO this serves as perfect example for > proprietary > attributes you won't need. > > How is authentication done? SSH keys, Kerberos, LDAP simple bind? > Kerberos > > + some other security related attributes. > > Personally i do not consider them a must - they are rather some nice to > have features - > > but i have to migrate an environment which does use them. And i would > like as well to > > make the migration as transparent as possible (therefore without > "missing features"). > > Is the existing environment also an LDAP server with this particular AIX > schema? > no, it is a custom/legacy solution wich does not use LDAP but local accounts which are centrally managed. > Or are you trying to follow a migration path to LDAP suggested by IBM docs? > > no, i've adapted some freeipa document which describes the client setup for aix (in original form it does not work and it needed some modifications) , but i have to admit that the documentation for integrating unix clients is poor and incomplete . IBM does recommend TDS, which integrates seamlessly with both AIX and Linux clients + other features which should help in integrating in heterogeneous environment, but i am not evaluating that solution currently (i may look into it only if i cannot integrate it with IPA in the way i want). > Being in your position I'd first compile a list of functional and security > requirements > and ask then whether these requirements can be implemented with FreeIPA. > I'm curious to > learn whether "some other security related attributes" are still needed > after all. > > all the password restriction policies (minage, maxage, number of characters in the password, history of the old passwords, number of characters, password dictionaries , etc) , loginretries - which "locks" the account after a number of unsuccessful logins , hostsallow/deny login , all the ulimit related parameters (that can probably be ignored) . It is not a matter if they increase the security or not or if they are really needed, but a matter of complying to some security standards agreed between two parties . It would be easy to keep them in the same format than to change the security standard , tooling and processes behind (bureaucracy , overhead and complexity of the enterprise environment makes me try to avoid that as much as possible , especially when there are many people and departments involved , with their own mindset and playing different politics). Ciao, Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at 0xc0dedbad.com Thu Feb 23 11:40:05 2017 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Thu, 23 Feb 2017 22:40:05 +1100 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! In-Reply-To: <63c68a7b-1c75-95cd-1d5c-0a1d61206d4b@redhat.com> References: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> <49e4b790-0288-2fa1-b5c3-bf0483d5757d@redhat.com> <05b2653c-9d75-b45a-12f5-a64b6c652029@0xc0dedbad.com> <63c68a7b-1c75-95cd-1d5c-0a1d61206d4b@redhat.com> Message-ID: On 23/02/17 20:27, Martin Basti wrote: > On 23.02.2017 10:21, Timo Aaltonen wrote: >> And as you noticed, packaging nss-pem is not a trivial task because of >> the way it uses private NSS api's that the libnss maintainer refuses to >> make public.. OpenSSL, anyone? :P >> > We are working on it :) in future IPA may need only openssl Doesn't this open the GPL/OpenSSL licensing can of worms (for distro != Fedora)? From mbasti at redhat.com Thu Feb 23 11:53:51 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Feb 2017 12:53:51 +0100 Subject: [Freeipa-users] Dogtag certs did not auto-renew, very stuck! In-Reply-To: References: <879f21b6-1168-9aeb-9299-818dfb8d75d3@0xc0dedbad.com> <07aaf4a7-a570-610f-b015-bd0521648769@0xc0dedbad.com> <49e4b790-0288-2fa1-b5c3-bf0483d5757d@redhat.com> <05b2653c-9d75-b45a-12f5-a64b6c652029@0xc0dedbad.com> <63c68a7b-1c75-95cd-1d5c-0a1d61206d4b@redhat.com> Message-ID: <70b62d8e-e21d-a149-5994-060f7ba46fc8@redhat.com> On 23.02.2017 12:40, Peter Fern wrote: > On 23/02/17 20:27, Martin Basti wrote: >> On 23.02.2017 10:21, Timo Aaltonen wrote: >>> And as you noticed, packaging nss-pem is not a trivial task because of >>> the way it uses private NSS api's that the libnss maintainer refuses to >>> make public.. OpenSSL, anyone? :P >>> >> We are working on it :) in future IPA may need only openssl > Doesn't this open the GPL/OpenSSL licensing can of worms (for distro != > Fedora)? IPA already requires OpenSSL so nothing should change. From bpk678 at gmail.com Thu Feb 23 12:51:35 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Thu, 23 Feb 2017 07:51:35 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> Message-ID: <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> On 02/23/2017 07:32 AM, Kees Bakker wrote: > On 22-02-17 17:33, Brendan Kearney wrote: >> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>> On 22-02-17 14:05, Brendan Kearney wrote: >>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>> Hey, >>>>>>> >>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>> >>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>> >>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>> only sees question marks as shown below. >>>>>>> >>>>>>> The mount command is simple. >>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>> >>>>>>> On the server side /etc/exports looks like this. >>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>> >>>>>>> $ sudo mount |grep nfs >>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>> >>>>>>> $ sudo ls -ld /nfshome >>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>> $ sudo ls -l /nfshome >>>>>>> total 0 >>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>> >>>>>>> $ ls -l /nfshome >>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>> $ ls -l / | grep nfshome >>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>> >>>>>> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) >>>>> Thanks for the reply. >>>>> >>>>> In this case the user _is_ authenticated. >>>>> keesb at client1:~$ klist >>>>> Ticket cache: KEYRING:persistent:60001:60001 >>>>> Default principal: keesb at EXAMPLE.COM >>>>> >>>>> Valid starting Expires Service principal >>>>> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>> no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. >>> (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >>> >>>>> What other grants could be needed? HBAC Rules? >>>>> >>>>> Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it >>>>> doesn't help to get access for the user.) >>>> there are principals to create and keytabs to be updated on hte NFS sever, if not done already. >>> I did create a principal for the NFS server (using ipa service-add) and >>> add to the keytab on the NFS server (using ipa-getkeytab) ... >>> root at srv1# klist -ke >>> Keytab name: FILE:/etc/krb5.keytab >>> KVNO Principal >>> ---- -------------------------------------------------------------------------- >>> 1 host/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>> 1 host/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>> >>> Is this what you mean? >> yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? > I don't think that a change of idmapd.conf (on the NFS server) is needed because all host > names are FQDN and everything is in one and the same REALM. NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. > >>>> then the user should be able to pull the ticket for auth. >>> Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? >>> >>> keesb at client1$ kinit nfs/srv1.example.com at EXAMPLE.COM >>> Password for nfs/srv1.example.com at EXAMPLE.COM: >>> >>> But I don't have a password for that. Hmm. >> there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. > OK > So, it seems to me that all the basics are setup correctly. The mount succeeds. The user > has a TGT and still the (non-root) user cannot even stat the mount point, nor the directory > entry itself. > > What puzzles me is that root can see everything, also without a TGT. the mount will succeed, but the user does not have access because NFS does not know who the user it. it has an unassociated ID established by kerberos, but not a user. > >>>>> Furthermore, I'm guessing that the host principle which I got after ipa-client-install is >>>>> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I >>>>> did not do.) >>>>> # klist -ke >>>>> Keytab name: FILE:/etc/krb5.keytab >>>>> KVNO Principal >>>>> ---- -------------------------------------------------------------------------- >>>>> 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>> 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>> >>>>> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>>>> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ >>>> http://www.itp.uzh.ch/~dpotter/howto/kerberos >>>> added the thread back to the mailing list for the benefit of any who search on the subject. From iulian.roman at gmail.com Thu Feb 23 14:07:20 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Thu, 23 Feb 2017 15:07:20 +0100 Subject: [Freeipa-users] integrated DNS vs external DNS Message-ID: Despite reading the freeipa and Redhat IdM documentation regarding the DNS , it is still unclear to me if and when is integrated DNS mandatory . We do have an environment with a pretty complex DNS setup , which is in place for years and there are no plans to change it. if i understood correctly from the documentation , integrated DNS is mandatory for configuring AD trust. is that correct ? Can the integrated DNS be configured as forward only ? Do the clients need to have IPA DNS as a resolver or they can just use existing DNS server ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From keesb at ghs.com Thu Feb 23 14:11:30 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 23 Feb 2017 15:11:30 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> Message-ID: <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> On 23-02-17 13:51, Brendan Kearney wrote: > On 02/23/2017 07:32 AM, Kees Bakker wrote: >> On 22-02-17 17:33, Brendan Kearney wrote: >>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>> Hey, >>>>>>>> >>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>> >>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>> >>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>> only sees question marks as shown below. >>>>>>>> >>>>>>>> The mount command is simple. >>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>> >>>>>>>> On the server side /etc/exports looks like this. >>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>> >>>>>>>> $ sudo mount |grep nfs >>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>> >>>>>>>> $ sudo ls -ld /nfshome >>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>> $ sudo ls -l /nfshome >>>>>>>> total 0 >>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>> >>>>>>>> $ ls -l /nfshome >>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>> $ ls -l / | grep nfshome >>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>> >>>>>>> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) >>>>>> Thanks for the reply. >>>>>> >>>>>> In this case the user _is_ authenticated. >>>>>> keesb at client1:~$ klist >>>>>> Ticket cache: KEYRING:persistent:60001:60001 >>>>>> Default principal: keesb at EXAMPLE.COM >>>>>> >>>>>> Valid starting Expires Service principal >>>>>> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>> no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. >>>> (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >>>> >>>>>> What other grants could be needed? HBAC Rules? >>>>>> >>>>>> Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it >>>>>> doesn't help to get access for the user.) >>>>> there are principals to create and keytabs to be updated on hte NFS sever, if not done already. >>>> I did create a principal for the NFS server (using ipa service-add) and >>>> add to the keytab on the NFS server (using ipa-getkeytab) ... >>>> root at srv1# klist -ke >>>> Keytab name: FILE:/etc/krb5.keytab >>>> KVNO Principal >>>> ---- -------------------------------------------------------------------------- >>>> 1 host/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>> 1 host/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>> >>>> Is this what you mean? >>> yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? >> I don't think that a change of idmapd.conf (on the NFS server) is needed because all host >> names are FQDN and everything is in one and the same REALM. > NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. Both the NFS server and the client are configured as FreeIPA client. On the server the users are known (through PAM, SSSD). Only user "ubuntu" is a local (/etc/passwd) user. All other users are defined on the IPA server. root at srv1:~# ls -l /home total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu root at srv1:~# ls -ln /home total 0 drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu On the client, same story root at client1:~# ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu root at client1:~# ls -ln /nfshome total 0 drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu >> >>>>> then the user should be able to pull the ticket for auth. >>>> Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? >>>> >>>> keesb at client1$ kinit nfs/srv1.example.com at EXAMPLE.COM >>>> Password for nfs/srv1.example.com at EXAMPLE.COM: >>>> >>>> But I don't have a password for that. Hmm. >>> there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. >> OK >> So, it seems to me that all the basics are setup correctly. The mount succeeds. The user >> has a TGT and still the (non-root) user cannot even stat the mount point, nor the directory >> entry itself. >> >> What puzzles me is that root can see everything, also without a TGT. > the mount will succeed, but the user does not have access because NFS does not know who the user it. it has an unassociated ID established by kerberos, but not a user. Let's step back a little. On the NFS client, the user does an ls of / (that's where the mountpoint is). At the point where ls reads the entry (through stat) for "nfshome" it gets (probably) EPERM. And hence ls prints all the question marks. That leads me to believe that only the kernel (on the NFS client) is involved at this point. I could be wrong but I don't think there is any kerberos TGT involved. >> >>>>>> Furthermore, I'm guessing that the host principle which I got after ipa-client-install is >>>>>> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I >>>>>> did not do.) >>>>>> # klist -ke >>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>> KVNO Principal >>>>>> ---- -------------------------------------------------------------------------- >>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>> >>>>>> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>>>>> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ >>>>> http://www.itp.uzh.ch/~dpotter/howto/kerberos >>>>> > added the thread back to the mailing list for the benefit of any who search on the subject. > > From bpk678 at gmail.com Thu Feb 23 14:39:10 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Thu, 23 Feb 2017 09:39:10 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> Message-ID: <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> On 02/23/2017 09:11 AM, Kees Bakker wrote: > On 23-02-17 13:51, Brendan Kearney wrote: >> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>> On 22-02-17 17:33, Brendan Kearney wrote: >>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>> Hey, >>>>>>>>> >>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>> >>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>> >>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>> only sees question marks as shown below. >>>>>>>>> >>>>>>>>> The mount command is simple. >>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>> >>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>> >>>>>>>>> $ sudo mount |grep nfs >>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>> >>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>> total 0 >>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>> >>>>>>>>> $ ls -l /nfshome >>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>> >>>>>>>> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) >>>>>>> Thanks for the reply. >>>>>>> >>>>>>> In this case the user _is_ authenticated. >>>>>>> keesb at client1:~$ klist >>>>>>> Ticket cache: KEYRING:persistent:60001:60001 >>>>>>> Default principal: keesb at EXAMPLE.COM >>>>>>> >>>>>>> Valid starting Expires Service principal >>>>>>> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>>> no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. >>>>> (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >>>>> >>>>>>> What other grants could be needed? HBAC Rules? >>>>>>> >>>>>>> Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it >>>>>>> doesn't help to get access for the user.) >>>>>> there are principals to create and keytabs to be updated on hte NFS sever, if not done already. >>>>> I did create a principal for the NFS server (using ipa service-add) and >>>>> add to the keytab on the NFS server (using ipa-getkeytab) ... >>>>> root at srv1# klist -ke >>>>> Keytab name: FILE:/etc/krb5.keytab >>>>> KVNO Principal >>>>> ---- -------------------------------------------------------------------------- >>>>> 1 host/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>> 1 host/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>> >>>>> Is this what you mean? >>>> yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? >>> I don't think that a change of idmapd.conf (on the NFS server) is needed because all host >>> names are FQDN and everything is in one and the same REALM. >> NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. > Both the NFS server and the client are configured as FreeIPA client. > On the server the users are known (through PAM, SSSD). Only user > "ubuntu" is a local (/etc/passwd) user. All other users are defined on > the IPA server. > > root at srv1:~# ls -l /home > total 0 > drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb > drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu > root at srv1:~# ls -ln /home > total 0 > drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb > drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu > > On the client, same story > > root at client1:~# ls -l /nfshome > total 0 > drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb > drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu > root at client1:~# ls -ln /nfshome > total 0 > drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb > drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu > > > >>>>>> then the user should be able to pull the ticket for auth. >>>>> Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? >>>>> >>>>> keesb at client1$ kinit nfs/srv1.example.com at EXAMPLE.COM >>>>> Password for nfs/srv1.example.com at EXAMPLE.COM: >>>>> >>>>> But I don't have a password for that. Hmm. >>>> there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. >>> OK >>> So, it seems to me that all the basics are setup correctly. The mount succeeds. The user >>> has a TGT and still the (non-root) user cannot even stat the mount point, nor the directory >>> entry itself. >>> >>> What puzzles me is that root can see everything, also without a TGT. >> the mount will succeed, but the user does not have access because NFS does not know who the user it. it has an unassociated ID established by kerberos, but not a user. > Let's step back a little. > > On the NFS client, the user does an ls of / (that's where the mountpoint is). At the point > where ls reads the entry (through stat) for "nfshome" it gets (probably) EPERM. > And hence ls prints all the question marks. That leads me to believe that only the kernel > (on the NFS client) is involved at this point. I could be wrong but I don't think there is > any kerberos TGT involved. > >>>>>>> Furthermore, I'm guessing that the host principle which I got after ipa-client-install is >>>>>>> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I >>>>>>> did not do.) >>>>>>> # klist -ke >>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>> KVNO Principal >>>>>>> ---- -------------------------------------------------------------------------- >>>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>> >>>>>>> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>>>>>> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ >>>>>> http://www.itp.uzh.ch/~dpotter/howto/kerberos >>>>>> >> added the thread back to the mailing list for the benefit of any who search on the subject. >> >> run journalctl -fl on both the NFS server and the NFS client while trying to mount the share. one of them should tell you something. the mount operation will succeed, because any ACL set in the exports file is being met. root likley has access because the uid/gid is common and local on both devices and therefore no mapping is needed. your virtual user does not exist in either local user store, and therefore needs to be mapped. what does /etc/nsswitch.conf say for passwd, shadow and group? From Steven.Auerbach at flbog.edu Thu Feb 23 14:43:44 2017 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Thu, 23 Feb 2017 14:43:44 +0000 Subject: [Freeipa-users] sudo NOPASSWD for a single command In-Reply-To: <1351947637.1781.1487782715833.JavaMail.zimbra@tresgeek.net> References: <1351947637.1781.1487782715833.JavaMail.zimbra@tresgeek.net> Message-ID: Yes, I implemented in Policy -> Sudo -> Sudo Commands as: Sudo Command: NOPASSWD: /sbin/vgs The script (executed by a non-root, administrative group user on an enrolled host) specifies: ?. hostname >> statresults.txt cat /etc/redhat-release >> statresults.txt uname -r >> statresults.txt printf "\n " >> statresults.txt sudo vgs >> statresults.txt ?.. Running the script I still was prompted for a password. So I guess this does not work. From: Jason B. Nance [mailto:jason at tresgeek.net] Sent: Wednesday, February 22, 2017 11:59 AM To: Auerbach, Steven Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] sudo NOPASSWD for a single command We have a script stored on a particular server in our realm that executes a number of non-privileged commands and are wanting to add /sbin/vgs command. The script uses SSH to then execute the same set of commands on all the servers in the realm. The owner of the script is in the administrator group and there are sudoer commands for the administrator group in general. We need to place a rule for this one command for either this group or the script owner to run NOPASSWD. Where and how would I specify that in the IPA admin console? Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> Sudo -> Sudo Commands)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 23 14:52:29 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Feb 2017 09:52:29 -0500 Subject: [Freeipa-users] Recommended approach to VM snapshot prior to upgrade In-Reply-To: <0c44704a-4f8e-bc9d-7b24-af2c6057303b@redhat.com> References: <0c44704a-4f8e-bc9d-7b24-af2c6057303b@redhat.com> Message-ID: <33eff6a5-3059-fbd4-26ae-3d1b44cee2a1@redhat.com> Martin Basti wrote: > > > On 23.02.2017 00:47, Brian Mathis wrote: >> I have a 3-node cluster running FreeIPA 4.2 on RHEL 7.2. I would like >> to upgrade to RHEL 7.3 / IPA 4.4, and I want to make VM snapshots that >> I can rollback to in case there are issues. What is the recommended >> approach to this? >> >> Should services already be started when running the yum update? > It doesn't matter, updater will stop/start services as needed > >> >> Can I shut down each ipa service one by one, snapshot, then upgrade? >> How would replication be affected if I had to rollback to the older >> snapshot after other nodes had been upgraded? > You have to rollback all snapshots for the whole topology and then you > can start IPA, otherwise replication conflicts may happen. > So I suggest to have snapshots of all servers before upgrade. >> >> Or is it better to shut down all ipa services on all nodes, make >> snapshots, then perform the upgrade? Obviously that would bring down >> the domain during the upgrade, but it would better ensure integrity. > This is the best for integrity, but in case there is no/low activity on > servers, then one by one snapshots may work too. I prefer the shut them all down method if you want a way to get back to the pre-upgraded state. Updating one of the masters is going to replicate out a bunch of changes, so if something goes wrong and you restore that snapshot those updates have already been replicated out. Would this cause problems? Ideally no, but you wouldn't have the pre-upgrade systems either. rob From bpk678 at gmail.com Thu Feb 23 14:53:07 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Thu, 23 Feb 2017 09:53:07 -0500 Subject: [Freeipa-users] sudo NOPASSWD for a single command In-Reply-To: References: <1351947637.1781.1487782715833.JavaMail.zimbra@tresgeek.net> Message-ID: <64e39f67-399d-a9a7-86d2-57b880b2d804@gmail.com> On 02/23/2017 09:43 AM, Auerbach, Steven wrote: > sudo vgs >> statresults.txt should be sudo /sbin/vgs >> statresults.txt since that is what sudo allows. its almost like exact match for strings. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Feb 23 15:21:34 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Feb 2017 16:21:34 +0100 Subject: [Freeipa-users] integrated DNS vs external DNS In-Reply-To: References: Message-ID: <6350025c-c979-3818-7fec-3da351ada626@redhat.com> Hello, comments inline On 23.02.2017 15:07, Iulian Roman wrote: > Despite reading the freeipa and Redhat IdM documentation regarding the > DNS , it is still unclear to me if and when is integrated DNS > mandatory . We do have an environment with a pretty complex DNS setup > , which is in place for years and there are no plans to change it. Integrated DNS is not mandatory at all. Without IPA DNS you have to manage all IPA system records manually on external DNS > > if i understood correctly from the documentation , integrated DNS is > mandatory for configuring AD trust. is that correct ? No, it is not needed for AD trust, you need to add additional DNS records > > Can the integrated DNS be configured as forward only ? Do the clients > need to have IPA DNS as a resolver or they can just use existing DNS > server ? You don't need to install IPA DNS. All records the IPA needs can be received from command `ipa dns-update-system-records --dry-run` (IPA4.4+) > > > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxguru.co at gmail.com Thu Feb 23 15:38:40 2017 From: linuxguru.co at gmail.com (Devin Acosta) Date: Thu, 23 Feb 2017 08:38:40 -0700 Subject: [Freeipa-users] FreeIPA 4.4 / Winsync issues. Message-ID: I have installed a new replica in our IPA domain and configured it to do a winsync with Windows 2012R2. It creates the agreement but then after a while it dies. It appears something isn't configured just right. The Windows client is using the passync user on my side, and i'm creating the sync using a windows account that has the appopriate permissions. This is what I see after about 10 minutes of the sync running from the server side. [22/Feb/2017:23:43:33.103632587 +0000] agmt="cn= meTolas01-050-005.axi.mtech.int" (las01-050-005:389) - Can't locate CSN 58ae2255000000180000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [22/Feb/2017:23:43:33.105866800 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389): CSN 58ae2255000000180000 not found, we aren't as up to date, or we purged [22/Feb/2017:23:43:33.107971862 +0000] NSMMReplicationPlugin - windows sync - agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389): Data required to update replica has been purged. The replica must be reinitialized. [22/Feb/2017:23:43:33.109455154 +0000] NSMMReplicationPlugin - windows sync - agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389): Incremental update failed and requires administrator action On the Windows Side, we show either DSA is unwilling to perform, or Insufficient access. We are using the passsync user that was created during the sync. 02/21/17 15:25:20: PassSync service initialized 02/21/17 15:25:20: PassSync service running 02/21/17 15:25:20: dataFilename is C:\Windows\System32\passhook.dat 02/21/17 15:25:20: 1 new entries loaded from data file 02/21/17 15:25:20: Cleared contents of data file 02/21/17 15:25:20: Password list has 1 entries 02/21/17 15:25:20: Ldap bind error in Connect 53: DSA is unwilling to perform 02/21/17 15:25:20: Attempting to sync password for jeremiah.pedersen 02/21/17 15:25:20: Searching for (uid=jeremiah.pedersen) 02/21/17 15:25:20: Password match, no modify performed: jeremiah.pedersen 02/21/17 15:25:20: Removing password change from list 02/21/17 15:25:20: Password list is empty. Waiting for passhook event 02/21/17 17:19:42: Received passhook event. Attempting sync 02/21/17 17:19:42: 1 new entries loaded from data file 02/21/17 17:19:42: Cleared contents of data file 02/21/17 17:19:42: Password list has 1 entries 02/21/17 17:19:42: Ldap bind error in Connect 53: DSA is unwilling to perform 02/21/17 17:19:42: Attempting to sync password for jeremiah 02/21/17 17:19:42: Searching for (uid=jeremiah) 02/21/17 17:19:42: Password match, no modify performed: jeremiah 02/21/17 17:19:42: Removing password change from list 02/21/17 17:19:42: Password list is empty. Waiting for passhook event 02/22/17 05:05:15: Received passhook event. Attempting sync 02/22/17 05:05:15: 1 new entries loaded from data file 02/22/17 05:05:15: Cleared contents of data file 02/22/17 05:05:15: Password list has 1 entries 02/22/17 05:05:15: Ldap bind error in Connect 53: DSA is unwilling to perform 02/22/17 05:05:15: Attempting to sync password for ray 02/22/17 05:05:15: Searching for (uid=ray) 02/22/17 05:05:15: Ldap error in ModifyPassword 50: Insufficient access 02/22/17 05:05:15: Modify password failed for remote entry: uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int 02/22/17 05:05:15: Deferring password change for ray 02/22/17 05:05:15: Backing off for 2000ms 02/22/17 05:05:17: Backoff time expired. Attempting sync 02/22/17 05:05:17: Password list has 1 entries 02/22/17 05:05:17: Ldap bind error in Connect 53: DSA is unwilling to perform 02/22/17 05:05:17: Attempting to sync password for ray 02/22/17 05:05:17: Searching for (uid=ray) 02/22/17 05:05:17: Ldap error in ModifyPassword 50: Insufficient access 02/22/17 05:05:17: Modify password failed for remote entry: uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int 02/22/17 05:05:17: Deferring password change for ray 02/22/17 05:05:17: Backing off for 4000ms 02/22/17 05:05:21: Backoff time expired. Attempting sync 02/22/17 05:05:21: Password list has 1 entries 02/22/17 05:05:21: Ldap bind error in Connect 53: DSA is unwilling to perform 02/22/17 05:05:21: Attempting to sync password for ray 02/22/17 05:05:21: Searching for (uid=ray) 02/22/17 05:05:21: Ldap error in ModifyPassword 50: Insufficient access 02/22/17 05:05:21: Modify password failed for remote entry: uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int 02/22/17 05:05:21: Deferring password change for ray 02/22/17 05:05:21: Backing off for 8000ms 02/22/17 05:05:29: Backoff time expired. Attempting sync 02/22/17 05:05:29: Password list has 1 entries 02/22/17 05:05:29: Ldap bind error in Connect 53: DSA is unwilling to perform Any help would greatly be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Thu Feb 23 16:08:07 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Thu, 23 Feb 2017 08:08:07 -0800 Subject: [Freeipa-users] ldapsearch for AD users In-Reply-To: <20170223062628.3scsvt3fpc5b5oky@redhat.com> References: <20170222072852.u3r5zusplcxvtiow@redhat.com> <20170222152244.rgfpwfdnvuwxuzhm@redhat.com> <20170222163423.h37n56eserowtxa6@redhat.com> <20170222193846.wjxofl533tzlldw2@redhat.com> <1505619398.823.1487800206507.JavaMail.zimbra@tresgeek.net> <20170223062628.3scsvt3fpc5b5oky@redhat.com> Message-ID: Thanks Alexander, I have rebuilt the server with compatibility and I can now query AD users. I'll just have to confirm with Dell / EMC whether the Isilon can now handle this. Regards, Hanoz On Wed, Feb 22, 2017 at 10:26 PM, Alexander Bokovoy wrote: > On ke, 22 helmi 2017, Jason B. Nance wrote: > >> For example, for user that would be (&(objectClass=posixAccount)(uid=%s)) >>> where %s is ad_user at server.com according to your example. >>> >>> This is what would be intercepted and queried through SSSD. >>> >>> For example: >>> >>> $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool >>> '(&(objectClass=posixAccount)(uid=user at ad.ipa.cool))' >>> SASL/GSSAPI authentication started >>> SASL username: admin at XS.IPA.COOL >>> SASL SSF: 56 >>> SASL data security layer installed. >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree >>> # filter: (&(objectClass=posixAccount)(uid=user at ad.ipa.cool)) >>> # requesting: ALL >>> # >>> >>> # user at ad.ipa.cool, users, compat, xs.ipa.cool >>> dn: uid=user at ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool >>> objectClass: ipaOverrideTarget >>> objectClass: posixAccount >>> objectClass: top >>> cn: YO! >>> gidNumber: 967001113 >>> gecos: YO! >>> ipaAnchorUUID:: >>> uidNumber: 967001113 >>> loginShell: /bin/bash >>> homeDirectory: /home/ad.ipa.cool/user >>> uid: user at ad.ipa.cool >>> >>> # search result >>> search: 4 >>> result: 0 Success >>> >>> # numResponses: 2 >>> # numEntries: 1 >>> >> >> I'm not able to recreate this (on FreeIPA 4.4.0). "ipa-compat-manage >> status" says "Plugin Enabled", but searches for AD users yield no >> results: >> > Sorry, I forgot mention yesterday that if you didn't use > 'ipa-adtrust-install --enable-compat' then one thing is missing from > compat tree configuration to allow resolution of AD users. Luckily, it > is a simple ldapadd that can fix it. You can use ipa-ldap-updater: > > > # cat 80-enable-compat-nsswitch.update dn: cn=users,cn=Schema > Compatibility,cn=plugins,cn=config > add:schema-compat-lookup-nsswitch: user > > dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config > add:schema-compat-lookup-nsswitch: group > # ipa-ldap-updater ./80-enable-compat-nsswitch.update > and then restart 389-ds. > > As a side note, I'm also not able to use GSSAPI auth as you did: >> >> $ kinit >> Password for jnance at LAB.GEN.ZONE: >> $ ldapsearch -Y GSSAPI -b cn=compat,dc=ipa,dc=lab,dc=gen,dc=zone >> '(&(objectClass=posixAccount)(uid=jnance at lab.gen.zone))' >> SASL/GSSAPI authentication started >> ldap_sasl_interactive_bind_s: Invalid credentials (49) >> > I used IPA user, not AD user to bind with GSSAPI. > > In FreeIPA 4.4 it should also work with AD user as well but only if the > user has ID override entry, even empty one: > > # ipa idoverrideuser-add 'Default Trust View' administrator at ad.ipa.cool > > and now administrator at ad.ipa.cool will be able to issue ldap searches > against IPA LDAP server from Linux machines. Note that ldp.exe will > still be unable to perform searches against IPA LDAP until > https://github.com/cyrusimap/cyrus-sasl/pull/424 is released in a > distribution. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Auerbach at flbog.edu Thu Feb 23 16:23:43 2017 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Thu, 23 Feb 2017 16:23:43 +0000 Subject: [Freeipa-users] Recall: sudo NOPASSWD for a single command Message-ID: Auerbach, Steven would like to recall the message, "[Freeipa-users] sudo NOPASSWD for a single command". From Steven.Auerbach at flbog.edu Thu Feb 23 16:29:56 2017 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Thu, 23 Feb 2017 16:29:56 +0000 Subject: [Freeipa-users] UPDATE: Resolved sudo NOPASSWD for a single command Message-ID: Yes, I implemented in Policy -> Sudo -> Sudo Commands as: Sudo Command: NOPASSWD: /sbin/vgs The script (executed by a non-root, administrative group user on an enrolled host) specifies: ?. hostname >> statresults.txt cat /etc/redhat-release >> statresults.txt uname -r >> statresults.txt printf "\n " >> statresults.txt sudo vgs >> statresults.txt ?.. Running the script I still was prompted for a password. RESEARCH AND CORRECTION: In the sssd.conf file on the enrolled host I found an invalid pointer to ?ipa_server=? directive which I corrected and added sudo to the ?services=? directive. One or both of those changes corrected the situation and vgs runs under sudo without a password prompt. From: Jason B. Nance [mailto:jason at tresgeek.net] Sent: Wednesday, February 22, 2017 11:59 AM To: Auerbach, Steven Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] sudo NOPASSWD for a single command We have a script stored on a particular server in our realm that executes a number of non-privileged commands and are wanting to add /sbin/vgs command. The script uses SSH to then execute the same set of commands on all the servers in the realm. The owner of the script is in the administrator group and there are sudoer commands for the administrator group in general. We need to place a rule for this one command for either this group or the script owner to run NOPASSWD. Where and how would I specify that in the IPA admin console? Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> Sudo -> Sudo Commands)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at marketfactory.com Thu Feb 23 16:56:54 2017 From: ayoung at marketfactory.com (Aaron Young) Date: Thu, 23 Feb 2017 11:56:54 -0500 Subject: [Freeipa-users] authenticating with dns In-Reply-To: References: Message-ID: on ld4ipa01, I removed it with ipa-server-install --uninstall this was an attempt to recreate the replica from nyc02ipa02 On Thu, Feb 23, 2017 at 3:17 AM, Martin Basti wrote: > > > On 22.02.2017 23:26, Aaron Young wrote: > > Hello Everyone > > I recently lost the master master IPA server setup by the previous > administrator. > As it stands now, if I try to add a new client, in order to standup a new > replica, I get errors while trying to setup DNS. This led me to look at how > authentication worked (I'm new to IPA) and I learned about the kerberos > tools > > I don't know if I'm familiar enough with the terminology to adequately > describe what I'm experiencing, so I'll give you some of the commands and > their results > > but first, a bit on the design > > before I got to this, we had > > a <-> b <-> c <-> d > > b was the master master > > a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 (not > pictured, I discovered them later when c and d started having problems) > > a - nyc01ipa02 > b - nyc01ipa01 > c - ld4ipa01 > d - ld4ipa02 > > currently, I have nyc02ipa02 <-> nyc01ipa02 > > the reason I have it limited like this is because all the other servers > stopped replicating for one reason or another (mainly that they can't > authenticate or in one case, there was a database record corruption) > > Anyway, here are some activities and logs from the latest round of fixes > and information activities I've been engaging in > > 22:54:32 root at nyc01ipa02:~# kinit admin > kinit: Clients credentials have been revoked while getting initial > credentials > > Reading through this > tells me > that > > # kadmin: modprinc -unlock PRINCNAME > > will unlock an account...but if I can't get in.... > > 22:54:37 root at nyc01ipa02:~# kadmin > Authenticating as principal root/admin at MF with password. > kadmin: Client 'root/admin at MF' not found in Kerberos database while > initializing kadmin interface > > on ld4ipa02, did a > > # ipa-client-install --uninstall > > then > > # ipa-client-install --force-join --enable-dns-updates --permit -f > --ssh-trust-dns --request-cert --automount-location=LD4 --enable-dns-updates > > DNS did not update, here is the relevant portion from > /var/log/ipaclient-install.log > > 2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt: > 2017-02-20T18:46:49Z DEBUG debug > > update delete ld4ipa02.mf. IN A > show > send > > update delete ld4ipa02.mf. IN AAAA > show > send > > update add ld4ipa02.mf. 1200 IN A 10.102.100.140 > show > send > > 2017-02-20T18:46:49Z DEBUG Starting external process > 2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > 2017-02-20T18:46:49Z DEBUG Process finished, return code=1 > 2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 > ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 > ;; UPDATE SECTION: > ld4ipa02.mf. 0 ANY A > > 2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702 > ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;ld4ipa02.mf. IN SOA > > ;; AUTHORITY SECTION: > mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600 > > Found zone name: mf > The master is: ld4ipa01.mf > start_gssrequest > tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ld4ipa01.mf at MF not found in Kerberos database. > > 2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 > 2017-02-20T18:46:49Z ERROR Failed to update DNS records. > 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A > 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. > 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN AAAA > 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. > 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: 140.100.102.10.in-addr.arpa. IN PTR > 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. > 2017-02-20T18:46:49Z WARNING Missing A/AAAA record(s) for host ld4ipa02.mf: 10.102.100.140. > 2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 10.102.100.140. > > Why isn't there an entry for "DNS/ld4ipa01.mf at MF" in the Kerberos > database? > > klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns > > Keytab name: FILE:/etc/dirsrv/ds.keytab > KVNO Timestamp Principal > ---- ------------------- ------------------------------ > ------------------------ > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x696a502bc73d209acdd36c42242f > 7f8aff9dbba1073b34ea018ed3bd9cdfd970) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe031464b6948ea34f4291d40fca7 > a21e) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe94a1c98fe79b6317901435d9e9e > 0257cefe438ff2ec527f) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6aaf4c7fa6b51b9de032b7c64283 > 07b5) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x5e0702f44aef9e0633e09eede7ca > 8041) > 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6e3a9d29ee3f129a156ae6228ab7 > 728df8ce5de923a61eba6a2e7802b8d230b6) > > > Tried to test connectivity using ldapsearch found that I could connect to > other hosts on 389 but not 636 > > # ldapsearch -H ldap://nyc02ipa02:389 -D "cn=directory manager" -W -b "" -s base > > # ldapsearch -H ldaps://nyc02ipa02:686 -D "cn=directory manager" -W -b "" -s base > > Testing the kvno > > 02:10:00 root at ld4ipa01:~# kvno DNS/ld4ipa01.mf at MF > DNS/ld4ipa01.mf at MF: kvno = 2 > > 02:10:52 root at ld4ipa02:~# kvno DNS/ld4ipa01.mf at MF > kvno: Server DNS/ld4ipa01.mf at MF not found in Kerberos database while > getting credentials for DNS/ld4ipa01.mf at MF > > Add this to any command line to get debug on kerberos commands > > KRB5_TRACE=/dev/stdout kvno DNS/ld4ipa01.mf at MF > > So, looking at the debug > kvno from ld4ipa02, does not return tickets. It does this because it > contacts the KDC which is nyc02ipa02, and nyc02ipa02 does not recognize > ldipa02 as an IPA server. It doesn't recognize ld4ipa01 either. > > > > right now, if I try to connect nyc02ipa02 to ld4ipa01 I get > > 21:56:27 root at nyc02ipa02:~# ipa topologysegment-add domain > ld4ipa01-to-nyc02ipa02 --leftnode ld4ipa01.mf --rightnode nyc02ipa02.mf > ipa: ERROR: invalid 'leftnode': left node is not a topology node: > ld4ipa01.mf > > ipa privilege-show 'DNS Servers' --all --raw > > dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=mf > cn: DNS Servers > description: DNS Servers > member: krbprincipalname=DNS/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=ipa-dnskeysyncd/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=DNS/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=ipa-dnskeysyncd/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf > member: krbprincipalname=ipa-ods-exporter/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf > memberof: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=mf > memberof: cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=mf > objectClass: top > objectClass: groupofnames > objectClass: nestedgroup > > > -- > Aaron Young > MarketFactory, Manager of Site Reliability Engineering > 425 Broadway, 3FL > New York, NY 10013 > Office: +1 212 625 9988 <(212)%20625-9988> > Direct +1 646 779 3710 <(646)%20779-3710> > US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 > > > > Hello, > > please don't use kadmin utility, it is not integrated very well with IPA > (or unsupported is a better word) and may break it even more. It looks that > you have corrupted kerberos credentials for id4ipa01 > > I see you are installing client on id4ipa01, was IPA server removed > properly previosly? > > Martin > -- Aaron Young MarketFactory, Manager of Site Reliability Engineering 425 Broadway, 3FL New York, NY 10013 Office: +1 212 625 9988 Direct +1 646 779 3710 US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at marketfactory.com Thu Feb 23 16:57:18 2017 From: ayoung at marketfactory.com (Aaron Young) Date: Thu, 23 Feb 2017 11:57:18 -0500 Subject: [Freeipa-users] authenticating with dns In-Reply-To: References: Message-ID: And yes, I learned to stop using kadmin after I made that note On Thu, Feb 23, 2017 at 11:56 AM, Aaron Young wrote: > on ld4ipa01, I removed it with ipa-server-install --uninstall > > this was an attempt to recreate the replica from nyc02ipa02 > > On Thu, Feb 23, 2017 at 3:17 AM, Martin Basti wrote: > >> >> >> On 22.02.2017 23:26, Aaron Young wrote: >> >> Hello Everyone >> >> I recently lost the master master IPA server setup by the previous >> administrator. >> As it stands now, if I try to add a new client, in order to standup a new >> replica, I get errors while trying to setup DNS. This led me to look at how >> authentication worked (I'm new to IPA) and I learned about the kerberos >> tools >> >> I don't know if I'm familiar enough with the terminology to adequately >> describe what I'm experiencing, so I'll give you some of the commands and >> their results >> >> but first, a bit on the design >> >> before I got to this, we had >> >> a <-> b <-> c <-> d >> >> b was the master master >> >> a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 (not >> pictured, I discovered them later when c and d started having problems) >> >> a - nyc01ipa02 >> b - nyc01ipa01 >> c - ld4ipa01 >> d - ld4ipa02 >> >> currently, I have nyc02ipa02 <-> nyc01ipa02 >> >> the reason I have it limited like this is because all the other servers >> stopped replicating for one reason or another (mainly that they can't >> authenticate or in one case, there was a database record corruption) >> >> Anyway, here are some activities and logs from the latest round of fixes >> and information activities I've been engaging in >> >> 22:54:32 root at nyc01ipa02:~# kinit admin >> kinit: Clients credentials have been revoked while getting initial >> credentials >> >> Reading through this >> tells me >> that >> >> # kadmin: modprinc -unlock PRINCNAME >> >> will unlock an account...but if I can't get in.... >> >> 22:54:37 root at nyc01ipa02:~# kadmin >> Authenticating as principal root/admin at MF with password. >> kadmin: Client 'root/admin at MF' not found in Kerberos database while >> initializing kadmin interface >> >> on ld4ipa02, did a >> >> # ipa-client-install --uninstall >> >> then >> >> # ipa-client-install --force-join --enable-dns-updates --permit -f >> --ssh-trust-dns --request-cert --automount-location=LD4 --enable-dns-updates >> >> DNS did not update, here is the relevant portion from >> /var/log/ipaclient-install.log >> >> 2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt: >> 2017-02-20T18:46:49Z DEBUG debug >> >> update delete ld4ipa02.mf. IN A >> show >> send >> >> update delete ld4ipa02.mf. IN AAAA >> show >> send >> >> update add ld4ipa02.mf. 1200 IN A 10.102.100.140 >> show >> send >> >> 2017-02-20T18:46:49Z DEBUG Starting external process >> 2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt >> 2017-02-20T18:46:49Z DEBUG Process finished, return code=1 >> 2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query: >> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 >> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >> ;; UPDATE SECTION: >> ld4ipa02.mf. 0 ANY A >> >> 2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702 >> ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >> ;; QUESTION SECTION: >> ;ld4ipa02.mf. IN SOA >> >> ;; AUTHORITY SECTION: >> mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600 >> >> Found zone name: mf >> The master is: ld4ipa01.mf >> start_gssrequest >> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ld4ipa01.mf at MF not found in Kerberos database. >> >> 2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 >> 2017-02-20T18:46:49Z ERROR Failed to update DNS records. >> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A >> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. >> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN AAAA >> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. >> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: 140.100.102.10.in-addr.arpa. IN PTR >> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. >> 2017-02-20T18:46:49Z WARNING Missing A/AAAA record(s) for host ld4ipa02.mf: 10.102.100.140. >> 2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 10.102.100.140. >> >> Why isn't there an entry for "DNS/ld4ipa01.mf at MF" in the Kerberos >> database? >> >> klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns >> >> Keytab name: FILE:/etc/dirsrv/ds.keytab >> >> KVNO Timestamp Principal >> ---- ------------------- ------------------------------ >> ------------------------ >> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x696a502bc73d209acdd36c42242 >> f7f8aff9dbba1073b34ea018ed3bd9cdfd970) >> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe031464b6948ea34f4291d40fca >> 7a21e) >> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe94a1c98fe79b6317901435d9e9 >> e0257cefe438ff2ec527f) >> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6aaf4c7fa6b51b9de032b7c6428 >> 307b5) >> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x5e0702f44aef9e0633e09eede7c >> a8041) >> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6e3a9d29ee3f129a156ae6228ab >> 7728df8ce5de923a61eba6a2e7802b8d230b6) >> >> >> Tried to test connectivity using ldapsearch found that I could connect >> to other hosts on 389 but not 636 >> >> # ldapsearch -H ldap://nyc02ipa02:389 -D "cn=directory manager" -W -b "" -s base >> >> # ldapsearch -H ldaps://nyc02ipa02:686 -D "cn=directory manager" -W -b "" -s base >> >> Testing the kvno >> >> 02:10:00 root at ld4ipa01:~# kvno DNS/ld4ipa01.mf at MF >> DNS/ld4ipa01.mf at MF: kvno = 2 >> >> 02:10:52 root at ld4ipa02:~# kvno DNS/ld4ipa01.mf at MF >> kvno: Server DNS/ld4ipa01.mf at MF not found in Kerberos database while >> getting credentials for DNS/ld4ipa01.mf at MF >> >> Add this to any command line to get debug on kerberos commands >> >> KRB5_TRACE=/dev/stdout kvno DNS/ld4ipa01.mf at MF >> >> So, looking at the debug >> kvno from ld4ipa02, does not return tickets. It does this because it >> contacts the KDC which is nyc02ipa02, and nyc02ipa02 does not recognize >> ldipa02 as an IPA server. It doesn't recognize ld4ipa01 either. >> >> >> >> right now, if I try to connect nyc02ipa02 to ld4ipa01 I get >> >> 21:56:27 root at nyc02ipa02:~# ipa topologysegment-add domain >> ld4ipa01-to-nyc02ipa02 --leftnode ld4ipa01.mf --rightnode nyc02ipa02.mf >> ipa: ERROR: invalid 'leftnode': left node is not a topology node: >> ld4ipa01.mf >> >> ipa privilege-show 'DNS Servers' --all --raw >> >> dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=mf >> cn: DNS Servers >> description: DNS Servers >> member: krbprincipalname=DNS/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf >> member: krbprincipalname=ipa-dnskeysyncd/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf >> member: krbprincipalname=DNS/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf >> member: krbprincipalname=ipa-dnskeysyncd/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf >> member: krbprincipalname=ipa-ods-exporter/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf >> memberof: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=mf >> memberof: cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=mf >> objectClass: top >> objectClass: groupofnames >> objectClass: nestedgroup >> >> >> -- >> Aaron Young >> MarketFactory, Manager of Site Reliability Engineering >> 425 Broadway, 3FL >> New York, NY 10013 >> Office: +1 212 625 9988 <(212)%20625-9988> >> Direct +1 646 779 3710 <(646)%20779-3710> >> US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 >> >> >> >> Hello, >> >> please don't use kadmin utility, it is not integrated very well with IPA >> (or unsupported is a better word) and may break it even more. It looks that >> you have corrupted kerberos credentials for id4ipa01 >> >> I see you are installing client on id4ipa01, was IPA server removed >> properly previosly? >> >> Martin >> > > > > -- > Aaron Young > MarketFactory, Manager of Site Reliability Engineering > 425 Broadway, 3FL > New York, NY 10013 > Office: +1 212 625 9988 <(212)%20625-9988> > Direct +1 646 779 3710 <(646)%20779-3710> > US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 > -- Aaron Young MarketFactory, Manager of Site Reliability Engineering 425 Broadway, 3FL New York, NY 10013 Office: +1 212 625 9988 Direct +1 646 779 3710 US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Auerbach at flbog.edu Thu Feb 23 18:29:16 2017 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Thu, 23 Feb 2017 18:29:16 +0000 Subject: [Freeipa-users] UPDATE: NOT Resolved After All -- sudo NOPASSWD for a single command Message-ID: Yes, I implemented in Policy -> Sudo -> Sudo Commands as: Sudo Command: NOPASSWD: /sbin/vgs The script (executed by a non-root, administrative group user on an enrolled host) specifies: ?. hostname >> statresults.txt cat /etc/redhat-release >> statresults.txt uname -r >> statresults.txt printf "\n " >> statresults.txt sudo vgs >> statresults.txt ?.. Running the script I still was prompted for a password. RESEARCH AND CORRECTION: In the sssd.conf file on the enrolled host I found an invalid pointer to ?ipa_server=? directive which I corrected and added sudo to the ?services=? directive. One or both of those changes corrected the situation and vgs runs under sudo without a password prompt. FURTHER CORRECTION: The sssd.conf changes did NOT resolve the issue. The password must have been cached from a prior script run when I re-ran it. I am being prompted for password by the sudo line again. From: Jason B. Nance [mailto:jason at tresgeek.net] Sent: Wednesday, February 22, 2017 11:59 AM To: Auerbach, Steven Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] sudo NOPASSWD for a single command We have a script stored on a particular server in our realm that executes a number of non-privileged commands and are wanting to add /sbin/vgs command. The script uses SSH to then execute the same set of commands on all the servers in the realm. The owner of the script is in the administrator group and there are sudoer commands for the administrator group in general. We need to place a rule for this one command for either this group or the script owner to run NOPASSWD. Where and how would I specify that in the IPA admin console? Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> Sudo -> Sudo Commands)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at josemaas.net Thu Feb 23 18:50:18 2017 From: fedora at josemaas.net (Joseph Vandermas) Date: Thu, 23 Feb 2017 13:50:18 -0500 (EST) Subject: [Freeipa-users] pki-tomcat will not start after certificate renewal In-Reply-To: References: <589ce8cd.JHznaGVVLmX1uW8t%fedora@josemaas.net> Message-ID: I got really busy sorry about the delay. It was a coworker who renewed our CA cert during an upgrade from Centos 6 to Centos 7. I remember him saying during the upgrade the CA broke and he had to mess around with it. According to him "Pretty sure I did the walk the clock back thing, but it's been so long I don't remember." As for pki-tomcat it certs where renewed automatically. I have tried the work around that was suggested on the open bug and that did not fix my issue. On Thu, 9 Feb 2017, Rob Crittenden wrote: > Joseph Vandermaas wrote: >> All >> I have been experiencing some issues with a FreeIPA instance that I maintain. More specifically pki-tomcat has not started since around the time it?s certificate renewed. I submitted this bug report https://fedorahosted.org/freeipa/ticket/6521, however a solution has yet to be found. >> This installation does have one instresting issue that I believe may be causing it to fail. There are two certificates under cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid CA certificates and when I run openssl verify with ether of them as the CA and the new subsystem certificate I get an OK message. I also believe that this issue is causing me not to be able to do a ipa-certupdate on the broken IPA server. Is there a way to to clean this up, should I try renewing the CA certificate and get rid of the old LDAP entries? >> > > What did you do, as exactly as you can remember, to get the certificates > renewed? > > rob > From huston at astro.princeton.edu Thu Feb 23 21:14:27 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Thu, 23 Feb 2017 16:14:27 -0500 Subject: [Freeipa-users] New install, unsupported format? Message-ID: Next stage of my testing was to make a replica of the FreeIPA server, and I started by doing a 'yum install ipa-server' and then moved on to adding the host to the ipaservers group. This fails every time however, with the error: ipa: ERROR: cannot connect to 'https://ipa.astro.princeton.edu/ipa/json': (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. Searches on this seem to turn up things like expired certificates, or "reboot httpd" (I went ahead and rebooted the whole ipa server), but nothing concrete. Suggestions? Everything (server and soon-to-be replica) running RHEL7.3 with all updates. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From rcritten at redhat.com Thu Feb 23 21:25:21 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Feb 2017 16:25:21 -0500 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: References: Message-ID: Steve Huston wrote: > Next stage of my testing was to make a replica of the FreeIPA server, > and I started by doing a 'yum install ipa-server' and then moved on to > adding the host to the ipaservers group. This fails every time > however, with the error: > > ipa: ERROR: cannot connect to > 'https://ipa.astro.princeton.edu/ipa/json': > (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, > unsupported format. > > Searches on this seem to turn up things like expired certificates, or > "reboot httpd" (I went ahead and rebooted the whole ipa server), but > nothing concrete. Suggestions? Everything (server and soon-to-be > replica) running RHEL7.3 with all updates. > See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9 rob From huston at astro.princeton.edu Thu Feb 23 21:38:50 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Thu, 23 Feb 2017 16:38:50 -0500 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: References: Message-ID: I already had to do that previously to get other things to work; I had solved it by changing line 582 of /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from "::1" to "localhost" before installing the server. I did do this on the to-be-promoted client as well, to no avail. On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden wrote: > Steve Huston wrote: >> Next stage of my testing was to make a replica of the FreeIPA server, >> and I started by doing a 'yum install ipa-server' and then moved on to >> adding the host to the ipaservers group. This fails every time >> however, with the error: >> >> ipa: ERROR: cannot connect to >> 'https://ipa.astro.princeton.edu/ipa/json': >> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, >> unsupported format. >> >> Searches on this seem to turn up things like expired certificates, or >> "reboot httpd" (I went ahead and rebooted the whole ipa server), but >> nothing concrete. Suggestions? Everything (server and soon-to-be >> replica) running RHEL7.3 with all updates. >> > > See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9 > > rob -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From gnotrica at candeal.com Thu Feb 23 21:20:09 2017 From: gnotrica at candeal.com (Gady Notrica) Date: Thu, 23 Feb 2017 21:20:09 +0000 Subject: [Freeipa-users] WARNING: Existing users or groups do not have a SID identifier assigned Message-ID: <0984AB34E553F54B8705D776686863E70FD70243@cd-exchange01.CD-PRD.candeal.ca> Hello, When setting up a trust between IPA and AD I am having the Warning below. Question: Is this going to affect the users in Active Directory if IPA sync back with AD? Any help? # ipa-adtrust-install WARNING: 200 existing users or groups do not have a SID identifier assigned. Installer can run a task to have ipa-sidgen Directory Server plugin generate the SID identifier for all these users. Please note, the in case of a high number of users and groups, the operation might lead to high replication traffic and performance degradation. Refer to ipa-adtrust-install(1) man page for details. Do you want to run the ipa-sidgen task? [no]: Thank you, Gady -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnotrica at candeal.com Thu Feb 23 19:41:03 2017 From: gnotrica at candeal.com (Gady Notrica) Date: Thu, 23 Feb 2017 19:41:03 +0000 Subject: [Freeipa-users] WARNING: Existing users or groups do not have a SID identifier assigned Message-ID: <0984AB34E553F54B8705D776686863E70FD6F952@cd-exchange01.CD-PRD.candeal.ca> Hello, When setting up a trust between IPA and AD I am having the Warning below. Question: Is this going to affect the users in Active Directory if IPA sync back with AD? # ipa-adtrust-install WARNING: 200 existing users or groups do not have a SID identifier assigned. Installer can run a task to have ipa-sidgen Directory Server plugin generate the SID identifier for all these users. Please note, the in case of a high number of users and groups, the operation might lead to high replication traffic and performance degradation. Refer to ipa-adtrust-install(1) man page for details. Do you want to run the ipa-sidgen task? [no]: -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Thu Feb 23 23:42:36 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Thu, 23 Feb 2017 15:42:36 -0800 Subject: [Freeipa-users] Default domain for AD groups Message-ID: Hello, My FreeIPA clients and server are setup to use the AD domain as the default. This is done using the default_domain_suffix parameter in the sssd section of the sssd.conf file. This works fine for users when we use ldapsearch but not so much for groups. For e.g.: ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b 'cn=compat,dc=ipa,dc=server,dc=com' -D 'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' '(cn= domaingroup at server.com)' works fine but ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b 'cn=compat,dc=ipa,dc=server,dc=com' -D 'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' '(cn=domaingroup)' won't work. However, the above will work fine for users. I'm using the following: AD: Windows 2008 R2 FreeIPA Server: 4.4.0-14 FreeIPA Client: 4.4.0-14 SSSD: 1.14.0-43 Linux version: CentOS 7.3 x64_86 The AD trust is setup with --enable-compat. Regards, Hanoz -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrix.zj at qq.com Fri Feb 24 00:08:50 2017 From: matrix.zj at qq.com (=?ISO-8859-1?B?TWF0cml4?=) Date: Fri, 24 Feb 2017 08:08:50 +0800 Subject: [Freeipa-users] integrated DNS vs external DNS References: Message-ID: No, integrated dns is an optional component of ipa, even for ad integration. But without integrated DNS, you have to correctly configure all srv records by manual. Matrix ------------------ Original ------------------ From: Iulian Roman Date: Thu,Feb 23,2017 09:16 To: freeipa-users Subject: Re: [Freeipa-users] integrated DNS vs external DNS -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Feb 24 06:03:21 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Feb 2017 08:03:21 +0200 Subject: [Freeipa-users] WARNING: Existing users or groups do not have a SID identifier assigned In-Reply-To: <0984AB34E553F54B8705D776686863E70FD6F952@cd-exchange01.CD-PRD.candeal.ca> References: <0984AB34E553F54B8705D776686863E70FD6F952@cd-exchange01.CD-PRD.candeal.ca> Message-ID: <20170224060321.6itiyy5k3wp6jm4k@redhat.com> On to, 23 helmi 2017, Gady Notrica wrote: >Hello, > >When setting up a trust between IPA and AD I am having the Warning >below. Question: Is this going to affect the users in Active Directory >if IPA sync back with AD? winsync and trust are incompatible options. You are supposed to disable winsync when switching to trust. To your question, the attributes that would be added, aren't synchronized back by winsync. Still, if you are switching from winsync to trust, disable winsync first. > ># ipa-adtrust-install > >WARNING: 200 existing users or groups do not have a SID identifier assigned. >Installer can run a task to have ipa-sidgen Directory Server plugin generate >the SID identifier for all these users. Please note, the in case of a high >number of users and groups, the operation might lead to high replication >traffic and performance degradation. Refer to ipa-adtrust-install(1) man page >for details. > >Do you want to run the ipa-sidgen task? [no]: >-- >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 abokovoy at redhat.com Fri Feb 24 06:04:43 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Feb 2017 08:04:43 +0200 Subject: [Freeipa-users] Default domain for AD groups In-Reply-To: References: Message-ID: <20170224060443.m7qrfxcpzj6cnqxr@redhat.com> On to, 23 helmi 2017, Hanoz Elavia wrote: >Hello, > >My FreeIPA clients and server are setup to use the AD domain as the >default. This is done using the default_domain_suffix parameter in the sssd >section of the sssd.conf file. > >This works fine for users when we use ldapsearch but not so much for >groups. For e.g.: > >ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b >'cn=compat,dc=ipa,dc=server,dc=com' -D >'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' '(cn= >domaingroup at server.com)' > >works fine but > >ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b >'cn=compat,dc=ipa,dc=server,dc=com' -D >'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' >'(cn=domaingroup)' > >won't work. However, the above will work fine for users. I'm using the No, compat tree is designed to be used with fully-qualified groups and users. There is no way around it. -- / Alexander Bokovoy From slaznick at redhat.com Fri Feb 24 07:31:43 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Fri, 24 Feb 2017 08:31:43 +0100 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: References: Message-ID: <67e3e2fb-0d57-793f-5bae-2395dfdd828a@redhat.com> Hello, I don't quite understand your situation - have the error happened during an addition of the host to the "ipaservers" group or during replica installation? Certutil is a wonderful piece of software that returns "(SEC_ERROR_LEGACY_DATABASE)" in about 90% of most common cases but I have never seen an actual legacy database. Usually, this error means that the directory you're pointing the certutil tool to either does not exist or you don't have the permissions to read/write in this exact directory. Cheers, Standa P.S.: I might have sent you this email twice because I am a bad person when it comes to the "Send" button, please reply to the email which has "freeipa-users" in CC :) On 02/23/2017 10:38 PM, Steve Huston wrote: > I already had to do that previously to get other things to work; I had > solved it by changing line 582 of > /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from > "::1" to "localhost" before installing the server. I did do this on > the to-be-promoted client as well, to no avail. > > On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden wrote: >> Steve Huston wrote: >>> Next stage of my testing was to make a replica of the FreeIPA server, >>> and I started by doing a 'yum install ipa-server' and then moved on to >>> adding the host to the ipaservers group. This fails every time >>> however, with the error: >>> >>> ipa: ERROR: cannot connect to >>> 'https://ipa.astro.princeton.edu/ipa/json': >>> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, >>> unsupported format. >>> >>> Searches on this seem to turn up things like expired certificates, or >>> "reboot httpd" (I went ahead and rebooted the whole ipa server), but >>> nothing concrete. Suggestions? Everything (server and soon-to-be >>> replica) running RHEL7.3 with all updates. >>> >> See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9 >> >> rob > > From pbrezina at redhat.com Fri Feb 24 08:21:00 2017 From: pbrezina at redhat.com (=?UTF-8?Q?Pavel_B=c5=99ezina?=) Date: Fri, 24 Feb 2017 09:21:00 +0100 Subject: [Freeipa-users] sudo NOPASSWD for a single command In-Reply-To: References: <1351947637.1781.1487782715833.JavaMail.zimbra@tresgeek.net> Message-ID: <741faa4a-c866-d7fe-55be-b4e80301ff76@redhat.com> On 02/23/2017 03:43 PM, Auerbach, Steven wrote: > Yes, I implemented in Policy -> Sudo -> Sudo Commands as: > > Sudo Command: NOPASSWD: /sbin/vgs NOPASSWD is used in /etc/sudoers. In IPA, create a sudo option "!authenticate" instead. > > > > The script (executed by a non-root, administrative group user on an > enrolled host) specifies: > > ?. > > hostname >> statresults.txt > > cat /etc/redhat-release >> statresults.txt > > uname -r >> statresults.txt > > printf "\n " >> statresults.txt > > sudo vgs >> statresults.txt > > ?.. > > Running the script I still was prompted for a password. So I guess this > does not work. > > > > *From:* Jason B. Nance [mailto:jason at tresgeek.net] > *Sent:* Wednesday, February 22, 2017 11:59 AM > *To:* Auerbach, Steven > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] sudo NOPASSWD for a single command > > > > > > We have a script stored on a particular server in our realm that > executes a number of non-privileged commands and are wanting to add > /sbin/vgs command. The script uses SSH to then execute the same set > of commands on all the servers in the realm. > > The owner of the script is in the administrator group and there are > sudoer commands for the administrator group in general. We need to > place a rule for this one command for either this group or the > script owner to run NOPASSWD. > > Where and how would I specify that in the IPA admin console? > > Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" > (Policy -> Sudo -> Sudo Commands)? > > > > > From keesb at ghs.com Fri Feb 24 08:33:10 2017 From: keesb at ghs.com (Kees Bakker) Date: Fri, 24 Feb 2017 09:33:10 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> Message-ID: On 23-02-17 15:39, Brendan Kearney wrote: > On 02/23/2017 09:11 AM, Kees Bakker wrote: >> On 23-02-17 13:51, Brendan Kearney wrote: >>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>> Hey, >>>>>>>>>> >>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>>> >>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>> >>>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>>> only sees question marks as shown below. >>>>>>>>>> >>>>>>>>>> The mount command is simple. >>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>> >>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>> >>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>> >>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>> total 0 >>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>> >>>>>>>>>> $ ls -l /nfshome >>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>> >>>>>>>>> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) >>>>>>>> Thanks for the reply. >>>>>>>> >>>>>>>> In this case the user _is_ authenticated. >>>>>>>> keesb at client1:~$ klist >>>>>>>> Ticket cache: KEYRING:persistent:60001:60001 >>>>>>>> Default principal: keesb at EXAMPLE.COM >>>>>>>> >>>>>>>> Valid starting Expires Service principal >>>>>>>> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>>>> no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. >>>>>> (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >>>>>> >>>>>>>> What other grants could be needed? HBAC Rules? >>>>>>>> >>>>>>>> Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it >>>>>>>> doesn't help to get access for the user.) >>>>>>> there are principals to create and keytabs to be updated on hte NFS sever, if not done already. >>>>>> I did create a principal for the NFS server (using ipa service-add) and >>>>>> add to the keytab on the NFS server (using ipa-getkeytab) ... >>>>>> root at srv1# klist -ke >>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>> KVNO Principal >>>>>> ---- -------------------------------------------------------------------------- >>>>>> 1 host/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>> 1 host/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>> >>>>>> Is this what you mean? >>>>> yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? >>>> I don't think that a change of idmapd.conf (on the NFS server) is needed because all host >>>> names are FQDN and everything is in one and the same REALM. >>> NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. >> Both the NFS server and the client are configured as FreeIPA client. >> On the server the users are known (through PAM, SSSD). Only user >> "ubuntu" is a local (/etc/passwd) user. All other users are defined on >> the IPA server. >> >> root at srv1:~# ls -l /home >> total 0 >> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >> drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu >> root at srv1:~# ls -ln /home >> total 0 >> drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb >> drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu >> >> On the client, same story >> >> root at client1:~# ls -l /nfshome >> total 0 >> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >> drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu >> root at client1:~# ls -ln /nfshome >> total 0 >> drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb >> drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu >> >> >> >>>>>>> then the user should be able to pull the ticket for auth. >>>>>> Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? >>>>>> >>>>>> keesb at client1$ kinit nfs/srv1.example.com at EXAMPLE.COM >>>>>> Password for nfs/srv1.example.com at EXAMPLE.COM: >>>>>> >>>>>> But I don't have a password for that. Hmm. >>>>> there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. >>>> OK >>>> So, it seems to me that all the basics are setup correctly. The mount succeeds. The user >>>> has a TGT and still the (non-root) user cannot even stat the mount point, nor the directory >>>> entry itself. >>>> >>>> What puzzles me is that root can see everything, also without a TGT. >>> the mount will succeed, but the user does not have access because NFS does not know who the user it. it has an unassociated ID established by kerberos, but not a user. >> Let's step back a little. >> >> On the NFS client, the user does an ls of / (that's where the mountpoint is). At the point >> where ls reads the entry (through stat) for "nfshome" it gets (probably) EPERM. >> And hence ls prints all the question marks. That leads me to believe that only the kernel >> (on the NFS client) is involved at this point. I could be wrong but I don't think there is >> any kerberos TGT involved. >> >>>>>>>> Furthermore, I'm guessing that the host principle which I got after ipa-client-install is >>>>>>>> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I >>>>>>>> did not do.) >>>>>>>> # klist -ke >>>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>>> KVNO Principal >>>>>>>> ---- -------------------------------------------------------------------------- >>>>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>>> >>>>>>>> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>>>>>>> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ >>>>>>> http://www.itp.uzh.ch/~dpotter/howto/kerberos >>>>>>> >>> added the thread back to the mailing list for the benefit of any who search on the subject. >>> >>> > run journalctl -fl on both the NFS server and the NFS client while trying to mount the share. one of them should tell you something. Nothing much. On the server I just see feb 23 15:47:34 srv1.example.com rpc.mountd[22742]: authenticated mount request from 172.16.16.39:678 for /home (/home) The mount succeeds. Simple as that. Mounting is not the problem, I think. > > the mount operation will succeed, because any ACL set in the exports file is being met. root likley has access because the uid/gid is common and local on both devices and therefore no mapping is needed. OK. No problem with that. > your virtual user does not exist in either local user store, and therefore needs to be mapped. No, no, the virtual user is present on both sides, because both NFS server and client are configured as IPA client. That user can login on both systems. The uid/gid mapping is straightforward. > what does /etc/nsswitch.conf say for passwd, shadow and group? > On both server and client: passwd: compat sss group: compat sss shadow: compat sss From mbasti at redhat.com Fri Feb 24 11:07:36 2017 From: mbasti at redhat.com (Martin Basti) Date: Fri, 24 Feb 2017 12:07:36 +0100 Subject: [Freeipa-users] integrated DNS vs external DNS In-Reply-To: References: <6350025c-c979-3818-7fec-3da351ada626@redhat.com> Message-ID: <1e711328-56ec-b472-107d-f2ec40460b72@redhat.com> Adding freeipa-users back to loop On 24.02.2017 12:02, Iulian Roman wrote: > On Thu, Feb 23, 2017 at 4:21 PM, Martin Basti > wrote: > > Hello, > > comments inline > > > On 23.02.2017 15:07, Iulian Roman wrote: >> Despite reading the freeipa and Redhat IdM documentation >> regarding the DNS , it is still unclear to me if and when is >> integrated DNS mandatory . We do have an environment with a >> pretty complex DNS setup , which is in place for years and there >> are no plans to change it. > > Integrated DNS is not mandatory at all. Without IPA DNS you have > to manage all IPA system records manually on external DNS > >> >> if i understood correctly from the documentation , integrated DNS >> is mandatory for configuring AD trust. is that correct ? > No, it is not needed for AD trust, you need to add additional DNS > records > >> >> Can the integrated DNS be configured as forward only ? Do the >> clients need to have IPA DNS as a resolver or they can just use >> existing DNS server ? > You don't need to install IPA DNS. > > All records the IPA needs can be received from command `ipa > dns-update-system-records --dry-run` (IPA4.4+) > > > there are some SRV records (_kerberos, _kpasswd, _ldap, _ntp) reported > by the above command which would not be easy to add them to existing > DNS (DNS updates are form based and they allow only A and CNAME > records). When and by whom are those records used and what is the > consequence of not adding them into existing DNS ? > These are mainly used by ipa-clients (SSSD) with dynamic configuration. However you may configure client to use static configuration (without auto detection of working IPA servers) and it should work. However I'm not sure about DNS records required for AD Trust, who is the consumer, if only SSSD or not. > >> >> >> >> > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iulian.roman at gmail.com Fri Feb 24 11:15:35 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Fri, 24 Feb 2017 12:15:35 +0100 Subject: [Freeipa-users] WEB UI - wrong fonts or incomplete page loaded Message-ID: Hello, After a successful installation of the ipa-server when i try to login via WEB UI i've noticed that the web page looks strange (wrong fonts and page seems not completely/correctly loaded). The network debugger in chrome/firefox does display 2 errors : - json /ipa/session/ 401 Unauthorized - login _kerberos?=... net::ERR_ACCESS_DENIED I do not intend to use SSO for login into WEBUI (although it is the default in the ipa version i am using) but apparently a supported method to disable it is not known. I can login with user and password but the WEB UI is almost unusable because of wrongly loaded page . Did anyone experience the same issue and is there any fix/solution for that ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmzgames.de at googlemail.com Fri Feb 24 11:36:03 2017 From: gmzgames.de at googlemail.com (Gerald Zabos) Date: Fri, 24 Feb 2017 12:36:03 +0100 Subject: [Freeipa-users] New user group not shown on IPA client Message-ID: Hello *, i just created a new user group 'it_testusers' (90600008) on one of the IPA servers and added three existing users: 'test' (90600005) 'ipajoin' (90600001) 'ldaptest' (90600003). When look up the group membership of these users on one of our IPA clients with 'id ' it shows uid, gid and groups=, but the new group 'it_testusers' is still missing. Looking up group membership with 'id ' on all of our IPA servers works, i can see the new group in the list of user's groups. Server OS: Redhat 7.3 ipa-server: ipa-server-4.4.0-14.el7_3.4 Client OS: CentOS 7.3 ipa-client: ipa-client-4.4.0-14.el7.centos.4 I've read https://www.redhat.com/archives/freeipa-users/2015-May/msg00463.html as it seems to be a similar problem. I stopped sssd, removed the files in /var/lib/sss/db and started sssd on the client -> still can't see the new group I rebooted the client -> still can't see the new group Any hints on how to proceed with this problem? Regards, Gerald From huston at astro.princeton.edu Fri Feb 24 13:28:13 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Fri, 24 Feb 2017 08:28:13 -0500 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: <67e3e2fb-0d57-793f-5bae-2395dfdd828a@redhat.com> References: <67e3e2fb-0d57-793f-5bae-2395dfdd828a@redhat.com> Message-ID: On Fri, Feb 24, 2017 at 2:31 AM, Standa Laznicka wrote: > Hello, > I don't quite understand your situation - have the error happened during an > addition of the host to the "ipaservers" group or during replica > installation? It was during the addition of the host. In fact, any 'ipa' command fails with the same error, even 'ipa help'. I could understand if the CA needs to be setup before these commands work, but then I'm pretty sure I followed the order of the instructions for creating a replica and this was the result. Interestingly, when I first started to do this, I had other failures related to the directory level. I later realized that it's because I was trying to create the replica on the test VM that I hadn't yet upgraded from RHEL6 to RHEL7 so was trying to use IPA 3.x. In that instance, the command to add the soon-to-be replica to ipaservers succeeded, but the command to create the replica failed with needing the replica file (which I later realized what was going on and reinstalled the VM as I intended originally). > Certutil is a wonderful piece of software that returns > "(SEC_ERROR_LEGACY_DATABASE)" in about 90% of most common cases but I have > never seen an actual legacy database. Usually, this error means that the > directory you're pointing the certutil tool to either does not exist or you > don't have the permissions to read/write in this exact directory. Everything else on the server seems to be working fine, and the error containing the URL to the running server leads me to believe it's a problem with communication between the two. However there is no firewalling on either host (yet) so I'm not sure why they wouldn't be able to communicate. I did run an strace of the process and didn't see anything highly useful, in fact the only connect syscall I saw was to the socket of the local nscd. Debug output of 'ipa -d help': ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at ASTRO.PRINCETON.EDU ipa: DEBUG: Process finished, return code=1 ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at ASTRO.PRINCETON.EDU' ipa: INFO: trying https://ipa.astro.princeton.edu/ipa/json ipa: DEBUG: Created connection context.rpcclient_49093200 ipa: INFO: Forwarding 'schema' to json server 'https://ipa.astro.princeton.edu/ipa/json' ipa: DEBUG: NSSConnection init ipa.astro.princeton.edu ipa: DEBUG: Destroyed connection context.rpcclient_49093200 ipa: ERROR: cannot connect to 'https://ipa.astro.princeton.edu/ipa/json': (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. > Cheers, > Standa > > P.S.: I might have sent you this email twice because I am a bad person when > it comes to the "Send" button, please reply to the email which has > "freeipa-users" in CC :) No worries :D > On 02/23/2017 10:38 PM, Steve Huston wrote: >> >> I already had to do that previously to get other things to work; I had >> solved it by changing line 582 of >> /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from >> "::1" to "localhost" before installing the server. I did do this on >> the to-be-promoted client as well, to no avail. >> >> On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden >> wrote: >>> >>> Steve Huston wrote: >>>> >>>> Next stage of my testing was to make a replica of the FreeIPA server, >>>> and I started by doing a 'yum install ipa-server' and then moved on to >>>> adding the host to the ipaservers group. This fails every time >>>> however, with the error: >>>> >>>> ipa: ERROR: cannot connect to >>>> 'https://ipa.astro.princeton.edu/ipa/json': >>>> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, >>>> unsupported format. >>>> >>>> Searches on this seem to turn up things like expired certificates, or >>>> "reboot httpd" (I went ahead and rebooted the whole ipa server), but >>>> nothing concrete. Suggestions? Everything (server and soon-to-be >>>> replica) running RHEL7.3 with all updates. >>>> >>> See the workaround in >>> https://fedorahosted.org/freeipa/ticket/6575#comment:9 >>> >>> rob >> >> >> > -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From h.elavia at atomiccartoons.com Fri Feb 24 13:30:48 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Fri, 24 Feb 2017 13:30:48 +0000 Subject: [Freeipa-users] Default domain for AD groups In-Reply-To: <20170224060443.m7qrfxcpzj6cnqxr@redhat.com> References: <20170224060443.m7qrfxcpzj6cnqxr@redhat.com> Message-ID: Thanks Alexander!! On Fri, Feb 24, 2017 at 6:04 AM, Alexander Bokovoy wrote: > On to, 23 helmi 2017, Hanoz Elavia wrote: > >> Hello, >> >> My FreeIPA clients and server are setup to use the AD domain as the >> default. This is done using the default_domain_suffix parameter in the >> sssd >> section of the sssd.conf file. >> >> This works fine for users when we use ldapsearch but not so much for >> groups. For e.g.: >> >> ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b >> 'cn=compat,dc=ipa,dc=server,dc=com' -D >> 'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' '(cn= >> domaingroup at server.com)' >> >> works fine but >> >> ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b >> 'cn=compat,dc=ipa,dc=server,dc=com' -D >> 'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' >> '(cn=domaingroup)' >> >> won't work. However, the above will work fine for users. I'm using the >> > No, compat tree is designed to be used with fully-qualified groups and > users. There is no way around it. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Fri Feb 24 13:38:46 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Fri, 24 Feb 2017 08:38:46 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> Message-ID: On 02/24/2017 03:33 AM, Kees Bakker wrote: > On 23-02-17 15:39, Brendan Kearney wrote: >> On 02/23/2017 09:11 AM, Kees Bakker wrote: >>> On 23-02-17 13:51, Brendan Kearney wrote: >>>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>>> Hey, >>>>>>>>>>> >>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>>>> >>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>>> >>>>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>>>> only sees question marks as shown below. >>>>>>>>>>> >>>>>>>>>>> The mount command is simple. >>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>>> >>>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>>> >>>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>>> >>>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>>> total 0 >>>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>>> >>>>>>>>>>> $ ls -l /nfshome >>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>>> >>>>>>>>>> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) >>>>>>>>> Thanks for the reply. >>>>>>>>> >>>>>>>>> In this case the user _is_ authenticated. >>>>>>>>> keesb at client1:~$ klist >>>>>>>>> Ticket cache: KEYRING:persistent:60001:60001 >>>>>>>>> Default principal: keesb at EXAMPLE.COM >>>>>>>>> >>>>>>>>> Valid starting Expires Service principal >>>>>>>>> 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>>>>> no, the user has a TGT. a nfs/host.domain.tld at REALM ticket is needed to authenticate. >>>>>>> (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) >>>>>>> >>>>>>>>> What other grants could be needed? HBAC Rules? >>>>>>>>> >>>>>>>>> Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it >>>>>>>>> doesn't help to get access for the user.) >>>>>>>> there are principals to create and keytabs to be updated on hte NFS sever, if not done already. >>>>>>> I did create a principal for the NFS server (using ipa service-add) and >>>>>>> add to the keytab on the NFS server (using ipa-getkeytab) ... >>>>>>> root at srv1# klist -ke >>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>> KVNO Principal >>>>>>> ---- -------------------------------------------------------------------------- >>>>>>> 1 host/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>> 1 host/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>> 1 nfs/srv1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>> >>>>>>> Is this what you mean? >>>>>> yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? >>>>> I don't think that a change of idmapd.conf (on the NFS server) is needed because all host >>>>> names are FQDN and everything is in one and the same REALM. >>>> NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. >>> Both the NFS server and the client are configured as FreeIPA client. >>> On the server the users are known (through PAM, SSSD). Only user >>> "ubuntu" is a local (/etc/passwd) user. All other users are defined on >>> the IPA server. >>> >>> root at srv1:~# ls -l /home >>> total 0 >>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>> drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu >>> root at srv1:~# ls -ln /home >>> total 0 >>> drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb >>> drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu >>> >>> On the client, same story >>> >>> root at client1:~# ls -l /nfshome >>> total 0 >>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>> drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu >>> root at client1:~# ls -ln /nfshome >>> total 0 >>> drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb >>> drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu >>> >>> >>> >>>>>>>> then the user should be able to pull the ticket for auth. >>>>>>> Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? >>>>>>> >>>>>>> keesb at client1$ kinit nfs/srv1.example.com at EXAMPLE.COM >>>>>>> Password for nfs/srv1.example.com at EXAMPLE.COM: >>>>>>> >>>>>>> But I don't have a password for that. Hmm. >>>>>> there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. >>>>> OK >>>>> So, it seems to me that all the basics are setup correctly. The mount succeeds. The user >>>>> has a TGT and still the (non-root) user cannot even stat the mount point, nor the directory >>>>> entry itself. >>>>> >>>>> What puzzles me is that root can see everything, also without a TGT. >>>> the mount will succeed, but the user does not have access because NFS does not know who the user it. it has an unassociated ID established by kerberos, but not a user. >>> Let's step back a little. >>> >>> On the NFS client, the user does an ls of / (that's where the mountpoint is). At the point >>> where ls reads the entry (through stat) for "nfshome" it gets (probably) EPERM. >>> And hence ls prints all the question marks. That leads me to believe that only the kernel >>> (on the NFS client) is involved at this point. I could be wrong but I don't think there is >>> any kerberos TGT involved. >>> >>>>>>>>> Furthermore, I'm guessing that the host principle which I got after ipa-client-install is >>>>>>>>> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I >>>>>>>>> did not do.) >>>>>>>>> # klist -ke >>>>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>>>> KVNO Principal >>>>>>>>> ---- -------------------------------------------------------------------------- >>>>>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>>>> 1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>>>> >>>>>>>>> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>>>>>>>> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ >>>>>>>> http://www.itp.uzh.ch/~dpotter/howto/kerberos >>>>>>>> >>>> added the thread back to the mailing list for the benefit of any who search on the subject. >>>> >>>> >> run journalctl -fl on both the NFS server and the NFS client while trying to mount the share. one of them should tell you something. > Nothing much. On the server I just see > > feb 23 15:47:34 srv1.example.com rpc.mountd[22742]: authenticated mount request from 172.16.16.39:678 for /home (/home) > > The mount succeeds. Simple as that. Mounting is not the problem, I think. > > > >> the mount operation will succeed, because any ACL set in the exports file is being met. root likley has access because the uid/gid is common and local on both devices and therefore no mapping is needed. > OK. No problem with that. > >> your virtual user does not exist in either local user store, and therefore needs to be mapped. > No, no, the virtual user is present on both sides, because both NFS server and client are configured > as IPA client. That user can login on both systems. The uid/gid mapping is straightforward. does "grep /etc/passwd" return a line with the virtual user info from both client and server? likely not, because the user is a virtual user, and not a local user. if/since there is no local mapping in passwd, you need to have mapping done. that is done with /etc/idmapd.conf. > >> what does /etc/nsswitch.conf say for passwd, shadow and group? >> > On both server and client: > passwd: compat sss > group: compat sss > shadow: compat sss > From jhrozek at redhat.com Fri Feb 24 15:44:23 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 24 Feb 2017 16:44:23 +0100 Subject: [Freeipa-users] New user group not shown on IPA client In-Reply-To: References: Message-ID: <20170224154423.5hbagexucdultmiy@hendrix> On Fri, Feb 24, 2017 at 12:36:03PM +0100, Gerald Zabos wrote: > Hello *, > > i just created a new user group 'it_testusers' (90600008) on one of > the IPA servers and added three existing users: > > 'test' (90600005) > 'ipajoin' (90600001) > 'ldaptest' (90600003). > > When look up the group membership of these users on one of our IPA > clients with 'id ' it shows uid, gid and groups=, but > the new group 'it_testusers' is still missing. > > Looking up group membership with 'id ' on all of our IPA > servers works, i can see the new group in the list of user's groups. > > Server OS: Redhat 7.3 > ipa-server: ipa-server-4.4.0-14.el7_3.4 > > Client OS: CentOS 7.3 > ipa-client: ipa-client-4.4.0-14.el7.centos.4 > > I've read https://www.redhat.com/archives/freeipa-users/2015-May/msg00463.html > as it seems to be a similar problem. > > I stopped sssd, removed the files in /var/lib/sss/db and started sssd > on the client -> still can't see the new group > > I rebooted the client -> still can't see the new group I'm afraid you need to look into sssd logs on the client: https://fedorahosted.org/sssd/wiki/Troubleshooting From pvoborni at redhat.com Fri Feb 24 15:55:31 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 24 Feb 2017 16:55:31 +0100 Subject: [Freeipa-users] WEB UI - wrong fonts or incomplete page loaded In-Reply-To: References: Message-ID: <0eee2153-0e38-335e-2352-d7089802d976@redhat.com> On 02/24/2017 12:15 PM, Iulian Roman wrote: > Hello, > > After a successful installation of the ipa-server when i try to login via WEB UI > i've noticed that the web page looks strange (wrong fonts and page seems not > completely/correctly loaded). > The network debugger in chrome/firefox does So it won't be browser or extension related. The only possibility is to have same extension on both browsers. > display 2 errors : > > - json /ipa/session/ 401 Unauthorized This is expected. > - login _kerberos?=... net::ERR_ACCESS_DENIED This one should return also "401 Unauthorized" if you don't have SSO configured on browser or SSO(kerberos) ticket. net::ERR_ACCESS_DENIED indicates something wrong. Maybe some other software interferes in the communication with server. What OS it is? Could there be an overzealous antivirus (the web check part). Or maybe a custom proxy setting? > > I do not intend to use SSO for login into WEBUI (although it is the default in > the ipa version i am using) but apparently a supported method to disable it is > not known. Right, it is not currently possible. I've opened RFE ticket. https://fedorahosted.org/freeipa/ticket/6709 Please comment if you use case is different than the proposed user story. > I can login with user and password but the WEB UI is almost unusable > because of wrongly loaded page . I wonder if something did not temper in the loaded files. If all files are loaded correctly and if it is fresh install(to mitigate possibility of old cache) then it is weird. Maybe it is the antivirus. Do you have some Web UI plugin installed on IPA server? > > > Did anyone experience the same issue and is there any fix/solution for that ? > -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. From iulian.roman at gmail.com Fri Feb 24 16:13:43 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Fri, 24 Feb 2017 17:13:43 +0100 Subject: [Freeipa-users] WEB UI - wrong fonts or incomplete page loaded In-Reply-To: <0eee2153-0e38-335e-2352-d7089802d976@redhat.com> References: <0eee2153-0e38-335e-2352-d7089802d976@redhat.com> Message-ID: On Fri, Feb 24, 2017 at 4:55 PM, Petr Vobornik wrote: > On 02/24/2017 12:15 PM, Iulian Roman wrote: > >> Hello, >> >> After a successful installation of the ipa-server when i try to login via >> WEB UI >> i've noticed that the web page looks strange (wrong fonts and page seems >> not >> completely/correctly loaded). >> > > > The network debugger in chrome/firefox does >> > > So it won't be browser or extension related. The only possibility is to > have same extension on both browsers. > > display 2 errors : >> >> - json /ipa/session/ 401 Unauthorized >> > > This is expected. > > - login _kerberos?=... net::ERR_ACCESS_DENIED >> > > This one should return also "401 Unauthorized" if you don't have SSO > configured on browser or SSO(kerberos) ticket. > > net::ERR_ACCESS_DENIED indicates something wrong. Maybe some other > software interferes in the communication with server. > > What OS it is? Could there be an overzealous antivirus (the web check > part). Or maybe a custom proxy setting? > it behaves the same from all browsers (firefox,chrome) and from both Linux and windows. i do use proxy, but trying with the firefox directly from the ipa server - therefore without proxy - does have the same result. > > >> I do not intend to use SSO for login into WEBUI (although it is the >> default in >> the ipa version i am using) but apparently a supported method to >> disable it is >> not known. >> > > Right, it is not currently possible. I've opened RFE ticket. > https://fedorahosted.org/freeipa/ticket/6709 Please comment if you use > case is different than the proposed user story. > > I can login with user and password but the WEB UI is almost unusable >> because of wrongly loaded page . >> > > I wonder if something did not temper in the loaded files. If all files are > loaded correctly and if it is fresh install(to mitigate possibility of old > cache) then it is weird. Maybe it is the antivirus. > i wonder too. the strange thing is that from the same browser i can access properly a different ipa server (which i've configured some time ago). > > Do you have some Web UI plugin installed on IPA server? it is default installation. How can i check which plugins are installed ? > > > >> >> Did anyone experience the same issue and is there any fix/solution for >> that ? >> >> > > -- > Petr Vobornik > > Associate Manager, Engineering, Identity Management > Red Hat, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Feb 24 16:41:26 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 24 Feb 2017 17:41:26 +0100 Subject: [Freeipa-users] WEB UI - wrong fonts or incomplete page loaded In-Reply-To: References: <0eee2153-0e38-335e-2352-d7089802d976@redhat.com> Message-ID: <08088ee6-c29c-d822-1ffc-65fe8e245aa3@redhat.com> On 02/24/2017 05:13 PM, Iulian Roman wrote: > > > On Fri, Feb 24, 2017 at 4:55 PM, Petr Vobornik > wrote: > > On 02/24/2017 12:15 PM, Iulian Roman wrote: > > Hello, > > After a successful installation of the ipa-server when i try to login > via WEB UI > i've noticed that the web page looks strange (wrong fonts and page seems not > completely/correctly loaded). > > > > The network debugger in chrome/firefox does > > > So it won't be browser or extension related. The only possibility is to have > same extension on both browsers. > > display 2 errors : > > - json /ipa/session/ 401 Unauthorized > > > This is expected. > > - login _kerberos?=... net::ERR_ACCESS_DENIED > > > This one should return also "401 Unauthorized" if you don't have SSO > configured on browser or SSO(kerberos) ticket. > > net::ERR_ACCESS_DENIED indicates something wrong. Maybe some other software > interferes in the communication with server. > > What OS it is? Could there be an overzealous antivirus (the web check > part). Or maybe a custom proxy setting? > > > it behaves the same from all browsers (firefox,chrome) and from both Linux and > windows. i do use proxy, but trying with the firefox directly from the ipa > server - therefore without proxy - does have the same result. > > > > I do not intend to use SSO for login into WEBUI (although it is the > default in > the ipa version i am using) but apparently a supported method to > disable it is > not known. > > > Right, it is not currently possible. I've opened RFE ticket. > https://fedorahosted.org/freeipa/ticket/6709 > Please comment if you use > case is different than the proposed user story. > > I can login with user and password but the WEB UI is almost unusable > because of wrongly loaded page . > > > I wonder if something did not temper in the loaded files. If all files are > loaded correctly and if it is fresh install(to mitigate possibility of old > cache) then it is weird. Maybe it is the antivirus. > > i wonder too. the strange thing is that from the same browser i can access > properly a different ipa server (which i've configured some time ago). > > > Do you have some Web UI plugin installed on IPA server? > > > it is default installation. How can i check which plugins are installed ? Plugins are in /usr/share/ipa/ui/js/plugins/ if the directory is empty then there is no plugin. But plugin would not cause: login _kerberos?=... net::ERR_ACCESS_DENIED > > > > > > Did anyone experience the same issue and is there any fix/solution for > that ? > > > > -- > Petr Vobornik > > Associate Manager, Engineering, Identity Management > Red Hat, Inc. > > -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. From michael at stroeder.com Fri Feb 24 17:21:22 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 24 Feb 2017 18:21:22 +0100 Subject: [Freeipa-users] support for rfc2307AIX schema in IPA server In-Reply-To: References: <7e109b94-38bd-2608-9e26-a945d7f5c33d@redhat.com> <120e6725-3891-6bbd-5ae3-7ad187a872e2@stroeder.com> <430f2a60-3f95-150d-3b42-b2ade5c2ce33@stroeder.com> Message-ID: <75cdd7b1-3a50-a54b-90e7-8f8b8b3bef2b@stroeder.com> Iulian Roman wrote: > Michael Str?der wrote: >> Being in your position I'd first compile a list of functional and security >> requirements and ask then whether these requirements can be implemented with >> FreeIPA. I'm curious to learn whether "some other security related attributes" are >> still needed after all. > > It is not a matter if they increase the security or not or if they are really needed, > but a matter of complying to some security standards agreed between two parties . It > would be easy to keep them in the same format than to change the security standard , > tooling and processes behind (bureaucracy , overhead and complexity of the enterprise > environment makes me try to avoid that as much as possible , especially when there are > many people and departments involved , with their own mindset and playing different > politics). Sounds like the usual IAM business - nothing special. Still my recommendation would to go the route to list the requirements and implement them in with methods native in the IAM system of your choice (here FreeIPA). This might look harder in the beginning but pays off pretty soon. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From huston at astro.princeton.edu Fri Feb 24 19:38:03 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Fri, 24 Feb 2017 14:38:03 -0500 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: <1258208599.155271.1487945118957.JavaMail.root@ap0605.com> References: <1258208599.155271.1487945118957.JavaMail.root@ap0605.com> Message-ID: So, I tried a different tack. Took my bare VM configured as an IPA client, did a 'yum install ipa-server' and edited the cainstance.py file to fix the IPv6 issue. Then, without adding the host to ipaservers in the webui, I simply tried to promote it: # kinit admin Password for admin at ASTRO.PRINCETON.EDU: # ipa-replica-install --verbose ipa.ipapython.install.cli.install_tool(Replica): DEBUG Logging to /var/log/ipareplica-install.log ipa.ipapython.install.cli.install_tool(Replica): DEBUG ipa-replica-install was invoked with arguments [] and options: {'no_dns_sshfp': None, 'skip_schema_check': None, 'setup_kra': None, 'ip_addresses': None , 'mkhomedir': None, 'http_cert_files': None, 'ssh_trust_dns': None, 'reverse_zones': None, 'no_forwarders': None, 'keytab': None, 'no_ntp': None, 'domain_name': None, 'http_cert_name': None, 'dirsrv_cert_files ': None, 'no_dnssec_validation': None, 'no_reverse': None, 'unattended': False, 'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, 'no_sshd': None, 'no_ui_redirect': None, 'dirsrv_config_file': None, 'forwarders': None, 'verbose': True, 'setup_ca': None, 'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, 'forward_policy': None, 'dirsrv_cert_name': None, 'quiet': False, 'server': None, 'setup_dns': None, 'host_name': None, 'log_file': None, 'allow_zone_overlap': None} ipa.ipapython.install.cli.install_tool(Replica): DEBUG IPA version 4.4.0-14.el7_3.4 ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/selinuxenabled ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' ipa : DEBUG httpd is not configured ipa : DEBUG kadmin is not configured ipa : DEBUG dirsrv is not configured ipa : DEBUG pki-tomcatd is not configured ipa : DEBUG install is not configured ipa : DEBUG krb5kdc is not configured ipa : DEBUG ntpd is not configured ipa : DEBUG named is not configured ipa : DEBUG ipa_memcached is not configured ipa : DEBUG filestore is tracking no files ipa : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' ipa : DEBUG Configuring client side components Configuring client side components ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/ipa-client-install --unattended --no-ntp IPA client is already configured on this system. If you want to reinstall the IPA client, uninstall it first using 'ipa-client-install --uninstall'. ipa : DEBUG Process finished, return code=3 Removing client side components ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/ipa-client-install --unattended --uninstall Unenrolling client from IPA server Removing Kerberos service principals from /etc/krb5.keytab Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted nslcd daemon is not installed, skip configuration Client uninstall complete. ipa : DEBUG Process finished, return code=0 ipa.ipapython.install.cli.install_tool(Replica): 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/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 308, in run self.validate() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 317, in validate for nothing in self._validator(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 564, in _configure next(validator) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1712, in main promote_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 364, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 386, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1004, in promote_check ensure_enrolled(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 958, in ensure_enrolled sys.exit("Configuration of client side components failed!") ipa.ipapython.install.cli.install_tool(Replica): DEBUG The ipa-replica-install command failed, exception: SystemExit: Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(Replica): ERROR Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Looks like it's unenrolling the machine, then trying to enroll it again? I also tried again with --server, --realm, --hostname, and --domain options set appropriately but it made no difference. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From iulian.roman at gmail.com Fri Feb 24 20:24:54 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Fri, 24 Feb 2017 21:24:54 +0100 Subject: [Freeipa-users] WEB UI - wrong fonts or incomplete page loaded In-Reply-To: <08088ee6-c29c-d822-1ffc-65fe8e245aa3@redhat.com> References: <0eee2153-0e38-335e-2352-d7089802d976@redhat.com> <08088ee6-c29c-d822-1ffc-65fe8e245aa3@redhat.com> Message-ID: On Fri, Feb 24, 2017 at 5:41 PM, Petr Vobornik wrote: > On 02/24/2017 05:13 PM, Iulian Roman wrote: > >> >> >> On Fri, Feb 24, 2017 at 4:55 PM, Petr Vobornik > > wrote: >> >> On 02/24/2017 12:15 PM, Iulian Roman wrote: >> >> Hello, >> >> After a successful installation of the ipa-server when i try to >> login >> via WEB UI >> i've noticed that the web page looks strange (wrong fonts and >> page seems not >> completely/correctly loaded). >> >> >> >> The network debugger in chrome/firefox does >> >> >> So it won't be browser or extension related. The only possibility is >> to have >> same extension on both browsers. >> >> display 2 errors : >> >> - json /ipa/session/ 401 Unauthorized >> >> >> This is expected. >> >> - login _kerberos?=... net::ERR_ACCESS_DENIED >> >> >> This one should return also "401 Unauthorized" if you don't have SSO >> configured on browser or SSO(kerberos) ticket. >> >> net::ERR_ACCESS_DENIED indicates something wrong. Maybe some other >> software >> interferes in the communication with server. >> >> What OS it is? Could there be an overzealous antivirus (the web check >> part). Or maybe a custom proxy setting? >> >> >> it behaves the same from all browsers (firefox,chrome) and from both >> Linux and >> windows. i do use proxy, but trying with the firefox directly from the ipa >> server - therefore without proxy - does have the same result. >> >> >> >> I do not intend to use SSO for login into WEBUI (although it is >> the >> default in >> the ipa version i am using) but apparently a supported method to >> disable it is >> not known. >> >> >> Right, it is not currently possible. I've opened RFE ticket. >> https://fedorahosted.org/freeipa/ticket/6709 >> Please comment if you >> use >> case is different than the proposed user story. >> >> I can login with user and password but the WEB UI is almost >> unusable >> because of wrongly loaded page . >> >> >> I wonder if something did not temper in the loaded files. If all >> files are >> loaded correctly and if it is fresh install(to mitigate possibility >> of old >> cache) then it is weird. Maybe it is the antivirus. >> >> i wonder too. the strange thing is that from the same browser i can access >> properly a different ipa server (which i've configured some time ago). >> >> >> Do you have some Web UI plugin installed on IPA server? >> >> >> it is default installation. How can i check which plugins are installed ? >> > > > Plugins are in /usr/share/ipa/ui/js/plugins/ if the directory is empty > then there is no plugin. > > i've just checked and there are no plugins installed. > But plugin would not cause: > login _kerberos?=... net::ERR_ACCESS_DENIED indeed, but what would cause that ? it quite strange and i am almost clueless. i try to narrow it down and in my opinion the issues is most probably on the server side, but i have no evidence for that so far. > > > >> >> >> >> >> Did anyone experience the same issue and is there any >> fix/solution for >> that ? >> >> >> >> -- >> Petr Vobornik >> >> Associate Manager, Engineering, Identity Management >> Red Hat, Inc. >> >> >> > > -- > Petr Vobornik > > Associate Manager, Engineering, Identity Management > Red Hat, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arequipeno at gmail.com Sat Feb 25 23:45:35 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Sat, 25 Feb 2017 17:45:35 -0600 Subject: [Freeipa-users] CentOS 6 -> 7 migration Message-ID: Is there any way to migrate an IPA server from 6 -> 7 without losing all of the IPA configuration and data? All of the documentation I can find involves setting up a replica, replicating the data over, and then decommissioning the old system; not exactly an option with a single system. -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From jochen at jochen.org Sun Feb 26 06:23:32 2017 From: jochen at jochen.org (Jochen Hein) Date: Sun, 26 Feb 2017 07:23:32 +0100 Subject: [Freeipa-users] named-pkcs11: option 'serial_autoincrement' is not supported, ignoring Message-ID: <83innxqxln.fsf@jochen.org> I'm implementing logcheck on my server and found the following message in my logs: > Feb 26 05:30:26 freeipa2 named-pkcs11[4935]: option 'serial_autoincrement' is not supported, ignoring >From reading http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation there was an implementation in IPA, but it has been changed to 'serial_remote': ,---- | Feature Management | | Add new option like serial_remote to /etc/named.conf. This option should be mutually exclusive with serial_autoincrement option from IPA 3.0. | Do not create UI for enabling/disabling this feature. We can provide some boolean directly in plugin configuration, but nothing else. | | Replication | | No change from IPA 3.0. | Updates and Upgrades | | Replace serial_autoincrement option in /etc/named.conf with serial_remote option. | Dependencies `---- My servers started with FreeIPA 4 - is there some configuration/upgrade change missing? Jochen -- The only problem with troubleshooting is that the trouble shoots back. From jochen at jochen.org Sun Feb 26 06:35:08 2017 From: jochen at jochen.org (Jochen Hein) Date: Sun, 26 Feb 2017 07:35:08 +0100 Subject: [Freeipa-users] named-pkcs11: option 'serial_autoincrement' is not supported, ignoring In-Reply-To: <83innxqxln.fsf@jochen.org> (Jochen Hein's message of "Sun, 26 Feb 2017 07:23:32 +0100") References: <83innxqxln.fsf@jochen.org> Message-ID: <83efylqx2b.fsf@jochen.org> Jochen Hein writes: > I'm implementing logcheck on my server and found the following message > in my logs: > >> Feb 26 05:30:26 freeipa2 named-pkcs11[4935]: option 'serial_autoincrement' is not supported, ignoring > | Updates and Upgrades > | > | Replace serial_autoincrement option in /etc/named.conf with serial_remote option. > | Dependencies > `---- I just tried that and got a message that serial_remote is unknown. I run a current CentOS 7.3 server. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From jochen at jochen.org Sun Feb 26 06:37:19 2017 From: jochen at jochen.org (Jochen Hein) Date: Sun, 26 Feb 2017 07:37:19 +0100 Subject: [Freeipa-users] named-pkcs11: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute; cnamerecord': unknown class/type Message-ID: <83a899qwyo.fsf@jochen.org> When reloading named I get the following message 8 times: Feb 26 05:30:27 freeipa2 named-pkcs11[4935]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type I do have cnames in my zones, but what is missing here? DNS seems to work fine for CNAMEs. I'm running CentOS 7.3. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From peljasz at yahoo.co.uk Sun Feb 26 10:35:28 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Sun, 26 Feb 2017 10:35:28 +0000 Subject: [Freeipa-users] unable to decode: {replica Message-ID: <5907f1b4-c87b-0217-d4a3-878dcf36b395@yahoo.co.uk> hi everyone I first time see: unable to decode: {replica 60} 586eaffd000a003c0000 586eaffd000a003c0000 Replica Update Vectors: .... on all four servers. What would be a correct troubleshooting and fixing this problem? many thanks, L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Sun Feb 26 11:08:36 2017 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Sun, 26 Feb 2017 12:08:36 +0100 Subject: [Freeipa-users] CentOS 6 -> 7 migration In-Reply-To: References: Message-ID: Upgrading centos6 to 7 is not a smart thing, unless you like to suffer a lot of issues. Then there are many comaptibility issues regarding the upgrade from ipa3.3 to 4.4 You should consider setting up a temporary vm to migrate from. On one of your client systems, I assume you got at least 1 ipa client Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your current system to a vm (side effect : instant full backup) When you got the vm up and running you can reinstall your main system with the new os and ipa. Then replicate the old ipa to the new one. Rob Verduijn 2017-02-26 0:45 GMT+01:00 Ian Pilcher : > Is there any way to migrate an IPA server from 6 -> 7 without losing all > of the IPA configuration and data? All of the documentation I can find > involves setting up a replica, replicating the data over, and then > decommissioning the old system; not exactly an option with a single > system. > > -- > ======================================================================== > Ian Pilcher arequipeno at gmail.com > -------- "I grew up before Mark Zuckerberg invented friendship" -------- > ======================================================================== > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arequipeno at gmail.com Sun Feb 26 13:40:04 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Sun, 26 Feb 2017 07:40:04 -0600 Subject: [Freeipa-users] CentOS 6 -> 7 migration In-Reply-To: References: Message-ID: On 02/26/2017 05:08 AM, Rob Verduijn wrote: > You should consider setting up a temporary vm to migrate from. > On one of your client systems, I assume you got at least 1 ipa client > > Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your > current system to a vm (side effect : instant full backup) > > When you got the vm up and running you can reinstall your main system > with the new os and ipa. > Then replicate the old ipa to the new one. Hmm. The system that runs IPA is the "network server" in my home network. It runs various services -- DNS, NTP, CUPS, squid, etc. -- as well as routing between various VLANs. So simply P2V'ing it would be a major project in its own right. What about this, though ... 1. Set up a new CentOS 7 VM running IPA 2. Replicate the IPA data from the old CentOS 6 system to the VM. 3. Install CentOS 7 on the original system 4. Replicate the IPA data back from the VM Will this work? -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From rob.verduijn at gmail.com Sun Feb 26 15:58:33 2017 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Sun, 26 Feb 2017 16:58:33 +0100 Subject: [Freeipa-users] CentOS 6 -> 7 migration In-Reply-To: References: Message-ID: Sounds feasable, however I'm not sure which solution entails the most work. In step 3 you loose all the extra functionalities( cups/squid/ntp ) as well, while these stay preserved by a p2v including a nice backup. You do need a backup of all the functions before proceeding with step3. Rob Verduijn 2017-02-26 14:40 GMT+01:00 Ian Pilcher : > On 02/26/2017 05:08 AM, Rob Verduijn wrote: > >> You should consider setting up a temporary vm to migrate from. >> On one of your client systems, I assume you got at least 1 ipa client >> >> Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your >> current system to a vm (side effect : instant full backup) >> >> When you got the vm up and running you can reinstall your main system >> with the new os and ipa. >> Then replicate the old ipa to the new one. >> > > Hmm. The system that runs IPA is the "network server" in my home > network. It runs various services -- DNS, NTP, CUPS, squid, etc. -- as > well as routing between various VLANs. So simply P2V'ing it would be > a major project in its own right. > > What about this, though ... > > 1. Set up a new CentOS 7 VM running IPA > > 2. Replicate the IPA data from the old CentOS 6 system to the VM. > > 3. Install CentOS 7 on the original system > > 4. Replicate the IPA data back from the VM > > Will this work? > > -- > ======================================================================== > Ian Pilcher arequipeno at gmail.com > -------- "I grew up before Mark Zuckerberg invented friendship" -------- > ======================================================================== > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at marketfactory.com Sun Feb 26 18:33:01 2017 From: ayoung at marketfactory.com (Aaron Young) Date: Sun, 26 Feb 2017 13:33:01 -0500 Subject: [Freeipa-users] authenticating with dns In-Reply-To: References: Message-ID: learned some things in the last few days I believe one of the root problems I have, if not THE root problem, is that I cannot start pki-tomcatd on my nyc01ipa02 machine. I now believe that if I could get that machine to work correctly, I could get all the others So, I get this in my logs from /var/log/pki/pki-tomcat/ca/debug > LdapJssSSLSocket: set client auth cert nickname subsystemCert cert-pki-ca > SSLClientCertificatSelectionCB: Entering! > Candidate cert: subsystemCert cert-pki-ca > SSLClientCertificateSelectionCB: desired cert found in list: subsystemCert > cert-pki-ca > SSLClientCertificateSelectionCB: returning: subsystemCert cert-pki-ca > SSL handshake happened > Could not connect to LDAP server host nyc01ipa02.mf port 636 Error > netscape.ldap.LDAPException: Authentication failed (49) from /var/log/dirsrv/slapd-MF/errors > slapi_search_internal ("o=ipaca", subtree, seeAlso=CN=CA Subsystem,O=MF) > err 32 which makes me think that the problem is the CA Subsystem secret isn't available when I do a "getcert list" I see that there are 8 keys certificate: 'auditSigningCert certificate: 'ocspSigningCert certificate: 'subsystemCert certificate: 'caSigningCert certificate: 'ipaCert' certificate: 'Server-Cert certificate: 'Server-Cert' certificate: 'Server-Cert' should there be others? also, I found this link https://fedorahosted.org/freeipa/ticket/5100#comment:9 and this person outlined the a number of steps (I included them below) and they seem reasonable to fix a problem like I'm experiencing...however, I don't know how to do step 1. If anyone knows how to do that...? 1. Make changes to cause FreeIPA to think it is CA-less. 1. Extract CA signing key from a replica info file. 1. Run ipa-ca-install to install the CA on one of the IPA servers, with external CA. This will generate a new private key and CSR to send to external CA. 1. Replace the new private key generated for the CSR, with the private key from the replica info file. 1. Continue the ipa-ca-install with the CA signing certificate from the replica info file. 1. Manually adjust serial number ranges to ensure the new CA instance does not issue certs with serial numbers that collide with certs issued by the original CA instance. (This might have to be hacked into the ipa-ca-install process). 1. Depending on whether your CA is self-signed, might need to tell certmonger to track the CA signing certificate. On Thu, Feb 23, 2017 at 11:57 AM, Aaron Young wrote: > And yes, I learned to stop using kadmin after I made that note > > On Thu, Feb 23, 2017 at 11:56 AM, Aaron Young > wrote: > >> on ld4ipa01, I removed it with ipa-server-install --uninstall >> >> this was an attempt to recreate the replica from nyc02ipa02 >> >> On Thu, Feb 23, 2017 at 3:17 AM, Martin Basti wrote: >> >>> >>> >>> On 22.02.2017 23:26, Aaron Young wrote: >>> >>> Hello Everyone >>> >>> I recently lost the master master IPA server setup by the previous >>> administrator. >>> As it stands now, if I try to add a new client, in order to standup a >>> new replica, I get errors while trying to setup DNS. This led me to look at >>> how authentication worked (I'm new to IPA) and I learned about the kerberos >>> tools >>> >>> I don't know if I'm familiar enough with the terminology to adequately >>> describe what I'm experiencing, so I'll give you some of the commands and >>> their results >>> >>> but first, a bit on the design >>> >>> before I got to this, we had >>> >>> a <-> b <-> c <-> d >>> >>> b was the master master >>> >>> a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 (not >>> pictured, I discovered them later when c and d started having problems) >>> >>> a - nyc01ipa02 >>> b - nyc01ipa01 >>> c - ld4ipa01 >>> d - ld4ipa02 >>> >>> currently, I have nyc02ipa02 <-> nyc01ipa02 >>> >>> the reason I have it limited like this is because all the other servers >>> stopped replicating for one reason or another (mainly that they can't >>> authenticate or in one case, there was a database record corruption) >>> >>> Anyway, here are some activities and logs from the latest round of fixes >>> and information activities I've been engaging in >>> >>> 22:54:32 root at nyc01ipa02:~# kinit admin >>> kinit: Clients credentials have been revoked while getting initial >>> credentials >>> >>> Reading through this >>> tells me >>> that >>> >>> # kadmin: modprinc -unlock PRINCNAME >>> >>> will unlock an account...but if I can't get in.... >>> >>> 22:54:37 root at nyc01ipa02:~# kadmin >>> Authenticating as principal root/admin at MF with password. >>> kadmin: Client 'root/admin at MF' not found in Kerberos database while >>> initializing kadmin interface >>> >>> on ld4ipa02, did a >>> >>> # ipa-client-install --uninstall >>> >>> then >>> >>> # ipa-client-install --force-join --enable-dns-updates --permit -f >>> --ssh-trust-dns --request-cert --automount-location=LD4 --enable-dns-updates >>> >>> DNS did not update, here is the relevant portion from >>> /var/log/ipaclient-install.log >>> >>> 2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt: >>> 2017-02-20T18:46:49Z DEBUG debug >>> >>> update delete ld4ipa02.mf. IN A >>> show >>> send >>> >>> update delete ld4ipa02.mf. IN AAAA >>> show >>> send >>> >>> update add ld4ipa02.mf. 1200 IN A 10.102.100.140 >>> show >>> send >>> >>> 2017-02-20T18:46:49Z DEBUG Starting external process >>> 2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt >>> 2017-02-20T18:46:49Z DEBUG Process finished, return code=1 >>> 2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query: >>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 >>> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >>> ;; UPDATE SECTION: >>> ld4ipa02.mf. 0 ANY A >>> >>> 2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702 >>> ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >>> ;; QUESTION SECTION: >>> ;ld4ipa02.mf. IN SOA >>> >>> ;; AUTHORITY SECTION: >>> mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600 >>> >>> Found zone name: mf >>> The master is: ld4ipa01.mf >>> start_gssrequest >>> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ld4ipa01.mf at MF not found in Kerberos database. >>> >>> 2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 >>> 2017-02-20T18:46:49Z ERROR Failed to update DNS records. >>> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A >>> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. >>> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN AAAA >>> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. >>> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: 140.100.102.10.in-addr.arpa. IN PTR >>> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record. >>> 2017-02-20T18:46:49Z WARNING Missing A/AAAA record(s) for host ld4ipa02.mf: 10.102.100.140. >>> 2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 10.102.100.140. >>> >>> Why isn't there an entry for "DNS/ld4ipa01.mf at MF" in the Kerberos >>> database? >>> >>> klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns >>> >>> Keytab name: FILE:/etc/dirsrv/ds.keytab >>> >>> KVNO Timestamp Principal >>> ---- ------------------- ------------------------------ >>> ------------------------ >>> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x696a502bc73d209acdd36c42242 >>> f7f8aff9dbba1073b34ea018ed3bd9cdfd970) >>> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe031464b6948ea34f4291d40fca >>> 7a21e) >>> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0xe94a1c98fe79b6317901435d9e9 >>> e0257cefe438ff2ec527f) >>> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6aaf4c7fa6b51b9de032b7c6428 >>> 307b5) >>> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x5e0702f44aef9e0633e09eede7c >>> a8041) >>> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf at MF (0x6e3a9d29ee3f129a156ae6228ab >>> 7728df8ce5de923a61eba6a2e7802b8d230b6) >>> >>> >>> Tried to test connectivity using ldapsearch found that I could connect >>> to other hosts on 389 but not 636 >>> >>> # ldapsearch -H ldap://nyc02ipa02:389 -D "cn=directory manager" -W -b "" -s base >>> >>> # ldapsearch -H ldaps://nyc02ipa02:686 -D "cn=directory manager" -W -b "" -s base >>> >>> Testing the kvno >>> >>> 02:10:00 root at ld4ipa01:~# kvno DNS/ld4ipa01.mf at MF >>> DNS/ld4ipa01.mf at MF: kvno = 2 >>> >>> 02:10:52 root at ld4ipa02:~# kvno DNS/ld4ipa01.mf at MF >>> kvno: Server DNS/ld4ipa01.mf at MF not found in Kerberos database while >>> getting credentials for DNS/ld4ipa01.mf at MF >>> >>> Add this to any command line to get debug on kerberos commands >>> >>> KRB5_TRACE=/dev/stdout kvno DNS/ld4ipa01.mf at MF >>> >>> So, looking at the debug >>> kvno from ld4ipa02, does not return tickets. It does this because it >>> contacts the KDC which is nyc02ipa02, and nyc02ipa02 does not recognize >>> ldipa02 as an IPA server. It doesn't recognize ld4ipa01 either. >>> >>> >>> >>> right now, if I try to connect nyc02ipa02 to ld4ipa01 I get >>> >>> 21:56:27 root at nyc02ipa02:~# ipa topologysegment-add domain >>> ld4ipa01-to-nyc02ipa02 --leftnode ld4ipa01.mf --rightnode nyc02ipa02.mf >>> ipa: ERROR: invalid 'leftnode': left node is not a topology node: >>> ld4ipa01.mf >>> >>> ipa privilege-show 'DNS Servers' --all --raw >>> >>> dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=mf >>> cn: DNS Servers >>> description: DNS Servers >>> member: krbprincipalname=DNS/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf >>> member: krbprincipalname=ipa-dnskeysyncd/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf >>> member: krbprincipalname=DNS/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf >>> member: krbprincipalname=ipa-dnskeysyncd/nyc02ipa02.mf at MF,cn=services,cn=accounts,dc=mf >>> member: krbprincipalname=ipa-ods-exporter/nyc01ipa02.mf at MF,cn=services,cn=accounts,dc=mf >>> memberof: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=mf >>> memberof: cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=mf >>> objectClass: top >>> objectClass: groupofnames >>> objectClass: nestedgroup >>> >>> >>> -- >>> Aaron Young >>> MarketFactory, Manager of Site Reliability Engineering >>> 425 Broadway, 3FL >>> New York, NY 10013 >>> Office: +1 212 625 9988 <(212)%20625-9988> >>> Direct +1 646 779 3710 <(646)%20779-3710> >>> US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 >>> >>> >>> >>> Hello, >>> >>> please don't use kadmin utility, it is not integrated very well with IPA >>> (or unsupported is a better word) and may break it even more. It looks that >>> you have corrupted kerberos credentials for id4ipa01 >>> >>> I see you are installing client on id4ipa01, was IPA server removed >>> properly previosly? >>> >>> Martin >>> >> >> >> >> -- >> Aaron Young >> MarketFactory, Manager of Site Reliability Engineering >> 425 Broadway, 3FL >> New York, NY 10013 >> Office: +1 212 625 9988 <(212)%20625-9988> >> Direct +1 646 779 3710 <(646)%20779-3710> >> US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 >> > > > > -- > Aaron Young > MarketFactory, Manager of Site Reliability Engineering > 425 Broadway, 3FL > New York, NY 10013 > Office: +1 212 625 9988 <(212)%20625-9988> > Direct +1 646 779 3710 <(646)%20779-3710> > US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 > -- Aaron Young MarketFactory, Manager of Site Reliability Engineering 425 Broadway, 3FL New York, NY 10013 Office: +1 212 625 9988 Direct +1 646 779 3710 US Support: +1 (212) 625-0688 | UK Support: +44 (0) 203 695-7997 -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Sun Feb 26 20:12:23 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Sun, 26 Feb 2017 12:12:23 -0800 Subject: [Freeipa-users] ID Mapping Message-ID: Hey guys, Is it possible to disable ID mapping for AD users in a FreeIPA AD trust setup? The version report is as follows: AD: Windows 2008 R2 FreeIPA Server: 4.4.0-14 FreeIPA Client: 4.4.0-14 SSSD: 1.14.0-43 Linux version: CentOS 7.3 x64_86 I've tried setting ldap_id_mapping = False in sssd.conf in the IPA domain sectionwith no success. Regards, Hanoz -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Feb 27 07:26:52 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 27 Feb 2017 08:26:52 +0100 Subject: [Freeipa-users] ID Mapping In-Reply-To: References: Message-ID: <20170227072652.dt5vtqov34xhxbuf@hendrix> On Sun, Feb 26, 2017 at 12:12:23PM -0800, Hanoz Elavia wrote: > Hey guys, > > Is it possible to disable ID mapping for AD users in a FreeIPA AD trust > setup? > > The version report is as follows: > > AD: Windows 2008 R2 > FreeIPA Server: 4.4.0-14 > FreeIPA Client: 4.4.0-14 > SSSD: 1.14.0-43 > Linux version: CentOS 7.3 x64_86 > > I've tried setting ldap_id_mapping = False in sssd.conf in the IPA domain > sectionwith no success. > > Regards, > > Hanoz In IPA-AD trust environment the mapping is managed on the server. So you'd need to remove the algorithmical range and add a POSIX range instead (see ipa help idrange-add, --type=['ipa-ad-trust-posix', 'ipa-ad-trust', 'ipa-local']) Note that clients cannot modify the range type at the moment, so you also need to remove the cache from all clients in the domain. From mbasti at redhat.com Mon Feb 27 09:35:56 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Feb 2017 10:35:56 +0100 Subject: [Freeipa-users] named-pkcs11: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute; cnamerecord': unknown class/type In-Reply-To: <83a899qwyo.fsf@jochen.org> References: <83a899qwyo.fsf@jochen.org> Message-ID: On 26.02.2017 07:37, Jochen Hein wrote: > When reloading named I get the following message 8 times: > > Feb 26 05:30:27 freeipa2 named-pkcs11[4935]: dns_rdatatype_fromtext() > failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown > class/type > > I do have cnames in my zones, but what is missing here? > DNS seems to work fine for CNAMEs. > > I'm running CentOS 7.3. > > Jochen > Hello, you can safely ignore this message, this is template for creating location records we just failed to get rid of that message. Martin From mbasti at redhat.com Mon Feb 27 10:30:06 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Feb 2017 11:30:06 +0100 Subject: [Freeipa-users] named-pkcs11: option 'serial_autoincrement' is not supported, ignoring In-Reply-To: <83efylqx2b.fsf@jochen.org> References: <83innxqxln.fsf@jochen.org> <83efylqx2b.fsf@jochen.org> Message-ID: On 26.02.2017 07:35, Jochen Hein wrote: > Jochen Hein writes: > >> I'm implementing logcheck on my server and found the following message >> in my logs: >> >>> Feb 26 05:30:26 freeipa2 named-pkcs11[4935]: option 'serial_autoincrement' is not supported, ignoring >> | Updates and Upgrades >> | >> | Replace serial_autoincrement option in /etc/named.conf with serial_remote option. >> | Dependencies >> `---- > I just tried that and got a message that serial_remote is unknown. > I run a current CentOS 7.3 server. > > Jochen > Hello, the documentation you found is old, it may be applicable to RHEL6. For current configuration options see section "5.1 Configuration options" in https://pagure.io/bind-dyndb-ldap You can safely remove serial_autoincrement option form your config. Martin From slaznick at redhat.com Mon Feb 27 10:56:15 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Mon, 27 Feb 2017 11:56:15 +0100 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: References: <1258208599.155271.1487945118957.JavaMail.root@ap0605.com> Message-ID: <00bdde26-ae68-5603-91a5-b5a1ed933021@redhat.com> On 02/24/2017 08:38 PM, Steve Huston wrote: > So, I tried a different tack. Took my bare VM configured as an IPA > client, did a 'yum install ipa-server' and edited the cainstance.py > file to fix the IPv6 issue. Then, without adding the host to > ipaservers in the webui, I simply tried to promote it: > > # kinit admin > Password for admin at ASTRO.PRINCETON.EDU: > # ipa-replica-install --verbose > ipa.ipapython.install.cli.install_tool(Replica): DEBUG Logging to > /var/log/ipareplica-install.log > ipa.ipapython.install.cli.install_tool(Replica): DEBUG > ipa-replica-install was invoked with arguments [] and options: > {'no_dns_sshfp': None, 'skip_schema_check': None, 'setup_kra': None, > 'ip_addresses': None > , 'mkhomedir': None, 'http_cert_files': None, 'ssh_trust_dns': None, > 'reverse_zones': None, 'no_forwarders': None, 'keytab': None, > 'no_ntp': None, 'domain_name': None, 'http_cert_name': None, > 'dirsrv_cert_files > ': None, 'no_dnssec_validation': None, 'no_reverse': None, > 'unattended': False, 'auto_reverse': None, 'auto_forwarders': None, > 'no_host_dns': None, 'no_sshd': None, 'no_ui_redirect': None, > 'dirsrv_config_file': > None, 'forwarders': None, 'verbose': True, 'setup_ca': None, > 'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, > 'forward_policy': None, 'dirsrv_cert_name': None, 'quiet': False, > 'server': None, 'setup_dns': None, 'host_name': None, 'log_file': > None, 'allow_zone_overlap': None} > ipa.ipapython.install.cli.install_tool(Replica): DEBUG IPA version > 4.4.0-14.el7_3.4 > ipa : DEBUG Starting external process > ipa : DEBUG args=/usr/sbin/selinuxenabled > ipa : DEBUG Process finished, return code=0 > ipa : DEBUG stdout= > ipa : DEBUG stderr= > ipa : DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > ipa : DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > ipa : DEBUG httpd is not configured > ipa : DEBUG kadmin is not configured > ipa : DEBUG dirsrv is not configured > ipa : DEBUG pki-tomcatd is not configured > ipa : DEBUG install is not configured > ipa : DEBUG krb5kdc is not configured > ipa : DEBUG ntpd is not configured > ipa : DEBUG named is not configured > ipa : DEBUG ipa_memcached is not configured > ipa : DEBUG filestore is tracking no files > ipa : DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > ipa : DEBUG Configuring client side components > Configuring client side components > ipa : DEBUG Starting external process > ipa : DEBUG args=/usr/sbin/ipa-client-install --unattended --no-ntp > IPA client is already configured on this system. > If you want to reinstall the IPA client, uninstall it first using > 'ipa-client-install --uninstall'. > ipa : DEBUG Process finished, return code=3 > Removing client side components > ipa : DEBUG Starting external process > ipa : DEBUG args=/usr/sbin/ipa-client-install --unattended > --uninstall > Unenrolling client from IPA server > Removing Kerberos service principals from /etc/krb5.keytab > Disabling client Kerberos and LDAP configurations > Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to > /etc/sssd/sssd.conf.deleted > nslcd daemon is not installed, skip configuration > Client uninstall complete. > ipa : DEBUG Process finished, return code=0 > > ipa.ipapython.install.cli.install_tool(Replica): 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/ipapython/install/cli.py", > line 318, in run > cfgr.run() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 308, in run > self.validate() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 317, in validate > for nothing in self._validator(): > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 564, in _configure > next(validator) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 63, in _install > for nothing in self._installer(self.parent): > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1712, in main > promote_check(self) > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 364, in decorated > func(installer) > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 386, in decorated > func(installer) > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1004, in promote_check > ensure_enrolled(installer) > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 958, in ensure_enrolled > sys.exit("Configuration of client side components failed!") > > ipa.ipapython.install.cli.install_tool(Replica): DEBUG The > ipa-replica-install command failed, exception: SystemExit: > Configuration of client side components failed! > ipa.ipapython.install.cli.install_tool(Replica): ERROR > Configuration of client side components failed! > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > Looks like it's unenrolling the machine, then trying to enroll it > again? I also tried again with --server, --realm, --hostname, and > --domain options set appropriately but it made no difference. > Hello, Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can run `ipa domainlevel-get` on the master if you don't know)? Did you have a client installed prior to ipa-replica-install? Cheers, Standa From th at casalogic.dk Mon Feb 27 11:20:40 2017 From: th at casalogic.dk (Troels Hansen) Date: Mon, 27 Feb 2017 12:20:40 +0100 (CET) Subject: [Freeipa-users] Kerberos - Weblogic SSO in IPA Message-ID: <1517028022.2193832.1488194440480.JavaMail.zimbra@casalogic.dk> Hi, I'm trying to help a Weblogic admin trying to enable SSO using IPA as a backend in AD trust, and I'm not anywhere near a Java or Weblogic man. The ticket looks OK, and I can kinit it. Klist shows: # klist -ke sso.keytab Keytab name: FILE:sso.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK (aes256-cts-hmac-sha1-96) 3 HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK (aes128-cts-hmac-sha1-96) 3 HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK (des3-cbc-sha1) 3 HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK (arcfour-hmac) Ticket is exported without the need for pre-auth. I have made a pretty basic krb5.conf for use with Weblogic: [libdefaults] default_realm = LX.DR.DK permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes256-cts default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes256-cts dns_lookup_realm = false dns_lookup_kdc = false noaddresses = true [realms] LX.DR.DK = { kdc = ipa01.lx.dr.dk } [domain_realm] .lx.dr.dk = LX.DR.DK lx.dr.dk = LX.DR.DK When trying to authenticate on web-ui I see: krb5kdc.log on IPA server shows: Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3349](info): AS_REQ (2 etypes {18 18}) 10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK for krbtgt/LX.DR.DK at LX.DR.DK Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3349](info): AS_REQ (2 etypes {18 18}) 10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK for krbtgt/LX.DR.DK at LX.DR.DK Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3353](info): AS_REQ (2 etypes {18 18}) 10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK for krbtgt/LX.DR.DK at LX.DR.DK Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3353](info): AS_REQ (2 etypes {18 18}) 10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK for krbtgt/LX.DR.DK at LX.DR.DK Feb 27 11:06:44 ipa01.lx.dr.dk krb5kdc[3353](info): AS_REQ (2 etypes {18 18}) 10.80.17.50: ISSUE: authtime 1488190004, etypes {rep=18 tkt=18 ses=18}, HTTP/ssotst01pack.lx.dr.dk at LX.DR.DK for krbtgt/LX.DR.DK at LX.DR.DK Java shows: [2017-02-22T14:17:06.666+01:00] [oam_server1] [ERROR] [] [oracle.oam.engine.authn] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: ] [ecid: 236b75b1bd93b747:4e356648:15a65f5a492:-8000-00000000000000db,0] [APP: oam_server#11.1.2.0.0] Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))[[ GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44)) (Not same time, I know. Log files from different days). >From what I can see on the krb5 log it tries to make 5 auth requests, but fails with "Specified version of key is not available", however, they are.... I have already verified this and tried exporting new ones just to make sure. The unlimited encryption package have been added to Java. Does these errors mean anything for some expert on this list, as i'm starting to run out of ideas...... -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Feb 27 11:46:08 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 27 Feb 2017 12:46:08 +0100 Subject: [Freeipa-users] Migration of FreeIPA issue tracker - Trac and git repo to pagure.io Message-ID: Hello list, today and tomorrow a migration of FreeIPA issue tracker[1] and git repo will take place. It is due to FedoraHosted sunset [2]. Both will be migrated to pagure.io [3]. During this migration it won't be possible to add new tickets and comments to Trac or Pagure. [1] https://fedorahosted.org/freeipa/ [2] https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/ [3] https://pagure.io/ Thank you for understanding, -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. From jochen at jochen.org Mon Feb 27 12:44:23 2017 From: jochen at jochen.org (Jochen Hein) Date: Mon, 27 Feb 2017 13:44:23 +0100 Subject: [Freeipa-users] Ubuntu client 2FA not working In-Reply-To: <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> (Tommy Nikjoo's message of "Mon, 6 Feb 2017 13:56:06 +0000") References: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> <20161214224809.GA4232@dhcp-40-8.bne.redhat.com> <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> Message-ID: <831sujrefs.fsf@jochen.org> Tommy Nikjoo writes: > I'm having some issues with 2FA PAM config's on Ubuntu clients. > Currently, I'm guessing that the PAM module doesn't know how to talk to > the 2FA protocol. Is anyone able to give an in site into how to get > this working correctly? I'm not finished with my quest, but I think I got at least some hints. Right now I'm not trying with pam/sss, but with kinit alone. I do have two IPA servers and in the default configuration I see: $ KRB5_TRACE=/dev/stderr kinit -T KEYRING:persistent:1004:krb_ccache_UhNqkJ3 jochen [15136] 1488197822.55857: Resolving hostname freeipa1.example.org. [15136] 1488197822.57587: Sending initial UDP request to dgram 192.168.30.121:88 [15136] 1488197822.60106: Received answer (546 bytes) from dgram 192.168.30.121:88 [15136] 1488197822.60994: Response was from master KDC [15136] 1488197822.61069: Received error from KDC: -1765328359/zus?tzlich Vorauthentifizierung erforderlich [15136] 1488197822.61093: Decoding FAST response [15136] 1488197822.61282: Processing preauth types: 136, 141, 133, 137 [15136] 1488197822.61298: Received cookie: MIT Enter your OTP password: [15136] 1488197829.991232: Preauth module otp (141) (real) returned: 0/Success [15136] 1488197829.991271: Produced preauth for next request: 133, 142 [15136] 1488197829.991289: Encoding request body and padata into FAST request [15136] 1488197829.991518: Sending request (1221 bytes) to EXAMPLE.ORG [15136] 1488197829.993141: Resolving hostname freeipa1.example.org. [15136] 1488197829.993873: Sending initial UDP request to dgram 192.168.30.121:88 [15136] 1488197830.994965: Resolving hostname freeipa2.example.org. [15136] 1488197830.995866: Sending initial UDP request to dgram 192.168.30.122:88 [15136] 1488197831.128141: Received answer (546 bytes) from dgram 192.168.30.121:88 [15136] 1488197831.129630: Response was from master KDC [15136] 1488197831.129731: Received error from KDC: -1765328360/Vorauthentifizierung fehlgeschlagen [15136] 1488197831.129764: Decoding FAST response [15136] 1488197831.129953: Preauth tryagain input types: 136, 141, 133, 137 kinit: Vorauthentifizierung fehlgeschlagen bei Anf?ngliche Anmeldedaten werden geholt. We ask the first ipa server for preauth, after I've entered the password+OTP we ask the first server with UDP, but don't get an answer within one second. So we ask the other server. Shortly after we get the answer from the first server. If I use only one KDC in krb5.conf: dns_lookup_kdc = false ... kdc = freeipa1.example.org we only ask that server and get the correct answer. So I see two questions for now: - Why do we ask both servers with such a short timeout? - Why do we use UDP when using dns_lookup_kdc, even if I have "udp_preference_limit = 1" set? My FreeIPA servers ask themselves, so they don't use DNS. I'll try to check a normal client. Hm, one CentOS client has krb5-workstation-1.14.1-27.el7_3.x86_64 and works fine. My Debian host I analyzed here has krb5-user 1.15-1. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From gkubok at gmail.com Sun Feb 26 12:47:55 2017 From: gkubok at gmail.com (Greg) Date: Sun, 26 Feb 2017 12:47:55 +0000 Subject: [Freeipa-users] CentOS 6 -> 7 migration Message-ID: I've had success going from RHEL6 to RHEL7 and IPA 3.0 to 4.4, without losing any data/objects/clients. It is as you found though, through replication. I've followed this guide for IPA upgrade: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc And this guide for in-situ RHEL6 to 7 upgrade, not sure if/how applicable that is to CentOS, but if you can get away doing fresh OS installs, that's always better (I couldn't, very limited access to hardware/BIOS): https://access.redhat.com/solutions/637583 For IPA upgrade, you definitely want a replica. Well, just another machine on the same network really to help you migrate and you can later go back to using just the one IPA server. As suggested by Rob, you could nominate one of your IPA clients as a replica temporarily (though if that's CentOS 6, it'd need OS upgrade too). In my case I already had two replicas, and I had done the following (deviating slightly from Redhat's guide, that says use 3rd/fresh machine, then decomm old ones): - Removed one RHEL6 replica, uninstalled IPA 3.0 on it, trashed the config etc, made it into as clean RHEL 6 as possible (even yum remove ipa-server etc). - Upgraded that cleaned up RHEL6 ex-replica to RHEL7 in-situ, and installed IPA 4.4 server. - Joined the freshly upgraded and empty RHEL7/IPA4.4 to existing realm and moved CA renewal service to it (important). - Repeated the steps on the other replica (remove from replication, uninstall/trash everything to have as clean RHEL6 as possible, upgraded to RHEL7, install IPA 4.4, re-join). In a way your steps would be even easier, cause you can ignore step 1, and just use a fresh machine. If you still want to end up with just 1 IPA server, then you'd introduce new CentOS 7 / IPA 4.4 replica (new machine on the same network, or existing client nominated to be a server for duration of migration), make sure clients can connect to it / are aware of it, move CA renewal to it, remove existing/old IPA from replication, clean it, upgrade to CentOS 7 / IPA 4.4 (or re-install OS from scratch), re-introduce into replication, move CA renewal back to it, and finally remove the new machine replica, so that you're left with your original machine in an upgraded state. Hope that makes sense. If you can avoid in-situ 6 to7 OS upgrade and do fresh OS installs between the replica migrations, all the better, as it can be a bit of an added nuisance (trawling all the *.rpmnew config files and making sure everything is correct). -- Thanks, Greg Kubok. On 26 February 2017 at 11:08, Rob Verduijn wrote: > Upgrading centos6 to 7 is not a smart thing, unless you like to suffer a > lot of issues. > > Then there are many comaptibility issues regarding the upgrade from ipa3.3 > to 4.4 > > You should consider setting up a temporary vm to migrate from. > On one of your client systems, I assume you got at least 1 ipa client > > Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your > current system to a vm (side effect : instant full backup) > > When you got the vm up and running you can reinstall your main system with > the new os and ipa. > Then replicate the old ipa to the new one. > > Rob Verduijn > > > > 2017-02-26 0:45 GMT+01:00 Ian Pilcher : > >> Is there any way to migrate an IPA server from 6 -> 7 without losing all >> of the IPA configuration and data? All of the documentation I can find >> involves setting up a replica, replicating the data over, and then >> decommissioning the old system; not exactly an option with a single >> system. >> >> -- >> ======================================================================== >> Ian Pilcher arequipeno at gmail.com >> -------- "I grew up before Mark Zuckerberg invented friendship" -------- >> ======================================================================== >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project >> > > > -- > 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 > -- Thanks, Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.elavia at atomiccartoons.com Mon Feb 27 13:49:15 2017 From: h.elavia at atomiccartoons.com (Hanoz Elavia) Date: Mon, 27 Feb 2017 13:49:15 +0000 Subject: [Freeipa-users] ID Mapping In-Reply-To: <20170227072652.dt5vtqov34xhxbuf@hendrix> References: <20170227072652.dt5vtqov34xhxbuf@hendrix> Message-ID: Thanks Jakub!! *Hanoz Elavia |* IT Manager *O:* 604-734-2866 *|* *www.atomiccartoons.com * 112 West 6th Ave, Vancouver, BC, Canada, V5Y1K6 On Mon, Feb 27, 2017 at 7:26 AM, Jakub Hrozek wrote: > On Sun, Feb 26, 2017 at 12:12:23PM -0800, Hanoz Elavia wrote: > > Hey guys, > > > > Is it possible to disable ID mapping for AD users in a FreeIPA AD trust > > setup? > > > > The version report is as follows: > > > > AD: Windows 2008 R2 > > FreeIPA Server: 4.4.0-14 > > FreeIPA Client: 4.4.0-14 > > SSSD: 1.14.0-43 > > Linux version: CentOS 7.3 x64_86 > > > > I've tried setting ldap_id_mapping = False in sssd.conf in the IPA domain > > sectionwith no success. > > > > Regards, > > > > Hanoz > > In IPA-AD trust environment the mapping is managed on the server. So > you'd need to remove the algorithmical range and add a POSIX range > instead (see ipa help idrange-add, --type=['ipa-ad-trust-posix', > 'ipa-ad-trust', 'ipa-local']) > > Note that clients cannot modify the range type at the moment, so you > also need to remove the cache from all clients in the domain. > > -- > 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 huston at astro.princeton.edu Mon Feb 27 15:51:01 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Mon, 27 Feb 2017 10:51:01 -0500 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: <00bdde26-ae68-5603-91a5-b5a1ed933021@redhat.com> References: <1258208599.155271.1487945118957.JavaMail.root@ap0605.com> <00bdde26-ae68-5603-91a5-b5a1ed933021@redhat.com> Message-ID: On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka wrote: > Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can > run `ipa domainlevel-get` on the master if you don't know)? Did you have a > client installed prior to ipa-replica-install? It's level 1. I did have a couple clients installed, and the machine I was trying to promote to a replica was one of them. This whole instance is a testing instance, with live data but not in production, while I make sure everything works as expected before I deploy it, so the servers and their data are new as of a couple weeks ago and began life as a RHEL7.3 install. It seems there might be two issues here; the one I originally reported was that the ipa-server packages installed on a client machine are unable to talk to the server, even though it obviously knows what the server is (the "unsupported format" error I originally shared). The second is with setting up a replica in general. I had tried the various methods outlined in the RedHat IdM documentation, including promoting a client via an administrators TGT, adding the client to the ipaservers group on the server, etc. What did finally work was unprovisioning the client, setting a one-time password, and running "ipa-replica-install -v --domain=astro.princeton.edu --server=ipa.astro.princeton.edu --realm=ASTRO.PRINCETON.EDU --hostname=syrinx.astro.princeton.edu --setup-ca -p foobar" - this yielded a fully working replica when it finished. All of the previous failures happened in the same way as mentioned before - it seems to unprovision the client for some reason, then fail in reprovisioning it. One problem which has cropped up before and caused problems is with DNS capitalization. DNS reports the domain name of "Princeton.EDU" for hosts here, which means in order to do just about anything with a FreeIPA server I have to manually add the host to /etc/hosts with all lowercase letters. I also have to force all of the host names via command line switches so that DNS is not consulted for lookups, which will return the StudlyCaps names and fail. I suppose I should raise that as a separate issue, because my understanding is that hostnames/domainnames should be case insensitive so I'm not sure why FreeIPA cares (and it may be easier to steer the entire project to not care than convince those in control of DNS here to change it :D ) -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From jason at tresgeek.net Mon Feb 27 19:50:50 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Mon, 27 Feb 2017 13:50:50 -0600 (CST) Subject: [Freeipa-users] AD Sites and Trusts Message-ID: <1849642901.2325.1488225050619.JavaMail.zimbra@tresgeek.net> Hello, I was wondering if this thread regarding AD trusts and sites is still correct: https://www.redhat.com/archives/freeipa-users/2015-December/msg00214.html (no way to make use of AD sites) If so, is there already an RFE for this that I can vote for and track? Thanks, j From jhrozek at redhat.com Mon Feb 27 20:11:30 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 27 Feb 2017 21:11:30 +0100 Subject: [Freeipa-users] AD Sites and Trusts In-Reply-To: <1849642901.2325.1488225050619.JavaMail.zimbra@tresgeek.net> References: <1849642901.2325.1488225050619.JavaMail.zimbra@tresgeek.net> Message-ID: <20170227201130.ha2kwft3xmtdus3l@hendrix> On Mon, Feb 27, 2017 at 01:50:50PM -0600, Jason B. Nance wrote: > Hello, > > I was wondering if this thread regarding AD trusts and sites is still correct: > > https://www.redhat.com/archives/freeipa-users/2015-December/msg00214.html > > (no way to make use of AD sites) Well, you can configure krb5.conf on the client..but there is still no automatic configuration. > > If so, is there already an RFE for this that I can vote for and track? RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=1416528 upstream: https://pagure.io/SSSD/sssd/issue/3291 This is a stretch goal for the next upstream release, but given our timeline and the fact that nobody started on this RFE, I think the release after the next one is more realistic. From jochen at jochen.org Mon Feb 27 21:07:32 2017 From: jochen at jochen.org (Jochen Hein) Date: Mon, 27 Feb 2017 22:07:32 +0100 Subject: [Freeipa-users] Ubuntu client 2FA not working In-Reply-To: <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> (Tommy Nikjoo's message of "Mon, 6 Feb 2017 13:56:06 +0000") References: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> <20161214224809.GA4232@dhcp-40-8.bne.redhat.com> <962dac31-8a9b-13f0-dd8a-8addec666251@armourcomms.com> Message-ID: <83fuizpckr.fsf@jochen.org> Tommy Nikjoo writes: > I'm having some issues with 2FA PAM config's on Ubuntu clients. > Currently, I'm guessing that the PAM module doesn't know how to talk to > the 2FA protocol. Is anyone able to give an in site into how to get > this working correctly? Can you provide logs what doesn't work? See also my report in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856307 In short: without _kerberos._udp entries it should work out-of-the-box. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From arequipeno at gmail.com Mon Feb 27 22:24:55 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Mon, 27 Feb 2017 16:24:55 -0600 Subject: [Freeipa-users] ipa-replica-conncheck wants listener on port 7389 Message-ID: I'm part way through my CentOS 6 to 7 "upgrade". I've reached the point of trying to set up my new IPA server as a replica of a temporary VM. ipa-replica-conncheck is complaining, because nothing on the temporary server is listening on port 7389. The documentation here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prepping-replica.html Says: In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not required. Which seems to indicate that nothing *should* be listening on that port on a CentOS 7 IPA server. So who's right? And if something (pki-tomcatd?) should be listening on that port, how do I make it do so? Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From APtashnik at cccis.com Mon Feb 27 23:19:15 2017 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 27 Feb 2017 23:19:15 +0000 Subject: [Freeipa-users] FreeIPA Read Only Replica Message-ID: <20E78A43-7FDE-44B7-9509-4C52B60015D3@cccis.com> Team, Is it possible to setup read only replica for use in DMZ for example? Regards, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Tue Feb 28 08:39:19 2017 From: th at casalogic.dk (Troels Hansen) Date: Tue, 28 Feb 2017 09:39:19 +0100 (CET) Subject: [Freeipa-users] Needs help understand this timeout issue In-Reply-To: <2146577764.1946080.1486560351510.JavaMail.zimbra@casalogic.dk> References: <298041591.1827916.1485770448856.JavaMail.zimbra@casalogic.dk> <954637680.1860873.1485945135656.JavaMail.zimbra@casalogic.dk> <8F1C6214-3C29-4B93-9E6E-2FFD76BFC969@bsd.uchicago.edu> <1359190682.1911254.1486367960580.JavaMail.zimbra@casalogic.dk> <1291496609.1940875.1486538822821.JavaMail.zimbra@casalogic.dk> <2146577764.1946080.1486560351510.JavaMail.zimbra@casalogic.dk> Message-ID: <693409646.2213645.1488271159119.JavaMail.zimbra@casalogic.dk> Hi all.... Just wanted to follow up on this as I created a case with RedHat, and here is their findings, for all of you to share: >From RedHat support: ---------------------- As per the current discussion with our engineering team. --- The client requests info about a user. This goes to the IPA DS which calls into SSSD on the client which does a sequence of: 1) getgrouplist -> returns a list of GIDs the user is a member of 2) for gid in list_of_gids: getgrgid(gid) now, the problem is that the getgrgid on the server doesn't go directly to the domain the GID comes from -- in the general case this is not possible, because at least in the case of POSIX GIDs set by the admin we don't know which domain the GID is from. So what happens instead is that we search all the subdomains in the order they are discovered. Observe here: (Mon Feb 27 09:27:29 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [lx.dr.dk][0x2][BE_REQ_GROUP][1][idnumber=235088:-] -- this is the NSS responder searching the IPA domain. This is very fast since the SSSD and the IPA server are on the same machine (Mon Feb 27 09:27:29 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [place.dr.dk][0x2][BE_REQ_GROUP][1][idnumber=235088:-] -- but here we are searching the place.dr.dk domain (Mon Feb 27 09:27:29 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [net.dr.dk][0x2][BE_REQ_GROUP][1][idnumber=235088:-] -- then the net.dr.dk domain I'm not sure we can do much in 7.3, unfortunately. But 7.4 will help in the sense that when the NSS responder is checking the caches and considering which back end server to contact, it would first loop over all the caches and try to first see if this ID already belongs to some domain as kind of a hint and first try to check this domain. In other words, instead of checking cache-server, cache-server it would check cache, cache, then server, server. The other thing is, the back end could also, if the domain uses algorithmic ID mapping, decide sooner if the ID comes from its domain (as I said earlier, it's not possible in the general case if the admin assigns the POSIX IDs). There, we could reconstruct the SID from the GID and if the SID comes from a different domain, just abort the request. --- We will be opening bug based on our observation and update you further. ------------ So, this is an actual bug or maybe just not optimal design, but being made into an actual bug at RedHat. From tkrizek at redhat.com Tue Feb 28 08:59:43 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 28 Feb 2017 09:59:43 +0100 Subject: [Freeipa-users] ipa-replica-conncheck wants listener on port 7389 In-Reply-To: References: Message-ID: <95e89957-0217-2335-fdd8-eea1c3d93c03@redhat.com> On 02/27/2017 11:24 PM, Ian Pilcher wrote: > I'm part way through my CentOS 6 to 7 "upgrade". I've reached the > point of trying to set up my new IPA server as a replica of a temporary > VM. > > ipa-replica-conncheck is complaining, because nothing on the temporary > server is listening on port 7389. > > The documentation here: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prepping-replica.html > > > Says: > > In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not > required. > > Which seems to indicate that nothing *should* be listening on that port > on a CentOS 7 IPA server. > > So who's right? And if something (pki-tomcatd?) should be listening on > that port, how do I make it do so? > > Thanks! > On a CentOS 7 IPA server, port 7389 should not be required. You can bypass the check with --skip-conncheck when running ipa-replica-install. -- Tomas Krizek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jhrozek at redhat.com Tue Feb 28 09:19:22 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 28 Feb 2017 10:19:22 +0100 Subject: [Freeipa-users] FreeIPA Read Only Replica In-Reply-To: <20E78A43-7FDE-44B7-9509-4C52B60015D3@cccis.com> References: <20E78A43-7FDE-44B7-9509-4C52B60015D3@cccis.com> Message-ID: <20170228091326.u3z6hz2djiajounk@hendrix> On Mon, Feb 27, 2017 at 11:19:15PM +0000, Andrey Ptashnik wrote: > Team, > > Is it possible to setup read only replica for use in DMZ for example? Not at the moment: https://pagure.io/freeipa/issue/5569 From slaznick at redhat.com Tue Feb 28 09:26:13 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Tue, 28 Feb 2017 10:26:13 +0100 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: References: <1258208599.155271.1487945118957.JavaMail.root@ap0605.com> <00bdde26-ae68-5603-91a5-b5a1ed933021@redhat.com> Message-ID: <5dd49d41-1654-f879-f7cc-95532c856374@redhat.com> On 02/27/2017 04:51 PM, Steve Huston wrote: > On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka wrote: >> Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can >> run `ipa domainlevel-get` on the master if you don't know)? Did you have a >> client installed prior to ipa-replica-install? > It's level 1. I did have a couple clients installed, and the machine > I was trying to promote to a replica was one of them. This whole > instance is a testing instance, with live data but not in production, > while I make sure everything works as expected before I deploy it, so > the servers and their data are new as of a couple weeks ago and began > life as a RHEL7.3 install. > > It seems there might be two issues here; the one I originally reported > was that the ipa-server packages installed on a client machine are > unable to talk to the server, even though it obviously knows what the > server is (the "unsupported format" error I originally shared). The > second is with setting up a replica in general. The server rpm packages should have no impact on client settings if neither server nor replica are installed on the given machine. IIRC client only uses the NSS database in /etc/ipa/nssdb, you may want to check the permissions there (should be o+xr for the folder, o+r for the *.db files there). > I had tried the various methods outlined in the RedHat IdM > documentation, including promoting a client via an administrators TGT, > adding the client to the ipaservers group on the server, etc. What > did finally work was unprovisioning the client, setting a one-time > password, and running "ipa-replica-install -v > --domain=astro.princeton.edu --server=ipa.astro.princeton.edu > --realm=ASTRO.PRINCETON.EDU --hostname=syrinx.astro.princeton.edu > --setup-ca -p foobar" - this yielded a fully working replica when it > finished. All of the previous failures happened in the same way as > mentioned before - it seems to unprovision the client for some reason, > then fail in reprovisioning it. I believe your machine might have been in some kind of undecided state when you tried to promote a client to a replica. What happens during replica installation on domain level 1 is that client installation is checked first. If client is installed the installation continues with other steps, if it's not, it tries to install the client. In your case, you probably had your client installed at first and tried to install replica. Something bad happened, can't be sure what, the installation failed and tried to uninstall the client but that might have failed, too. Eventually, you uninstalled the client yourself successfully, all files were removed and its records were also removed from the server. This made it possible to eventually successfully install a replica. I wouldn't bet my life on it but I'd think the installation could have gone successfully even if you installed a client and tried to promote it again :) Anyway, I am sorry to hear you had such troubles, the replica installation is not usually such a painful process, I hope you will have more luck with FreeIPA in the future. > One problem which has cropped up before and caused problems is with > DNS capitalization. DNS reports the domain name of "Princeton.EDU" > for hosts here, which means in order to do just about anything with a > FreeIPA server I have to manually add the host to /etc/hosts with all > lowercase letters. I also have to force all of the host names via > command line switches so that DNS is not consulted for lookups, which > will return the StudlyCaps names and fail. I suppose I should raise > that as a separate issue, because my understanding is that > hostnames/domainnames should be case insensitive so I'm not sure why > FreeIPA cares (and it may be easier to steer the entire project to not > care than convince those in control of DNS here to change it :D ) > From slaznick at redhat.com Tue Feb 28 09:37:45 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Tue, 28 Feb 2017 10:37:45 +0100 Subject: [Freeipa-users] ipa-replica-conncheck wants listener on port 7389 In-Reply-To: <95e89957-0217-2335-fdd8-eea1c3d93c03@redhat.com> References: <95e89957-0217-2335-fdd8-eea1c3d93c03@redhat.com> Message-ID: <241f0e44-8130-6127-2c12-5f640e454c05@redhat.com> On 02/28/2017 09:59 AM, Tomas Krizek wrote: > On 02/27/2017 11:24 PM, Ian Pilcher wrote: >> I'm part way through my CentOS 6 to 7 "upgrade". I've reached the >> point of trying to set up my new IPA server as a replica of a temporary >> VM. >> >> ipa-replica-conncheck is complaining, because nothing on the temporary >> server is listening on port 7389. >> >> The documentation here: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prepping-replica.html >> >> >> Says: >> >> In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not >> required. >> >> Which seems to indicate that nothing *should* be listening on that port >> on a CentOS 7 IPA server. >> >> So who's right? And if something (pki-tomcatd?) should be listening on >> that port, how do I make it do so? >> >> Thanks! >> > On a CentOS 7 IPA server, port 7389 should not be required. You can > bypass the check with --skip-conncheck when running ipa-replica-install. > > > Please, rather check what the problem is. Port 7389 is not required for the newer system, but the old 6.x system has to be listening on it so that we can replicate agains the older Dogtag database. From the previous mail I believe you were following the right documentation, https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc, correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Feb 28 09:45:14 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 28 Feb 2017 10:45:14 +0100 Subject: [Freeipa-users] unable to decode: {replica In-Reply-To: <5907f1b4-c87b-0217-d4a3-878dcf36b395@yahoo.co.uk> References: <5907f1b4-c87b-0217-d4a3-878dcf36b395@yahoo.co.uk> Message-ID: <250983c1-67dc-832c-aefb-f5bf4abb1cd2@redhat.com> On 02/26/2017 11:35 AM, lejeczek wrote: > hi everyone > > I first time see: > > unable to decode: {replica 60} 586eaffd000a003c0000 586eaffd000a003c0000 > Replica Update Vectors: > .... > > on all four servers. What would be a correct troubleshooting and fixing this > problem? > many thanks, > L. > > > Hello, what is the version and OS of your IPA servers and DS? $ rpm -q ipa-server freeipa-server 389-ds-base Similar issues happened last year, you can search the archives for "unable to decode" but a 389-ds fix improved the situation. So if you have older version then maybe update and then manual cleanup of RUVs might help. -- Petr Vobornik From pvoborni at redhat.com Tue Feb 28 09:49:21 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 28 Feb 2017 10:49:21 +0100 Subject: [Freeipa-users] CentOS 6 -> 7 migration In-Reply-To: References: Message-ID: <71deae8b-35b2-9e83-e951-e0b4d8a1c45d@redhat.com> On 02/26/2017 04:58 PM, Rob Verduijn wrote: > Sounds feasable, however I'm not sure which solution entails the most work. +1 Just in case, I'll mention migration documentation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc There are some manual steps regarding CA which should not be skipped. > > In step 3 you loose all the extra functionalities( cups/squid/ntp ) as well, > while these stay preserved by a p2v including a nice backup. > You do need a backup of all the functions before proceeding with step3. > > Rob Verduijn > > 2017-02-26 14:40 GMT+01:00 Ian Pilcher >: > > On 02/26/2017 05:08 AM, Rob Verduijn wrote: > > You should consider setting up a temporary vm to migrate from. > On one of your client systems, I assume you got at least 1 ipa client > > Try looking at http://libguestfs.org/virt-p2v.1.html > to migrate your > current system to a vm (side effect : instant full backup) > > When you got the vm up and running you can reinstall your main system > with the new os and ipa. > Then replicate the old ipa to the new one. > > > Hmm. The system that runs IPA is the "network server" in my home > network. It runs various services -- DNS, NTP, CUPS, squid, etc. -- as > well as routing between various VLANs. So simply P2V'ing it would be > a major project in its own right. > > What about this, though ... > > 1. Set up a new CentOS 7 VM running IPA > > 2. Replicate the IPA data from the old CentOS 6 system to the VM. > > 3. Install CentOS 7 on the original system > > 4. Replicate the IPA data back from the VM > > Will this work? > > -- > ======================================================================== > Ian Pilcher arequipeno at gmail.com > -------- "I grew up before Mark Zuckerberg invented friendship" -------- > ======================================================================== > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > > -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. From pvoborni at redhat.com Tue Feb 28 11:00:12 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 28 Feb 2017 12:00:12 +0100 Subject: [Freeipa-users] Migration of FreeIPA issue tracker - Trac and git repo to pagure.io In-Reply-To: References: Message-ID: On 02/27/2017 12:46 PM, Petr Vobornik wrote: > Hello list, > > today and tomorrow a migration of FreeIPA issue tracker[1] and git repo > will take place. > > It is due to FedoraHosted sunset [2]. Both will be migrated to pagure.io > [3]. > > During this migration it won't be possible to add new tickets and > comments to Trac or Pagure. > > [1] https://fedorahosted.org/freeipa/ > [2] https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/ > [3] https://pagure.io/ > > Thank you for understanding, Issue tracker and git repo were migrated. They can be used now. https://pagure.io/freeipa Additional steps will follow - redirection of old URLs to new - sync with github -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. From huston at astro.princeton.edu Tue Feb 28 13:39:26 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Tue, 28 Feb 2017 08:39:26 -0500 Subject: [Freeipa-users] New install, unsupported format? In-Reply-To: <5dd49d41-1654-f879-f7cc-95532c856374@redhat.com> References: <1258208599.155271.1487945118957.JavaMail.root@ap0605.com> <00bdde26-ae68-5603-91a5-b5a1ed933021@redhat.com> <5dd49d41-1654-f879-f7cc-95532c856374@redhat.com> Message-ID: On Tue, Feb 28, 2017 at 4:26 AM, Standa Laznicka wrote: > On 02/27/2017 04:51 PM, Steve Huston wrote: >> It seems there might be two issues here; the one I originally reported >> was that the ipa-server packages installed on a client machine are >> unable to talk to the server, even though it obviously knows what the >> server is (the "unsupported format" error I originally shared). The >> second is with setting up a replica in general. > > The server rpm packages should have no impact on client settings if neither > server nor replica are installed on the given machine. IIRC client only uses > the NSS database in /etc/ipa/nssdb, you may want to check the permissions > there (should be o+xr for the folder, o+r for the *.db files there). I'll look into this more later, since it's less of an issue (I don't plan on having the server packages installed on a machine that isn't a server, and once it's a server it works fine). > I believe your machine might have been in some kind of undecided state when > you tried to promote a client to a replica. What happens during replica > installation on domain level 1 is that client installation is checked first. > If client is installed the installation continues with other steps, if it's > not, it tries to install the client. > In your case, you probably had your client installed at first and tried to > install replica. Something bad happened, can't be sure what, the > installation failed and tried to uninstall the client but that might have > failed, too. Eventually, you uninstalled the client yourself successfully, > all files were removed and its records were also removed from the server. > This made it possible to eventually successfully install a replica. > I wouldn't bet my life on it but I'd think the installation could have gone > successfully even if you installed a client and tried to promote it again :) Quite possible - I thought I accounted for everything, but I'll admit that when a client gets installed and provisioned it's not with ipa-client-install but via puppet. I did this because I needed a programmatic way to determine if a host was already provisioned (preferably locally) and execute the proper commands to do so, and in my experimenting I found following the instructions for provisioning manually worked well and use the presence of /etc/krb5.keytab as an indicator of "has this host been provisioned" (its absence is a negative). It's likely that ipa-client-install does something else that I never noticed, which ipa-replica-install relies on to know what's going on - especially since when I run on a client, it first uninstalls the client and then tries to reinstall it, and that's where it fails. I may experiment with that a bit too since it won't take long to do. > Anyway, I am sorry to hear you had such troubles, the replica installation > is not usually such a painful process, I hope you will have more luck with > FreeIPA in the future. While it has been frustrating, it has definitely been a learning experience. I grow more confident in the system's abilities as I discover more about it, and that means should something break in the future I'm already in a position of knowledge of some of the internals and less afraid to poke gently to fix it. The support on this mailing list has also been wonderful, so thank you all for that! -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' From arequipeno at gmail.com Tue Feb 28 14:21:46 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Tue, 28 Feb 2017 08:21:46 -0600 Subject: [Freeipa-users] CentOS 6 -> 7 migration In-Reply-To: <71deae8b-35b2-9e83-e951-e0b4d8a1c45d@redhat.com> References: <71deae8b-35b2-9e83-e951-e0b4d8a1c45d@redhat.com> Message-ID: <3cb0f4ed-0da0-7adf-5c58-403534618dea@gmail.com> On 02/28/2017 03:49 AM, Petr Vobornik wrote: > On 02/26/2017 04:58 PM, Rob Verduijn wrote: >> Sounds feasable, however I'm not sure which solution entails the most >> work. > > +1 > > Just in case, I'll mention migration documentation: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc > > > There are some manual steps regarding CA which should not be skipped. > Thanks for mentioning that. I thought that I was done, but I had missed that part. -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From arequipeno at gmail.com Tue Feb 28 14:32:40 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Tue, 28 Feb 2017 08:32:40 -0600 Subject: [Freeipa-users] ipa-replica-conncheck wants listener on port 7389 In-Reply-To: <241f0e44-8130-6127-2c12-5f640e454c05@redhat.com> References: <95e89957-0217-2335-fdd8-eea1c3d93c03@redhat.com> <241f0e44-8130-6127-2c12-5f640e454c05@redhat.com> Message-ID: <44b732bc-bd6d-8714-c9dd-517e92d03996@gmail.com> On 02/28/2017 03:37 AM, Standa Laznicka wrote: > Please, rather check what the problem is. Port 7389 is not required for > the newer system, but the old 6.x system has to be listening on it so > that we can replicate agains the older Dogtag database. From the > previous mail I believe you were following the right documentation, > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc, > correct? Yes, but I hit this issue when setting up replication from a (temporary) CentOS 7 system back to the newly re-installed system. I believe that I understand the issue. The ipa-replica-conncheck man page at https://linux.die.net/man/1/ipa-replica-conncheck says this: -c, --check-ca Include in a check also a set of dogtag connection requirements. When a replica is self-sign this option is not needed. But the man page in CentOS 7 says: -c, --check-ca Include in a check also a set of dogtag connection requirements. Only needed when the master was installed with Dogtag 9 or lower. As a system administrator who is unfamiliar with the inner workings of FreeIPA, neither version really helped me to figure out if I should be passing that option. (The answer appears to be "yes" when the existing server was CentOS 6, but "no" when the existing server is CentOS 7.) -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From karl.forner at gmail.com Tue Feb 28 17:13:42 2017 From: karl.forner at gmail.com (Karl Forner) Date: Tue, 28 Feb 2017 18:13:42 +0100 Subject: [Freeipa-users] login/su problem on ubuntu Message-ID: I just registered a new computer running ubuntu to our freeIPA system. Some users (all I tried except me) are not able to login using lightdm. The message on screen is "Permission denied". On the system the user (joe) is created, its home directory also, but it only contains a .kde/ subdir and a .bash_history. On my session, if I type: $sudo su - joe I get: su: Permission denied (Ignored) The only log file that is modified is /var/log/auth.log. The relevant lines during the graphical login are: Feb 28 16:44:29 nyx lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=joe Feb 28 16:44:41 nyx lightdm: pam_sss(lightdm:auth): authentication success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=joe Feb 28 16:44:41 nyx lightdm: pam_kwallet(lightdm:auth): pam_sm_authenticate Feb 28 16:44:43 nyx lightdm: pam_sss(lightdm:account): Access denied for user joe: 6 (Permission denied) Feb 28 16:44:54 nyx lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "joe" The relevant lines during the "sudo su - joe": Feb 28 16:48:32 nyx su[26394]: pam_sss(su:account): Access denied for user joe: 6 (Permission denied) Feb 28 16:48:32 nyx su[26394]: pam_acct_mgmt: Permission denied Feb 28 16:48:32 nyx su[26394]: FAILED su for joe by karl This computer is setup exactly like a dozen of others that work fine. What could be the problem ? Thanks, Karl Forner P.S Description: Ubuntu 14.04.5 LTS 3.16.0-76-generic #98~14.04.1-Ubuntu SM -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Tue Feb 28 18:52:10 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 28 Feb 2017 18:52:10 +0000 Subject: [Freeipa-users] unable to decode: {replica In-Reply-To: <250983c1-67dc-832c-aefb-f5bf4abb1cd2@redhat.com> References: <5907f1b4-c87b-0217-d4a3-878dcf36b395@yahoo.co.uk> <250983c1-67dc-832c-aefb-f5bf4abb1cd2@redhat.com> Message-ID: <22d81136-0d79-df33-a041-bbc8a70fad5e@yahoo.co.uk> On 28/02/17 09:45, Petr Vobornik wrote: > On 02/26/2017 11:35 AM, lejeczek wrote: >> hi everyone >> >> I first time see: >> >> unable to decode: {replica 60} 586eaffd000a003c0000 >> 586eaffd000a003c0000 >> Replica Update Vectors: >> .... >> >> on all four servers. What would be a correct >> troubleshooting and fixing this >> problem? >> many thanks, >> L. >> >> >> > > Hello, > > what is the version and OS of your IPA servers and DS? > > $ rpm -q ipa-server freeipa-server 389-ds-base well I run a Centos 7.x and ~]$ rpm -q ipa-server freeipa-server 389-ds-base ipa-server-4.4.0-14.el7.centos.4.x86_64 package freeipa-server is not installed 389-ds-base-1.3.5.10-15.el7_3.x86_64 I searched the net and archives but failed to find anything flagged as "solved". > > Similar issues happened last year, you can search the > archives for "unable to decode" but a 389-ds fix improved > the situation. So if you have older version then maybe > update and then manual cleanup of RUVs might help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Feb 28 20:01:53 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 28 Feb 2017 21:01:53 +0100 Subject: [Freeipa-users] login/su problem on ubuntu In-Reply-To: References: Message-ID: <20170228200153.7wcg5tunckkrgmkv@hendrix> On Tue, Feb 28, 2017 at 06:13:42PM +0100, Karl Forner wrote: > I just registered a new computer running ubuntu to our freeIPA system. > Some users (all I tried except me) are not able to login using lightdm. > > The message on screen is "Permission denied". > On the system the user (joe) is created, its home directory also, but it > only contains a .kde/ subdir and a .bash_history. > > On my session, if I type: > $sudo su - joe > I get: > su: Permission denied > (Ignored) > > > The only log file that is modified is /var/log/auth.log. > The relevant lines during the graphical login are: > > Feb 28 16:44:29 nyx lightdm: pam_unix(lightdm:auth): authentication > failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=joe > Feb 28 16:44:41 nyx lightdm: pam_sss(lightdm:auth): authentication success; > logname= uid=0 euid=0 tty=:0 ruser= rhost= user=joe > Feb 28 16:44:41 nyx lightdm: pam_kwallet(lightdm:auth): pam_sm_authenticate > Feb 28 16:44:43 nyx lightdm: pam_sss(lightdm:account): Access denied for > user joe: 6 (Permission denied) > Feb 28 16:44:54 nyx lightdm: pam_succeed_if(lightdm:auth): requirement > "user ingroup nopasswdlogin" not met by user "joe" > > The relevant lines during the "sudo su - joe": > Feb 28 16:48:32 nyx su[26394]: pam_sss(su:account): Access denied for user > joe: 6 (Permission denied) You need to enable SSSD debugging: https://fedorahosted.org/sssd/wiki/Troubleshooting and check the sssd logs, probably the HBAC access control is kicking you out.