From jcnt at use.startmail.com Sun Apr 2 23:46:26 2017 From: jcnt at use.startmail.com (Josh) Date: Sun, 2 Apr 2017 19:46:26 -0400 Subject: [Freeipa-users] 389-console and IPA In-Reply-To: <20170331143850.GN10135@10.4.128.1> References: <3cb3e29e-88a9-861f-c386-3861f8f92e91@redhat.com> <25db9b7c-bd7a-3081-efec-7e155b9a31b7@use.startmail.com> <20170331143850.GN10135@10.4.128.1> Message-ID: On 03/31/2017 10:38 AM, Lukas Slebodnik wrote: > On (29/03/17 14:05), Josh wrote: >> Hi Mark, >> >> Thanks for responding. >> >> Essentially I would like to change access log file size from 100Meg to 10Meg >> and change number of log files down to 5 for example. >> > If you are a vi-user then you can try to use ldapvi. > It can even shouw you ldif which can be used with ldapmodify. > Thank you, Lukas! ldapvi is an excellent tool! Problem solved. Josh. From datakid at gmail.com Mon Apr 3 01:00:21 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Mon, 3 Apr 2017 11:00:21 +1000 Subject: [Freeipa-users] libsemanage updates fail due to AD user with space Message-ID: Hola, I've reported this issue before (with a different symptom iirc), but thought I should mention again, as I have no idea how to competently report it to selinux. With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces in their names, libsemanage fails to update: eg from recent monthly upgrade cycle: Updating : selinux-policy-targeted-3.13.1-102.el7_3.16.noarch 3/14 libsemanage.parse_assert_ch: expected character ':', but found 'f' (/etc/selinux/targeted/tmp/seusers.local: 5): lastname firstname at domain.com:unconfined_u:s0-s0:c0.c1023 (No such file or directory). libsemanage.seuser_parse: could not parse seuser record (No such file or directory). libsemanage.dbase_file_cache: could not cache file database (No such file or directory). libsemanage.semanage_base_merge_components: could not merge local modifications into policy (No such file or directory). 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: From jhrozek at redhat.com Mon Apr 3 08:04:26 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 3 Apr 2017 10:04:26 +0200 Subject: [Freeipa-users] ipa_add_ad_memberships_get_next errors In-Reply-To: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> References: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> Message-ID: <20170403080426.s6pqcswmgqujssxs@hendrix> On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote: > I'm seeing messages like this: > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external > group memberships even after all groups have been looked up on the LDAP server. > > and wondering it is anything to worry about. > > > Some context: > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > (0x2000): Search groups with filter: > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > (0x2000): No such entry > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > (0x2000): Search groups with filter: > (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com)) > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000): > No such DN in the timestamp cache: > name=nwra at nwra.com,cn=groups,cn=nwra.com,cn=sysdb > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs] > (0x2000): TS cache doesn't contain this DN, skipping > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base] > (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000): > Searching 10.10.41.4:389 > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x0400): calling ldap_search_ext with > [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com]. I think this might be the reason why SSSD reports unresolved memberships. It'trying to resolve the group using the cn attribute, ut the object's RDN attribute seems to be ipaUniqueID. So I don't think this is harmful, just confusing. Can you please check what the object is on the IPA side with this ipaUniqueID? Could you describe the hierarchy so I can set up and reproduce something similar locally? > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [objectClass] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [posixGroup] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [cn] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [userPassword] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [gidNumber] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [member] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [ipaUniqueID] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [modifyTimestamp] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [entryUSN] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x1000): Requesting attrs: [ipaExternalMember] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > (0x2000): ldap_search_ext called, msgid = 17 > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_add] (0x2000): New > operation 17 timeout 6 > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result] > (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0], > ldap[0x7fc2ae9b60b0] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result] > (0x2000): Trace: end of ldap_result list > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result] > (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0], > ldap[0x7fc2ae9b60b0] > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_op_finished] > (0x0400): Search result: Success(0), no errmsg set > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_destructor] (0x2000): > Operation 17 finished > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_process] > (0x0400): Search for groups, returned 0 results. > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > (0x2000): Search groups with filter: > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > (0x2000): No such entry > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external > group memberships even after all groups have been looked up on the LDAP server. > > -- > Orion Poplawski > Technical Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane orion at nwra.com > Boulder, CO 80301 http://www.nwra.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 jhrozek at redhat.com Mon Apr 3 08:08:53 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 3 Apr 2017 10:08:53 +0200 Subject: [Freeipa-users] subdomain errors In-Reply-To: <6043cbf5-f052-25fd-b565-411084cdd2b1@cora.nwra.com> References: <6043cbf5-f052-25fd-b565-411084cdd2b1@cora.nwra.com> Message-ID: <20170403080853.hrrop3gfn6ltayi5@hendrix> On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote: > I seem to be having some issues with users/groups that may be leading to > errors in the subdomain status. Can anyone parse this for me? > > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] > (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] > (0x0080): Cannot set ts attrs for > name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb This can be ignored, it's just a minor performance annoyance we track upstream. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] > (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] > (0x0080): Cannot set ts attrs for > name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_initgr_get_overrides_step] (0x0040): The group > name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute > objectSIDString, error! But this seems strange. Before you sanitized (presumably?) the logs, did the DN name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to an IPA object? Did you run the sidgen task when setting up trusts or did you make sure all replicas are either trust controllers or trust agents? Does the entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute? > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides > failed [22]. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] > (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] > (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): > DP Error is OK on failed request? > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] > (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] > (0x0080): Cannot set ts attrs for > name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_initgr_get_overrides_step] (0x0040): The group > name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute > objectSIDString, error! > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides > failed [22]. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] > (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] > (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): > DP Error is OK on failed request? > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [sdap_ad_tokengroups_get_posix_members] (0x0080): Domain not found for SID > S-1-5-32-545 > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] > (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] > (0x0080): Cannot set ts attrs for > name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external > group memberships even after all groups have been looked up on the LDAP server. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] > (0x0080): Sudomain lookup failed, will try to reset sudomain.. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080): > Cannot retrieve service [ad.nwra.com] > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] > (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] > (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): > DP Error is OK on failed request? > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] > (0x0080): Sudomain lookup failed, will try to reset sudomain.. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080): > Cannot retrieve service [ad.nwra.com] > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] > (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] > (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): > DP Error is OK on failed request? > (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] > [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request > > -- > Orion Poplawski > Technical Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane orion at nwra.com > Boulder, CO 80301 http://www.nwra.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 abokovoy at redhat.com Mon Apr 3 08:10:41 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Apr 2017 11:10:41 +0300 Subject: [Freeipa-users] ipa_add_ad_memberships_get_next errors In-Reply-To: <20170403080426.s6pqcswmgqujssxs@hendrix> References: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> <20170403080426.s6pqcswmgqujssxs@hendrix> Message-ID: <20170403081041.pvxb4lfk72rucmzk@redhat.com> On ma, 03 huhti 2017, Jakub Hrozek wrote: >On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote: >> I'm seeing messages like this: >> >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] >> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external >> group memberships even after all groups have been looked up on the LDAP server. >> >> and wondering it is anything to worry about. >> >> >> Some context: >> >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >> (0x2000): Search groups with filter: >> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >> (0x2000): No such entry >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >> (0x2000): Search groups with filter: >> (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com)) >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000): >> No such DN in the timestamp cache: >> name=nwra at nwra.com,cn=groups,cn=nwra.com,cn=sysdb >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs] >> (0x2000): TS cache doesn't contain this DN, skipping >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base] >> (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com] >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000): >> Searching 10.10.41.4:389 >> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] >> (0x0400): calling ldap_search_ext with >> [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com]. > >I think this might be the reason why SSSD reports unresolved >memberships. It'trying to resolve the group using the cn attribute, ut >the object's RDN attribute seems to be ipaUniqueID. So I don't think >this is harmful, just confusing. > >Can you please check what the object is on the IPA side with this >ipaUniqueID? It is HBAC group -- see above in the log: (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) -- / Alexander Bokovoy From jhrozek at redhat.com Mon Apr 3 09:11:16 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 3 Apr 2017 11:11:16 +0200 Subject: [Freeipa-users] libsemanage updates fail due to AD user with space In-Reply-To: References: Message-ID: <20170403091116.usilk66d7gazhyhp@hendrix> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote: > Hola, > > I've reported this issue before (with a different symptom iirc), but > thought I should mention again, as I have no idea how to competently report > it to selinux. > > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces in > their names, libsemanage fails to update: > > eg from recent monthly upgrade cycle: > > Updating : > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch > 3/14 > libsemanage.parse_assert_ch: expected character ':', but found 'f' > (/etc/selinux/targeted/tmp/seusers.local: 5): > lastname firstname at domain.com:unconfined_u:s0-s0:c0.c1023 (No such file or > directory). > libsemanage.seuser_parse: could not parse seuser record (No such file or > directory). > libsemanage.dbase_file_cache: could not cache file database (No such file > or directory). > libsemanage.semanage_base_merge_components: could not merge local > modifications into policy (No such file or directory). > Hi, according to my quick testing this is solved with this PR: https://github.com/SSSD/sssd/pull/189 (Please note that we haven't ran all regression tests on this PR so I can't in fact tell if it's correct or not. The code does look OK, though). I was also able to work around the issue by setting: override_space = _ in sssd.conf From orion at cora.nwra.com Mon Apr 3 14:52:09 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 3 Apr 2017 08:52:09 -0600 Subject: [Freeipa-users] ipa_add_ad_memberships_get_next errors In-Reply-To: <20170403081041.pvxb4lfk72rucmzk@redhat.com> References: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> <20170403080426.s6pqcswmgqujssxs@hendrix> <20170403081041.pvxb4lfk72rucmzk@redhat.com> Message-ID: <41aea6b9-8c64-6377-2eb4-f06b6bf628dd@cora.nwra.com> On 04/03/2017 02:10 AM, Alexander Bokovoy wrote: > On ma, 03 huhti 2017, Jakub Hrozek wrote: >> On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote: >>> I'm seeing messages like this: >>> >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] >>> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external >>> group memberships even after all groups have been looked up on the LDAP >>> server. >>> >>> and wondering it is anything to worry about. >>> >>> >>> Some context: >>> >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >>> (0x2000): Search groups with filter: >>> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) >>> >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >>> (0x2000): No such entry >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >>> (0x2000): Search groups with filter: >>> (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com)) >>> >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000): >>> No such DN in the timestamp cache: >>> name=nwra at nwra.com,cn=groups,cn=nwra.com,cn=sysdb >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs] >>> (0x2000): TS cache doesn't contain this DN, skipping >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base] >>> (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com] >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000): >>> Searching 10.10.41.4:389 >>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] >>> (0x0400): calling ldap_search_ext with >>> [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com]. >>> >> >> I think this might be the reason why SSSD reports unresolved >> memberships. It'trying to resolve the group using the cn attribute, ut >> the object's RDN attribute seems to be ipaUniqueID. So I don't think >> this is harmful, just confusing. >> >> Can you please check what the object is on the IPA side with this >> ipaUniqueID? > It is HBAC group -- see above in the log: > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) This is our "allow employees access" HBAC group. So it applies to our "nwra" host group as well as a couple individual machines, and to our "nwra" IPA group. # 12d2026e-a5cd-11e5-a14e-00163e2d6456, hbac, nwra.com dn: ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com description: Allow NWRA-Users serviceCategory: all memberHost: cn=nwra,cn=hostgroups,cn=accounts,dc=nwra,dc=com memberHost: fqdn=ipaclient1.cora.nwra.com,cn=computers,cn=accounts,dc=nwra,dc= com memberHost: fqdn=quetzal.cora.nwra.com,cn=computers,cn=accounts,dc=nwra,dc=com memberUser: cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com objectClass: ipaassociation objectClass: ipahbacrule accessRuleType: allow ipaEnabledFlag: TRUE cn: allow_nwra ipaUniqueID: 12d2026e-a5cd-11e5-a14e-00163e2d6456 The group search for that item fails presumably because it's not a group (doesn't have objectclass=group). The nwra group contains the nwra_users_external group: # ipa group-show nwra Group name: nwra Description: ad.nwra.com NWRA-Users GID: 1001 Member groups: nwra_users_external Member of HBAC rule: allow_nwra # ipa group-show nwra_users_external Group name: nwra_users_external Description: ad.nwra.com NWRA-Users external map External member: nwra-users at ad.nwra.com Member of groups: nwra Indirect Member of HBAC rule: allow_nwra -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Mon Apr 3 15:03:19 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 3 Apr 2017 09:03:19 -0600 Subject: [Freeipa-users] subdomain errors In-Reply-To: <20170403080853.hrrop3gfn6ltayi5@hendrix> References: <6043cbf5-f052-25fd-b565-411084cdd2b1@cora.nwra.com> <20170403080853.hrrop3gfn6ltayi5@hendrix> Message-ID: <37ff2acc-46b2-4ad2-3ff4-49bdb158544e@cora.nwra.com> On 04/03/2017 02:08 AM, Jakub Hrozek wrote: > On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote: >> I seem to be having some issues with users/groups that may be leading to >> errors in the subdomain status. Can anyone parse this for me? >> >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >> (0x0080): Cannot set ts attrs for >> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb > > This can be ignored, it's just a minor performance annoyance we track > upstream. Figured something like that, but thanks. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >> (0x0080): Cannot set ts attrs for >> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_initgr_get_overrides_step] (0x0040): The group >> name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute >> objectSIDString, error! > > But this seems strange. Before you sanitized (presumably?) the logs, did > the DN name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to > an IPA object? Yes, it's an IPA group used for HBAC access. > Did you run the sidgen task when setting up trusts or did you make sure > all replicas are either trust controllers or trust agents? Does the > entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute? I suspect the sidgen task has not been run, as I'm not really sure what that is. I have belatedly installed and run ipa-adtrust-install on all of our IPA servers, though a couple ran without that for a while. It does not look like that group has an ipaNTSecurityIdentifier atribute. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides >> failed [22]. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] >> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] >> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): >> DP Error is OK on failed request? >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >> (0x0080): Cannot set ts attrs for >> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_initgr_get_overrides_step] (0x0040): The group >> name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute >> objectSIDString, error! >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides >> failed [22]. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] >> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] >> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): >> DP Error is OK on failed request? >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [sdap_ad_tokengroups_get_posix_members] (0x0080): Domain not found for SID >> S-1-5-32-545 >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >> (0x0080): Cannot set ts attrs for >> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external >> group memberships even after all groups have been looked up on the LDAP server. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] >> (0x0080): Sudomain lookup failed, will try to reset sudomain.. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080): >> Cannot retrieve service [ad.nwra.com] >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] >> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] >> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): >> DP Error is OK on failed request? >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] >> (0x0080): Sudomain lookup failed, will try to reset sudomain.. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080): >> Cannot retrieve service [ad.nwra.com] >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] >> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] >> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): >> DP Error is OK on failed request? >> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request >> >> -- >> Orion Poplawski >> Technical Manager 720-772-5637 >> NWRA, Boulder/CoRA Office FAX: 303-415-9702 >> 3380 Mitchell Lane orion at nwra.com >> Boulder, CO 80301 http://www.nwra.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 > -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Mon Apr 3 15:25:53 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 3 Apr 2017 09:25:53 -0600 Subject: [Freeipa-users] subdomain errors In-Reply-To: <37ff2acc-46b2-4ad2-3ff4-49bdb158544e@cora.nwra.com> References: <6043cbf5-f052-25fd-b565-411084cdd2b1@cora.nwra.com> <20170403080853.hrrop3gfn6ltayi5@hendrix> <37ff2acc-46b2-4ad2-3ff4-49bdb158544e@cora.nwra.com> Message-ID: On 04/03/2017 09:03 AM, Orion Poplawski wrote: > On 04/03/2017 02:08 AM, Jakub Hrozek wrote: >> On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote: >>> I seem to be having some issues with users/groups that may be leading to >>> errors in the subdomain status. Can anyone parse this for me? >>> >>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >>> (0x0080): Cannot set ts attrs for >>> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb >> >> This can be ignored, it's just a minor performance annoyance we track >> upstream. > > Figured something like that, but thanks. > >>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >>> (0x0080): Cannot set ts attrs for >>> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb >>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >>> [ipa_initgr_get_overrides_step] (0x0040): The group >>> name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute >>> objectSIDString, error! >> >> But this seems strange. Before you sanitized (presumably?) the logs, did >> the DN name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to >> an IPA object? > > Yes, it's an IPA group used for HBAC access. > >> Did you run the sidgen task when setting up trusts or did you make sure >> all replicas are either trust controllers or trust agents? Does the >> entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute? > > I suspect the sidgen task has not been run, as I'm not really sure what that > is. I have belatedly installed and run ipa-adtrust-install on all of our IPA > servers, though a couple ran without that for a while. It does not look like > that group has an ipaNTSecurityIdentifier atribute. I'm seeing: [03/Apr/2017:09:07:34.269247507 -0600] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [03/Apr/2017:09:07:34.273308903 -0600] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [24613] into an unused SID. [03/Apr/2017:09:07:34.274521892 -0600] do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [03/Apr/2017:09:07:34.277196405 -0600] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. My IPA ranges are: # ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: AD.NWRA.COM_id_range First Posix ID of the range: 20000 Number of IDs in the range: 20000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-89655523-1570529619-2103694531 Range type: Active Directory domain range Range name: NWRA.COM_id_range First Posix ID of the range: 8000 Number of IDs in the range: 2000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range ---------------------------- Number of entries returned 2 ---------------------------- So I've been creating these local posix IPA groups for HBAC access (as well as file storage) with the same gid as that assigned to the AD user. Perhaps that is a problem? -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From abokovoy at redhat.com Mon Apr 3 15:32:49 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Apr 2017 18:32:49 +0300 Subject: [Freeipa-users] ipa_add_ad_memberships_get_next errors In-Reply-To: <41aea6b9-8c64-6377-2eb4-f06b6bf628dd@cora.nwra.com> References: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> <20170403080426.s6pqcswmgqujssxs@hendrix> <20170403081041.pvxb4lfk72rucmzk@redhat.com> <41aea6b9-8c64-6377-2eb4-f06b6bf628dd@cora.nwra.com> Message-ID: <20170403153249.hxdo7eqfe4iajn53@redhat.com> On ma, 03 huhti 2017, Orion Poplawski wrote: >On 04/03/2017 02:10 AM, Alexander Bokovoy wrote: >> On ma, 03 huhti 2017, Jakub Hrozek wrote: >>> On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote: >>>> I'm seeing messages like this: >>>> >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] >>>> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external >>>> group memberships even after all groups have been looked up on the LDAP >>>> server. >>>> >>>> and wondering it is anything to worry about. >>>> >>>> >>>> Some context: >>>> >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >>>> (0x2000): Search groups with filter: >>>> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) >>>> >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >>>> (0x2000): No such entry >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >>>> (0x2000): Search groups with filter: >>>> (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com)) >>>> >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000): >>>> No such DN in the timestamp cache: >>>> name=nwra at nwra.com,cn=groups,cn=nwra.com,cn=sysdb >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs] >>>> (0x2000): TS cache doesn't contain this DN, skipping >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base] >>>> (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com] >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000): >>>> Searching 10.10.41.4:389 >>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] >>>> (0x0400): calling ldap_search_ext with >>>> [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com]. >>>> >>> >>> I think this might be the reason why SSSD reports unresolved >>> memberships. It'trying to resolve the group using the cn attribute, ut >>> the object's RDN attribute seems to be ipaUniqueID. So I don't think >>> this is harmful, just confusing. >>> >>> Can you please check what the object is on the IPA side with this >>> ipaUniqueID? >> It is HBAC group -- see above in the log: >> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) > >This is our "allow employees access" HBAC group. So it applies to our "nwra" >host group as well as a couple individual machines, and to our "nwra" IPA group. It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even look at it for a POSIX user membership. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Apr 3 15:35:08 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Apr 2017 18:35:08 +0300 Subject: [Freeipa-users] subdomain errors In-Reply-To: References: <6043cbf5-f052-25fd-b565-411084cdd2b1@cora.nwra.com> <20170403080853.hrrop3gfn6ltayi5@hendrix> <37ff2acc-46b2-4ad2-3ff4-49bdb158544e@cora.nwra.com> Message-ID: <20170403153508.qvdgb7hen4byiwcy@redhat.com> On ma, 03 huhti 2017, Orion Poplawski wrote: >On 04/03/2017 09:03 AM, Orion Poplawski wrote: >> On 04/03/2017 02:08 AM, Jakub Hrozek wrote: >>> On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote: >>>> I seem to be having some issues with users/groups that may be leading to >>>> errors in the subdomain status. Can anyone parse this for me? >>>> >>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >>>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >>>> (0x0080): Cannot set ts attrs for >>>> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb >>> >>> This can be ignored, it's just a minor performance annoyance we track >>> upstream. >> >> Figured something like that, but thanks. >> >>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] >>>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] >>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] >>>> (0x0080): Cannot set ts attrs for >>>> name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb >>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] >>>> [ipa_initgr_get_overrides_step] (0x0040): The group >>>> name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute >>>> objectSIDString, error! >>> >>> But this seems strange. Before you sanitized (presumably?) the logs, did >>> the DN name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to >>> an IPA object? >> >> Yes, it's an IPA group used for HBAC access. >> >>> Did you run the sidgen task when setting up trusts or did you make sure >>> all replicas are either trust controllers or trust agents? Does the >>> entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute? >> >> I suspect the sidgen task has not been run, as I'm not really sure what that >> is. I have belatedly installed and run ipa-adtrust-install on all of our IPA >> servers, though a couple ran without that for a while. It does not look like >> that group has an ipaNTSecurityIdentifier atribute. > >I'm seeing: > >[03/Apr/2017:09:07:34.269247507 -0600] sidgen_task_thread - [file >ipa_sidgen_task.c, line 194]: Sidgen task starts ... >[03/Apr/2017:09:07:34.273308903 -0600] find_sid_for_ldap_entry - [file >ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [24613] into an unused >SID. >[03/Apr/2017:09:07:34.274521892 -0600] do_work - [file ipa_sidgen_task.c, line >154]: Cannot add SID to existing entry. >[03/Apr/2017:09:07:34.277196405 -0600] sidgen_task_thread - [file >ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. Look at this list's archives, I've been giving recipes how to fix this in February. >My IPA ranges are: > ># ipa idrange-find >---------------- >2 ranges matched >---------------- > Range name: AD.NWRA.COM_id_range > First Posix ID of the range: 20000 > Number of IDs in the range: 20000 > First RID of the corresponding RID range: 0 > Domain SID of the trusted domain: S-1-5-21-89655523-1570529619-2103694531 > Range type: Active Directory domain range > > Range name: NWRA.COM_id_range > First Posix ID of the range: 8000 > Number of IDs in the range: 2000 > First RID of the corresponding RID range: 1000 > First RID of the secondary RID range: 100000000 > Range type: local domain range >---------------------------- >Number of entries returned 2 >---------------------------- > >So I've been creating these local posix IPA groups for HBAC access (as well as >file storage) with the same gid as that assigned to the AD user. Perhaps that >is a problem? Yes, that is a problem. But HBAC group is not a problem because HBAC group is not a POSIX IPA group at all, it is even stored in a different subtree than user groups. -- / Alexander Bokovoy From jhrozek at redhat.com Mon Apr 3 16:04:00 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 3 Apr 2017 18:04:00 +0200 Subject: [Freeipa-users] ipa_add_ad_memberships_get_next errors In-Reply-To: <20170403153249.hxdo7eqfe4iajn53@redhat.com> References: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> <20170403080426.s6pqcswmgqujssxs@hendrix> <20170403081041.pvxb4lfk72rucmzk@redhat.com> <41aea6b9-8c64-6377-2eb4-f06b6bf628dd@cora.nwra.com> <20170403153249.hxdo7eqfe4iajn53@redhat.com> Message-ID: <20170403160400.h6yluwyo43zrghcx@hendrix> On Mon, Apr 03, 2017 at 06:32:49PM +0300, Alexander Bokovoy wrote: > On ma, 03 huhti 2017, Orion Poplawski wrote: > > On 04/03/2017 02:10 AM, Alexander Bokovoy wrote: > > > On ma, 03 huhti 2017, Jakub Hrozek wrote: > > > > On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote: > > > > > I'm seeing messages like this: > > > > > > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] > > > > > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external > > > > > group memberships even after all groups have been looked up on the LDAP > > > > > server. > > > > > > > > > > and wondering it is anything to worry about. > > > > > > > > > > > > > > > Some context: > > > > > > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > > > > > (0x2000): Search groups with filter: > > > > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) > > > > > > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > > > > > (0x2000): No such entry > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] > > > > > (0x2000): Search groups with filter: > > > > > (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com)) > > > > > > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000): > > > > > No such DN in the timestamp cache: > > > > > name=nwra at nwra.com,cn=groups,cn=nwra.com,cn=sysdb > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs] > > > > > (0x2000): TS cache doesn't contain this DN, skipping > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base] > > > > > (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com] > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000): > > > > > Searching 10.10.41.4:389 > > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] > > > > > (0x0400): calling ldap_search_ext with > > > > > [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com]. > > > > > > > > > > > > > I think this might be the reason why SSSD reports unresolved > > > > memberships. It'trying to resolve the group using the cn attribute, ut > > > > the object's RDN attribute seems to be ipaUniqueID. So I don't think > > > > this is harmful, just confusing. > > > > > > > > Can you please check what the object is on the IPA side with this > > > > ipaUniqueID? > > > It is HBAC group -- see above in the log: > > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) > > > > This is our "allow employees access" HBAC group. So it applies to our "nwra" > > host group as well as a couple individual machines, and to our "nwra" IPA group. > It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even > look at it for a POSIX user membership. Right, I'll try to reproduce at least the error message locally to try if we can suppress it (by skipping the HBAC group). At the very least the error message is confusing for admins. From abokovoy at redhat.com Mon Apr 3 16:12:09 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Apr 2017 19:12:09 +0300 Subject: [Freeipa-users] ipa_add_ad_memberships_get_next errors In-Reply-To: <20170403160400.h6yluwyo43zrghcx@hendrix> References: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> <20170403080426.s6pqcswmgqujssxs@hendrix> <20170403081041.pvxb4lfk72rucmzk@redhat.com> <41aea6b9-8c64-6377-2eb4-f06b6bf628dd@cora.nwra.com> <20170403153249.hxdo7eqfe4iajn53@redhat.com> <20170403160400.h6yluwyo43zrghcx@hendrix> Message-ID: <20170403161209.dgdr6dje4dtjz5nl@redhat.com> On ma, 03 huhti 2017, Jakub Hrozek wrote: >On Mon, Apr 03, 2017 at 06:32:49PM +0300, Alexander Bokovoy wrote: >> On ma, 03 huhti 2017, Orion Poplawski wrote: >> > On 04/03/2017 02:10 AM, Alexander Bokovoy wrote: >> > > On ma, 03 huhti 2017, Jakub Hrozek wrote: >> > > > On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote: >> > > > > I'm seeing messages like this: >> > > > > >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] >> > > > > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external >> > > > > group memberships even after all groups have been looked up on the LDAP >> > > > > server. >> > > > > >> > > > > and wondering it is anything to worry about. >> > > > > >> > > > > >> > > > > Some context: >> > > > > >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >> > > > > (0x2000): Search groups with filter: >> > > > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) >> > > > > >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >> > > > > (0x2000): No such entry >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] >> > > > > (0x2000): Search groups with filter: >> > > > > (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com)) >> > > > > >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000): >> > > > > No such DN in the timestamp cache: >> > > > > name=nwra at nwra.com,cn=groups,cn=nwra.com,cn=sysdb >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs] >> > > > > (0x2000): TS cache doesn't contain this DN, skipping >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base] >> > > > > (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com] >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000): >> > > > > Searching 10.10.41.4:389 >> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] >> > > > > (0x0400): calling ldap_search_ext with >> > > > > [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com]. >> > > > > >> > > > >> > > > I think this might be the reason why SSSD reports unresolved >> > > > memberships. It'trying to resolve the group using the cn attribute, ut >> > > > the object's RDN attribute seems to be ipaUniqueID. So I don't think >> > > > this is harmful, just confusing. >> > > > >> > > > Can you please check what the object is on the IPA side with this >> > > > ipaUniqueID? >> > > It is HBAC group -- see above in the log: >> > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) >> > >> > This is our "allow employees access" HBAC group. So it applies to our "nwra" >> > host group as well as a couple individual machines, and to our "nwra" IPA group. >> It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even >> look at it for a POSIX user membership. > >Right, I'll try to reproduce at least the error message locally to try >if we can suppress it (by skipping the HBAC group). At the very least >the error message is confusing for admins. It may also be related to the issue of not setting proper base for searches in case of IPA provider for some times of searches. -- / Alexander Bokovoy From APtashnik at cccis.com Mon Apr 3 18:28:46 2017 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 3 Apr 2017 18:28:46 +0000 Subject: [Freeipa-users] Upgrade from IPA 4.2 Message-ID: Hello, We have Centos 7.2 and IPA 4.2 version. I remember that in previous versions in order to upgrade to the latest one I had to run IPA upgrade scripts that would separately upgrade LDAP database. Is that the same procedure if I need to upgrade from version 4.2? Regards, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiml at omnigroup.com Mon Apr 3 23:17:13 2017 From: wiml at omnigroup.com (Wim Lewis) Date: Mon, 3 Apr 2017 16:17:13 -0700 Subject: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates Message-ID: <3E12EE86-4096-4F50-B39B-C9887E383A1C@omnigroup.com> I'm trying to provision a client with a wildcard certificate[1]. I followed the procedure outlined in [2], but I'm not receiving the certificate I expect. The certificate's subject DN contains a wildcard string, but the SAN does not. Since the SAN, not the subject name, is the relevant part of the certificate [3], this isn't the right certificate. What I want is a certificate with two SAN entries, a dNSName for "blah.example.com" and another dNSName for "*.blah.example.com". But if I request the additional SAN (by passing "-D 'blah.example.com' -D '*.blah.example.com'" to getcert) then the request fails: status: CA_UNREACHABLE ca-error: Server at https://ipa.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. The service principal for subject alt name *.blah.example.com in certificate request does not exist). How do I tell FreeIPA that it is OK for it to issue a cert with an additional SAN to my host principal? [1] Why am I using a wildcard certificate despite it being easy to issue certs from FreeIPA? I'm using it with sandstorm.io, which creates a randomly named subdomain for essentially every session. This is a reasonable use of wildcard certificates, as I understand it, since all of the domains are served from the same process and no other domain can match the cert's wildcard - sandstorm owns the dns hierarchy under its root. [2] https://www.freeipa.org/page/Howto/Wildcard_certificates [3] See RFC6125 [B.2], based on RFC 2818, which describes what part of the certificate the browser should look at to see if the certificate matches the expected hostname. In short, as far as HTTPS is concerned, if there are DNS SANs, then the subject field of the server's certificate (and its CN) is irrelevant. From datakid at gmail.com Tue Apr 4 00:13:47 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Tue, 4 Apr 2017 10:13:47 +1000 Subject: [Freeipa-users] libsemanage updates fail due to AD user with space In-Reply-To: <20170403091116.usilk66d7gazhyhp@hendrix> References: <20170403091116.usilk66d7gazhyhp@hendrix> Message-ID: On 3 April 2017 at 19:11, Jakub Hrozek wrote: > On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote: > > > > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces > in > > their names, libsemanage fails to update: > > > > eg from recent monthly upgrade cycle: > > > > Updating : > > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch > > 3/14 > > libsemanage.parse_assert_ch: expected character ':', but found 'f' > > (/etc/selinux/targeted/tmp/seusers.local: 5): > > lastname firstname at domain.com:unconfined_u:s0-s0:c0.c1023 (No such file > or > > directory). > > libsemanage.seuser_parse: could not parse seuser record (No such file or > > directory). > > libsemanage.dbase_file_cache: could not cache file database (No such file > > or directory). > > libsemanage.semanage_base_merge_components: could not merge local > > modifications into policy (No such file or directory). > > > > Hi, > according to my quick testing this is solved with this PR: > https://github.com/SSSD/sssd/pull/189 > (Please note that we haven't ran all regression tests on this PR so I > can't in fact tell if it's correct or not. The code does look OK, > though). > > I was also able to work around the issue by setting: > override_space = _ > in sssd.conf > Thanks Jakub. The problem with the override_space = _ is that we also have users with _ in their names. I understand that this could be any character, but we decided that - given what we know about our AD - any character could also be in a user name. Looking forward to seeing the patch in upcoming releases. 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: From datakid at gmail.com Tue Apr 4 00:21:11 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Tue, 4 Apr 2017 10:21:11 +1000 Subject: [Freeipa-users] subdomain errors In-Reply-To: <20170403153508.qvdgb7hen4byiwcy@redhat.com> References: <6043cbf5-f052-25fd-b565-411084cdd2b1@cora.nwra.com> <20170403080853.hrrop3gfn6ltayi5@hendrix> <37ff2acc-46b2-4ad2-3ff4-49bdb158544e@cora.nwra.com> <20170403153508.qvdgb7hen4byiwcy@redhat.com> Message-ID: On 4 April 2017 at 01:35, Alexander Bokovoy wrote: > On ma, 03 huhti 2017, Orion Poplawski wrote: > >> On 04/03/2017 09:03 AM, Orion Poplawski wrote: >> >>> On 04/03/2017 02:08 AM, Jakub Hrozek wrote: >>> >>>> On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote: >>>> >>> >>> I'm seeing: >> >> [03/Apr/2017:09:07:34.269247507 -0600] sidgen_task_thread - [file >> ipa_sidgen_task.c, line 194]: Sidgen task starts ... >> [03/Apr/2017:09:07:34.273308903 -0600] find_sid_for_ldap_entry - [file >> ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [24613] into an >> unused >> SID. >> [03/Apr/2017:09:07:34.274521892 -0600] do_work - [file >> ipa_sidgen_task.c, line >> 154]: Cannot add SID to existing entry. >> [03/Apr/2017:09:07:34.277196405 -0600] sidgen_task_thread - [file >> ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. >> > Look at this list's archives, I've been giving recipes how to fix this > in February. > > My IPA ranges are: >> >> # ipa idrange-find >> ---------------- >> 2 ranges matched >> ---------------- >> Range name: AD.NWRA.COM_id_range >> First Posix ID of the range: 20000 >> Number of IDs in the range: 20000 >> First RID of the corresponding RID range: 0 >> Domain SID of the trusted domain: S-1-5-21-89655523-1570529619-2 >> 103694531 >> Range type: Active Directory domain range >> >> Range name: NWRA.COM_id_range >> First Posix ID of the range: 8000 >> Number of IDs in the range: 2000 >> First RID of the corresponding RID range: 1000 >> First RID of the secondary RID range: 100000000 >> Range type: local domain range >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> So I've been creating these local posix IPA groups for HBAC access (as >> well as >> file storage) with the same gid as that assigned to the AD user. Perhaps >> that >> is a problem? >> > Yes, that is a problem. But HBAC group is not a problem because HBAC > group is not a POSIX IPA group at all, it is even stored in a different > subtree than user groups. > > Can you expand on this please? In what way is this a problem? We also have local posix IPA groups with the same gid as that assigned to the AD user (for historical reasons to do with samba shares on networked disks). We don't use those groups for HBAC though, we use AD group membership through external groups for HBAC. (I use the term "we use HBAC" loosely - it's still in testing :) ) cheers L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From datakid at gmail.com Tue Apr 4 00:23:41 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Tue, 4 Apr 2017 10:23:41 +1000 Subject: [Freeipa-users] Upgrade from IPA 4.2 In-Reply-To: References: Message-ID: On 4 April 2017 at 04:28, Andrey Ptashnik wrote: > Hello, > > We have Centos 7.2 and IPA 4.2 version. > I remember that in previous versions in order to upgrade to the latest one > I had to run IPA upgrade scripts that would separately upgrade LDAP > database. Is that the same procedure if I need to upgrade from version 4.2? > > Andrey, That wasn't my experience. We just did a yum update and it all seemed to work. Given it's role, I presume you have or can set up a test env you can try it on? 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: From ftweedal at redhat.com Tue Apr 4 01:41:42 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 4 Apr 2017 11:41:42 +1000 Subject: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates In-Reply-To: <3E12EE86-4096-4F50-B39B-C9887E383A1C@omnigroup.com> References: <3E12EE86-4096-4F50-B39B-C9887E383A1C@omnigroup.com> Message-ID: <20170404014142.GX10261@dhcp-40-8.bne.redhat.com> On Mon, Apr 03, 2017 at 04:17:13PM -0700, Wim Lewis wrote: > I'm trying to provision a client with a wildcard certificate[1]. I > followed the procedure outlined in [2], but I'm not receiving the > certificate I expect. The certificate's subject DN contains a > wildcard string, but the SAN does not. Since the SAN, not the > subject name, is the relevant part of the certificate [3], this > isn't the right certificate. > > What I want is a certificate with two SAN entries, a dNSName for > "blah.example.com" and another dNSName for "*.blah.example.com". > But if I request the additional SAN (by passing "-D > 'blah.example.com' -D '*.blah.example.com'" to getcert) then the > request fails: > > status: CA_UNREACHABLE > ca-error: Server at https://ipa.example.com/ipa/xml failed > request, will retry: 4001 (RPC failed at server. The > service principal for subject alt name *.blah.example.com in > certificate request does not exist). > > How do I tell FreeIPA that it is OK for it to issue a cert with an > additional SAN to my host principal? > The only way is to create a profile that hard-codes the desired SAN data, then use that profile. The observed behaviour is because FreeIPA's CSR processing checks that all SAN values present in the CSR actually correspond to the indicated subject principal(s). In your case, there is no principal that has a wildcard in its name, so the cert request gets rejected. We are not planning to change FreeIPA to support wildcard dnsNames in SAN. More commentary below. > > [1] Why am I using a wildcard certificate despite it being easy to > issue certs from FreeIPA? I'm using it with sandstorm.io, which > creates a randomly named subdomain for essentially every session. > This is a reasonable use of wildcard certificates, as I understand > it, since all of the domains are served from the same process and > no other domain can match the cert's wildcard - sandstorm owns the > dns hierarchy under its root. > Is your instance publicly hosted? Perhaps the sandstorm.io developers could support ACME/Let's Encrypt so that certs can be automatically acquired for each domain... > [2] https://www.freeipa.org/page/Howto/Wildcard_certificates > [3] See RFC6125 [B.2], based on RFC 2818, which describes what > part of the certificate the browser should look at to see if the > certificate matches the expected hostname. In short, as far as > HTTPS is concerned, if there are DNS SANs, then the subject field > of the server's certificate (and its CN) is irrelevant. > This is correct. But see also ?7.2 which states that wildcard certs are deprecated :) https://tools.ietf.org/html/rfc6125#section-7.2 Thanks, Fraser From lslebodn at redhat.com Tue Apr 4 07:32:12 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 4 Apr 2017 09:32:12 +0200 Subject: [Freeipa-users] libsemanage updates fail due to AD user with space In-Reply-To: References: <20170403091116.usilk66d7gazhyhp@hendrix> Message-ID: <20170404073212.GB9143@10.4.128.1> On (04/04/17 10:13), Lachlan Musicman wrote: >On 3 April 2017 at 19:11, Jakub Hrozek wrote: > >> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote: >> > >> > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces >> in >> > their names, libsemanage fails to update: >> > >> > eg from recent monthly upgrade cycle: >> > >> > Updating : >> > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch >> > 3/14 >> > libsemanage.parse_assert_ch: expected character ':', but found 'f' >> > (/etc/selinux/targeted/tmp/seusers.local: 5): >> > lastname firstname at domain.com:unconfined_u:s0-s0:c0.c1023 (No such file >> or >> > directory). >> > libsemanage.seuser_parse: could not parse seuser record (No such file or >> > directory). >> > libsemanage.dbase_file_cache: could not cache file database (No such file >> > or directory). >> > libsemanage.semanage_base_merge_components: could not merge local >> > modifications into policy (No such file or directory). >> > >> >> Hi, >> according to my quick testing this is solved with this PR: >> https://github.com/SSSD/sssd/pull/189 This patch will not help with spaces in name. it need to be fixed in selinux-policy or libsemanage. LS From ronaldw at ronzo.at Tue Apr 4 07:41:38 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Tue, 4 Apr 2017 09:41:38 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: <20170331113521.GH10135@10.4.128.1> References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> Message-ID: On 2017-03-31 13:35, Lukas Slebodnik wrote: > On (29/03/17 10:47), Ronald Wimmer wrote: >> Hi, >> >> yesterday I suddenly was unable to use the webinterface of my ipa master. SSH >> login (with root user) did not work also. >> >> When I uncommented the setting "memcache_timeout = 600" in the sssd config >> file of the master everything seemed to work fine again. (my ipa setup has a >> trust to AD) >> > I doubt it had anything to do memcache_timeout. > I would say that restart of sssd helped. But it difficult to say > without log files. either sssd logs or at least /var/log/secure > (journald for pam). You were right. I uncommented the setting and the problem ocurred again. From lslebodn at redhat.com Tue Apr 4 07:44:04 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 4 Apr 2017 09:44:04 +0200 Subject: [Freeipa-users] libsemanage updates fail due to AD user with space In-Reply-To: <20170404073212.GB9143@10.4.128.1> References: <20170403091116.usilk66d7gazhyhp@hendrix> <20170404073212.GB9143@10.4.128.1> Message-ID: <20170404074403.GC9143@10.4.128.1> On (04/04/17 09:32), Lukas Slebodnik wrote: >On (04/04/17 10:13), Lachlan Musicman wrote: >>On 3 April 2017 at 19:11, Jakub Hrozek wrote: >> >>> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote: >>> > >>> > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces >>> in >>> > their names, libsemanage fails to update: >>> > >>> > eg from recent monthly upgrade cycle: >>> > >>> > Updating : >>> > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch >>> > 3/14 >>> > libsemanage.parse_assert_ch: expected character ':', but found 'f' >>> > (/etc/selinux/targeted/tmp/seusers.local: 5): >>> > lastname firstname at domain.com:unconfined_u:s0-s0:c0.c1023 (No such file >>> or >>> > directory). >>> > libsemanage.seuser_parse: could not parse seuser record (No such file or >>> > directory). >>> > libsemanage.dbase_file_cache: could not cache file database (No such file >>> > or directory). >>> > libsemanage.semanage_base_merge_components: could not merge local >>> > modifications into policy (No such file or directory). >>> > >>> >>> Hi, >>> according to my quick testing this is solved with this PR: >>> https://github.com/SSSD/sssd/pull/189 >This patch will not help with spaces in name. > >it need to be fixed in selinux-policy or libsemanage. > It looks like it happen with each upgrade of selinux-policy. I assume it might be some missing quoting in rpm bash scriptlet. It should not be difficult to reproduce and file a bug. Feel free to add to CC my mail. LS From ronaldw at ronzo.at Tue Apr 4 07:51:04 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Tue, 4 Apr 2017 09:51:04 +0200 Subject: [Freeipa-users] SSSD hangs on IPA master Message-ID: Hi, my IPA master has an AD trust (several thousand users). Since the trust has been set up I am experiencing that I cannot login on the web interface. Even connecting via SSH does not work or takes extremely long. When I managed to log in as root via SSH (after waiting and trying several times or rebooting the machine) I could not restart SSSD (systemctl restart sssd). I had to kill the SSSD processes manually and then everything seemed to work fine again. What could be going on? Could the SSSD cache be to big (122M)? Where should I take a deeper look? Any hints are highly appreciated! Regards, Ronald From jhrozek at redhat.com Tue Apr 4 09:19:04 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 4 Apr 2017 11:19:04 +0200 Subject: [Freeipa-users] SSSD hangs on IPA master In-Reply-To: References: Message-ID: <20170404091904.gwlofxwejlcc4mqz@hendrix> On Tue, Apr 04, 2017 at 09:51:04AM +0200, Ronald Wimmer wrote: > Hi, > > my IPA master has an AD trust (several thousand users). Since the trust has > been set up I am experiencing that I cannot login on the web interface. Even > connecting via SSH does not work or takes extremely long. When I managed to > log in as root via SSH (after waiting and trying several times or rebooting > the machine) I could not restart SSSD (systemctl restart sssd). I had to > kill the SSSD processes manually and then everything seemed to work fine > again. > > What could be going on? Could the SSSD cache be to big (122M)? Where should > I take a deeper look? > > Any hints are highly appreciated! SSSD logs that capture the problem are always a good start. From yamakasi.014 at gmail.com Tue Apr 4 18:35:42 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 4 Apr 2017 20:35:42 +0200 Subject: [Freeipa-users] Auto create kerberos/ldap SRV records on subdomain Message-ID: Hi guys, Is it possible to create in a simple way the SRV domains for kerberos on subdomains ? it's a pain to add them all manually when you have a lot of subdomains. I hope someone has a solution. Thanks! Matt From abokovoy at redhat.com Tue Apr 4 18:48:22 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 4 Apr 2017 21:48:22 +0300 Subject: [Freeipa-users] Auto create kerberos/ldap SRV records on subdomain In-Reply-To: References: Message-ID: <20170404184822.fnkaxjqldgizku2h@redhat.com> On ti, 04 huhti 2017, Matt . wrote: >Hi guys, > >Is it possible to create in a simple way the SRV domains for kerberos >on subdomains ? it's a pain to add them all manually when you have a >lot of subdomains. > >I hope someone has a solution. Create TXT record _kerberos.sub.domain.tld that contains name of your Kerberos realm in upper case. For MIT Kerberos clients this is enough to discover their proper Kerberos realm and DNS domain for SRV record discovery. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Tue Apr 4 18:50:16 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 4 Apr 2017 20:50:16 +0200 Subject: [Freeipa-users] Auto create kerberos/ldap SRV records on subdomain In-Reply-To: <20170404184822.fnkaxjqldgizku2h@redhat.com> References: <20170404184822.fnkaxjqldgizku2h@redhat.com> Message-ID: Hi Alexander, Superb, thanks a lot for this quick fix! Matt 2017-04-04 20:48 GMT+02:00 Alexander Bokovoy : > On ti, 04 huhti 2017, Matt . wrote: >> >> Hi guys, >> >> Is it possible to create in a simple way the SRV domains for kerberos >> on subdomains ? it's a pain to add them all manually when you have a >> lot of subdomains. >> >> I hope someone has a solution. > > Create TXT record _kerberos.sub.domain.tld that contains name of your > Kerberos realm in upper case. For MIT Kerberos clients this is enough to > discover their proper Kerberos realm and DNS domain for SRV record > discovery. > > -- > / Alexander Bokovoy From cherdt at umn.edu Tue Apr 4 23:17:28 2017 From: cherdt at umn.edu (Chris Herdt) Date: Tue, 4 Apr 2017 18:17:28 -0500 Subject: [Freeipa-users] Error deleting IPA host: SSL peer cannot verify your certificate Message-ID: Although I had previously been using a self-signed certificate, I recently started using a cert signed by InCommon CA on my FreeIPA master (still on IPA 3.0.0 at this time). I added the certificate and intermediate certificates to /etc/ssl/certs and the certificate database in /etc/dirsrc/slapd-EXAMPLE-COM. /etc/httpd/conf.d/nss.conf is pointing to the new certificate for NSSNickname. I can log into the web UI, but when I attempt to delete a host I get the following error: Operations Error Some entries were not deleted Show details Under "Show details": cannot connect to 'https://freeipa.example.com:443/ca/agent/ca/displayBySerial': (SSL_ERROR_BAD_CERT_ALERT) SSL peer cannot verify your certificate. Likewise, if I attempt to delete a host using the CLI I get an error message: # ipa host-del host-01.example.com ipa: ERROR: cert validation failed for "CN=freeipa.example.com,OU=Example Unit,O=Example Org,L=Example City,ST=MN,C=US" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cannot connect to Gettext('any of the configured servers', domain='ipa', localedir=None): https://freeipa.example.com/ipa/xml If I enable the verbose flag -vv, I see that it is making an HTTP POST request to https://freeipa.example.com/ipa/xml. It looks like Firefox on my local client trusts the certificate, but that the server itself does not trust its own certificate when connecting to itself. Can anyone advise on how I can address this issue? From flo at redhat.com Wed Apr 5 06:35:38 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 5 Apr 2017 08:35:38 +0200 Subject: [Freeipa-users] Error deleting IPA host: SSL peer cannot verify your certificate In-Reply-To: References: Message-ID: <9044c758-93a4-67b7-bc7d-01511381e9b7@redhat.com> On 04/05/2017 01:17 AM, Chris Herdt wrote: > Although I had previously been using a self-signed certificate, I > recently started using a cert signed by InCommon CA on my FreeIPA > master (still on IPA 3.0.0 at this time). > > I added the certificate and intermediate certificates to > /etc/ssl/certs and the certificate database in > /etc/dirsrc/slapd-EXAMPLE-COM. /etc/httpd/conf.d/nss.conf is pointing > to the new certificate for NSSNickname. > > I can log into the web UI, but when I attempt to delete a host I get > the following error: > > Operations Error > Some entries were not deleted > Show details > > Under "Show details": > cannot connect to > 'https://freeipa.example.com:443/ca/agent/ca/displayBySerial': > (SSL_ERROR_BAD_CERT_ALERT) SSL peer cannot verify your certificate. > > Likewise, if I attempt to delete a host using the CLI I get an error message: > > # ipa host-del host-01.example.com > ipa: ERROR: cert validation failed for > "CN=freeipa.example.com,OU=Example Unit,O=Example Org,L=Example > City,ST=MN,C=US" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate > issuer has been marked as not trusted by the user.) > ipa: ERROR: cannot connect to Gettext('any of the configured servers', > domain='ipa', localedir=None): https://freeipa.example.com/ipa/xml > > If I enable the verbose flag -vv, I see that it is making an HTTP POST > request to https://freeipa.example.com/ipa/xml. > > It looks like Firefox on my local client trusts the certificate, but > that the server itself does not trust its own certificate when > connecting to itself. Can anyone advise on how I can address this > issue? > Hi, the certificate and intermediate certificates need to be added to all the NSS databases used by FreeIPA. You can find instructions in the page "Using 3rd part certificates for HTTP/LDAP > Procedure in IPA < 4.1" [1]. HTH, Flo [1] http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 From mbasti at redhat.com Wed Apr 5 09:11:53 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Wed, 5 Apr 2017 11:11:53 +0200 Subject: [Freeipa-users] Upgrade from IPA 4.2 In-Reply-To: References: Message-ID: <53940b90-bebc-1203-5b0e-4a914f3fd714@redhat.com> On 04/04/2017 02:23 AM, Lachlan Musicman wrote: > > On 4 April 2017 at 04:28, Andrey Ptashnik > wrote: > > Hello, > > We have Centos 7.2 and IPA 4.2 version. > I remember that in previous versions in order to upgrade to the > latest one I had to run IPA upgrade scripts that would separately > upgrade LDAP database. Is that the same procedure if I need to > upgrade from version 4.2? > > > > Andrey, > > That wasn't my experience. We just did a yum update and it all seemed > to work. > > Given it's role, I presume you have or can set up a test env you can > try it on? > > cheers > L. > > ------ > The most dangerous phrase in the language is, "We've always done it > this way." > > - Grace Hopper > > > Yum upgrade should run upgrade script automatically. Now we have just one script ipa-server-upgrade Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Apr 5 13:28:42 2017 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 5 Apr 2017 07:28:42 -0600 Subject: [Freeipa-users] LDAPcon 2017 Message-ID: <733894d5-6516-a34c-0264-aacdbba7098f@redhat.com> This year's LDAPcon 2017 will be in Bruxelles 19th-20th October, 2017. Kudos to Paola PENATI and Benoit MORTIER at OpenSides for organizing the event. If you'd like to submit a conference talk then please have a look at the CfP: https://ldapcon.org/2017/call-for-papers/ Submission deadline : 28th May From greg at greg-gilbert.com Wed Apr 5 23:57:02 2017 From: greg at greg-gilbert.com (Greg Gilbert) Date: Wed, 5 Apr 2017 19:57:02 -0400 Subject: [Freeipa-users] How long should it take to propagate user role changes? Message-ID: <8dc58605-ed44-59e6-068b-5a12c4850534@greg-gilbert.com> Hey. I'm a bit new to FreeIPA, so apologies if this has already been addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7, and FreeIPA client 4.3.1 on Ubuntu nodes. I've noticed that when I make changes to policies, it either takes a long time to propagate out to the client nodes, or requires a manual restart of the sssd service. In this case, I'm testing adding and removing a user from a sudo rule. Is this the correct behavior, or is there a misconfiguration on my part somewhere? - greg From william.muriithi at gmail.com Thu Apr 6 00:25:17 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 5 Apr 2017 20:25:17 -0400 Subject: [Freeipa-users] Creating trust relationship that survive password rotation Message-ID: Good evening, I am looking through the IPA documentation and it looks like I will need a password that don't expire on the active directory side. These are the two documented ways. ipa trust-add --type=ad ad.example.com --admin Administrator ?password ipa trust-add --type=ad ad.example.com --trust-secret I had initially used the first method, but we recently started rotating the admin password. I suspect this has broken the trust and looking on a more durable solution. On closely reading through the trust secret section on the documentation, it looks like it also involve using a password. I thought I had read somewhere that trust can be done without a permanent password, but this don't seem like the case now. Is there a way of creating trust, without putting an none expire exception on the active directory trust account? Regards, William From wiml at omnigroup.com Thu Apr 6 05:38:48 2017 From: wiml at omnigroup.com (Wim Lewis) Date: Wed, 5 Apr 2017 22:38:48 -0700 Subject: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates In-Reply-To: <20170404014142.GX10261@dhcp-40-8.bne.redhat.com> References: <3E12EE86-4096-4F50-B39B-C9887E383A1C@omnigroup.com> <20170404014142.GX10261@dhcp-40-8.bne.redhat.com> Message-ID: <7B07469D-6B94-47C8-BEA5-C58B8D8171F1@omnigroup.com> With a bit of tweaking, I was able to generate a usable certificate by creating a second host entry, 'wildcard.blah.example.com', managed by blah.example.com, and then editing the leftmost label from 'wildcard' to '*' in all of the host's LDAP entry's properties. On Apr 3, 2017, at 6:41 PM, Fraser Tweedale wrote: > The only way is to create a profile that hard-codes the desired SAN > data, then use that profile. Out of curiosity, if my LDAP approach didn't work, how would I do that? I assume it involves `ipa certprofile-import`, but is there any documentation on the format it expects? The examples I've found have no mention of SANs at all, so it's not clear how I would hard code the desired SAN. > Is your instance publicly hosted? Perhaps the sandstorm.io > developers could support ACME/Let's Encrypt so that certs can be > automatically acquired for each domain... This would be possible, I assume, but it would couple the sandstorm instance rather tightly to its CA --- requiring the CA to issue a certificate for every new user session. Let's Encrypt does rate limiting which would prevent this, for example. An alternative would be to run a local sub-CA for uses like sandstorm, but this would require a CA to support issuing name-constrained sub-CAs (and if wildcard certs are considered too sloppily implemented in real-world clients to be trustworthy, then name constraints definitely are!). > But see also ?7.2 which states that wildcard certs are deprecated :) > https://tools.ietf.org/html/rfc6125#section-7.2 Only mostly deprecated; it admits of legitimate uses for them. :) Wildcards are not the best feature of the web PKI, I agree, and I wouldn't want to use them if I could think of a viable alternative. (And consider that putting domains in the CN has been deprecated since HTTPS/TLS was even a standard, back in 2000 --- yet everyone still does that.) From APtashnik at cccis.com Thu Apr 6 06:32:56 2017 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Thu, 6 Apr 2017 06:32:56 +0000 Subject: [Freeipa-users] Upgrade from IPA 4.2 In-Reply-To: <53940b90-bebc-1203-5b0e-4a914f3fd714@redhat.com> References: <53940b90-bebc-1203-5b0e-4a914f3fd714@redhat.com> Message-ID: Thank you for hint, Martin! Looks like upgrade went smooth just with yum upgrade. Following multi step upgrade in previous versions I was hesitant this time. Andrey From: Martin Ba?ti > Date: Wednesday, April 5, 2017 at 4:11 AM To: Lachlan Musicman >, Andrey Ptashnik > Cc: "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Upgrade from IPA 4.2 On 04/04/2017 02:23 AM, Lachlan Musicman wrote: On 4 April 2017 at 04:28, Andrey Ptashnik > wrote: Hello, We have Centos 7.2 and IPA 4.2 version. I remember that in previous versions in order to upgrade to the latest one I had to run IPA upgrade scripts that would separately upgrade LDAP database. Is that the same procedure if I need to upgrade from version 4.2? Andrey, That wasn't my experience. We just did a yum update and it all seemed to work. Given it's role, I presume you have or can set up a test env you can try it on? cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper Yum upgrade should run upgrade script automatically. Now we have just one script ipa-server-upgrade Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Apr 6 07:01:00 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Apr 2017 10:01:00 +0300 Subject: [Freeipa-users] Creating trust relationship that survive password rotation In-Reply-To: References: Message-ID: <20170406070100.n2hnx7jietl7p3wl@redhat.com> On ke, 05 huhti 2017, William Muriithi wrote: >Good evening, > >I am looking through the IPA documentation and it looks like I will >need a password that don't expire on the active directory side. No. > >These are the two documented ways. > >ipa trust-add --type=ad ad.example.com --admin Administrator ?password >ipa trust-add --type=ad ad.example.com --trust-secret > >I had initially used the first method, but we recently started >rotating the admin password. I suspect this has broken the trust and >looking on a more durable solution. You need administrator's password once -- to establish trust. It is *not* used for anything else once you established trust. >On closely reading through the trust secret section on the >documentation, it looks like it also involve using a password. I >thought I had read somewhere that trust can be done without a >permanent password, but this don't seem like the case now. > >Is there a way of creating trust, without putting an none expire >exception on the active directory trust account? Right now AD DCs trying to rotate password for trusted domain object account will fail. We do not support this rotation on IPA side. So it does not matter what AD tries to do -- as password cannot be set remotely, it is not rotated. -- / Alexander Bokovoy From mbasti at redhat.com Thu Apr 6 07:11:32 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Thu, 6 Apr 2017 09:11:32 +0200 Subject: [Freeipa-users] How long should it take to propagate user role changes? In-Reply-To: <8dc58605-ed44-59e6-068b-5a12c4850534@greg-gilbert.com> References: <8dc58605-ed44-59e6-068b-5a12c4850534@greg-gilbert.com> Message-ID: <03fc10d8-e110-0df6-5ec2-e019c6e2a14d@redhat.com> On 06.04.2017 01:57, Greg Gilbert wrote: > Hey. I'm a bit new to FreeIPA, so apologies if this has already been > addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7, > and FreeIPA client 4.3.1 on Ubuntu nodes. > > I've noticed that when I make changes to policies, it either takes a > long time to propagate out to the client nodes, or requires a manual > restart of the sssd service. In this case, I'm testing adding and > removing a user from a sudo rule. Is this the correct behavior, or is > there a misconfiguration on my part somewhere? > > - greg > Hello, it is caused by SSSD caches, to refresh particular objects in cache see `man sss_cache`. You can lower TTL for records in cache, but the lower TTL, the higher load on server (`man sssd.conf` search for cache). Martin -- Martin Ba?ti Software Engineer Red Hat Czech From ftweedal at redhat.com Thu Apr 6 07:50:44 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 6 Apr 2017 17:50:44 +1000 Subject: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates In-Reply-To: <7B07469D-6B94-47C8-BEA5-C58B8D8171F1@omnigroup.com> References: <3E12EE86-4096-4F50-B39B-C9887E383A1C@omnigroup.com> <20170404014142.GX10261@dhcp-40-8.bne.redhat.com> <7B07469D-6B94-47C8-BEA5-C58B8D8171F1@omnigroup.com> Message-ID: <20170406075044.GG10261@dhcp-40-8.bne.redhat.com> On Wed, Apr 05, 2017 at 10:38:48PM -0700, Wim Lewis wrote: > With a bit of tweaking, I was able to generate a usable > certificate by creating a second host entry, > 'wildcard.blah.example.com', managed by blah.example.com, and then > editing the leftmost label from 'wildcard' to '*' in all of the > host's LDAP entry's properties. > Suffice to say: this is not a supported or recommended approach :) > > On Apr 3, 2017, at 6:41 PM, Fraser Tweedale wrote: > > The only way is to create a profile that hard-codes the desired SAN > > data, then use that profile. > > Out of curiosity, if my LDAP approach didn't work, how would I do > that? I assume it involves `ipa certprofile-import`, but is there > any documentation on the format it expects? The examples I've > found have no mention of SANs at all, so it's not clear how I > would hard code the desired SAN. > Have a look at: https://www.redhat.com/archives/pki-users/2014-January/msg00005.html Based on the example there you would change a couple of config. policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName policyset.serverCertSet.9.default.params.subjAltExtPattern_0=*.blah.exmaple.com The rest of the profile config could be a direct copy of caIPAserviceCert, although it would be sensible to remote the 'userExtDefault' component, which is used to copy a SAN extension from the CSR, would could cause a conflict. > > Is your instance publicly hosted? Perhaps the sandstorm.io > > developers could support ACME/Let's Encrypt so that certs can be > > automatically acquired for each domain... > > This would be possible, I assume, but it would couple the > sandstorm instance rather tightly to its CA --- requiring the CA > to issue a certificate for every new user session. Let's Encrypt > does rate limiting which would prevent this, for example. > Right. Let's Encrypt does rate limit per registered domain (max 20 per week according to [1]). So that would seem to be too low for your use case. [1] https://letsencrypt.org/docs/rate-limits/ > An alternative would be to run a local sub-CA for uses like > sandstorm, but this would require a CA to support issuing > name-constrained sub-CAs (and if wildcard certs are considered too > sloppily implemented in real-world clients to be trustworthy, then > name constraints definitely are!). > If you trust the IPA CA, you could create a sub-CA under it, export it, and use it with whatever software can meet your needs. But this leads me to the question: are you using FreeIPA already and trying to work out how to fit the Sandstorm use case into it? Or are you just looking for a solution for Sandstorm? > > But see also ?7.2 which states that wildcard certs are > > deprecated :) https://tools.ietf.org/html/rfc6125#section-7.2 > > Only mostly deprecated; it admits of legitimate uses for them. :) > Wildcards are not the best feature of the web PKI, I agree, and I > wouldn't want to use them if I could think of a viable > alternative. > The fact that you are looking at FreeIPA suggests that you will be anchoring your trust at some private CA (not a publicly trusted CA). If that is the case, then you always have the viable option, "build the software you need". It may not exist OOTB but AFAICS there is nothing fundamentally difficult about your use case. > (And consider that putting domains in the CN has been deprecated > since HTTPS/TLS was even a standard, back in 2000 --- yet everyone > still does that.) > Sure, but do not hold it against us if we follow the standards :) Thanks, Fraser From jhrozek at redhat.com Thu Apr 6 08:01:18 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 6 Apr 2017 10:01:18 +0200 Subject: [Freeipa-users] How long should it take to propagate user role changes? In-Reply-To: <03fc10d8-e110-0df6-5ec2-e019c6e2a14d@redhat.com> References: <8dc58605-ed44-59e6-068b-5a12c4850534@greg-gilbert.com> <03fc10d8-e110-0df6-5ec2-e019c6e2a14d@redhat.com> Message-ID: <20170406080118.7cd2pmxy7465agys@hendrix> On Thu, Apr 06, 2017 at 09:11:32AM +0200, Martin Ba?ti wrote: > > > On 06.04.2017 01:57, Greg Gilbert wrote: > > Hey. I'm a bit new to FreeIPA, so apologies if this has already been > > addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7, > > and FreeIPA client 4.3.1 on Ubuntu nodes. > > > > I've noticed that when I make changes to policies, it either takes a > > long time to propagate out to the client nodes, or requires a manual > > restart of the sssd service. In this case, I'm testing adding and > > removing a user from a sudo rule. Is this the correct behavior, or is > > there a misconfiguration on my part somewhere? > > > > - greg > > > > Hello, > > it is caused by SSSD caches, to refresh particular objects in cache see `man > sss_cache`. > > You can lower TTL for records in cache, but the lower TTL, the higher load > on server (`man sssd.conf` search for cache). btw the sudo caching is a bit more complex, but man sssd-sudo hopefully explains it well. Also please check in the sssd debug logs if the sssd client is 'online'. From ronaldw at ronzo.at Thu Apr 6 09:06:50 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 6 Apr 2017 11:06:50 +0200 Subject: [Freeipa-users] SSSD hangs on IPA master In-Reply-To: <20170404091904.gwlofxwejlcc4mqz@hendrix> References: <20170404091904.gwlofxwejlcc4mqz@hendrix> Message-ID: On 2017-04-04 11:19, Jakub Hrozek wrote: > On Tue, Apr 04, 2017 at 09:51:04AM +0200, Ronald Wimmer wrote: >> Hi, >> >> my IPA master has an AD trust (several thousand users). Since the trust has >> been set up I am experiencing that I cannot login on the web interface. Even >> connecting via SSH does not work or takes extremely long. When I managed to >> log in as root via SSH (after waiting and trying several times or rebooting >> the machine) I could not restart SSSD (systemctl restart sssd). I had to >> kill the SSSD processes manually and then everything seemed to work fine >> again. >> >> What could be going on? Could the SSSD cache be to big (122M)? Where should >> I take a deeper look? >> >> Any hints are highly appreciated! > SSSD logs that capture the problem are always a good start. > I found out that the CPU was quite busy (sssd_be process) and that there was a lot I/O in the cache directory. So I upgraded from 1 to 4 virtual CPUs and followed your recommendations regarding large deployments: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ No problems so far... Regards, Ronald From ronaldw at ronzo.at Thu Apr 6 10:10:29 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 6 Apr 2017 12:10:29 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work Message-ID: Hi, when I try to login to an IPA client with my AD user it works perfectly when I already have a kerberos ticket for my user. When I do not and I try a password-based login it fails: Password-based: (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [myuser at xyz.mydomain.at@xyz.mydomain.at] (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is myuser at xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): user: myuser at xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 31816 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: myuser (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f4c122ed450 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f4c122ed450 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f4c122e59c0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][XYZ] (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f4c122f4640][21] When I have a Kerberos ticket: (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [myuser at xyz.mydomain.at@xyz.mydomain.at] (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is myuser at xyz.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): user: myuser at xyz.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 31841 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: myuser (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f4c122ec4a0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f4c122ec4a0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f4c122e59c0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][XYZ] (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f4c122f4640][21] My question is why? Regards, Ronald From sbose at redhat.com Thu Apr 6 09:21:22 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Apr 2017 11:21:22 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: References: Message-ID: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote: > Hi, > > when I try to login to an IPA client with my AD user it works perfectly when > I already have a kerberos ticket for my user. When I do not and I try a > password-based login it fails: Please send the sssd_domain.log and krb5_child.log form the same time as well. bye, Sumit > > Password-based: > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_check_user_search] (0x0400): > Returning info for user [myuser at xyz.mydomain.at@xyz.mydomain.at] > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): > User's primary name is myuser at xyz.mydomain.at > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): command: > SSS_PAM_PREAUTH > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: > XYZ > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): user: > myuser at xyz.mydomain.at > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not > set > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: > chupacabra.ipa.mydomain.at > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok > type: 0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 31816 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): logon > name: myuser > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): > 0x7f4c122ed450 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x7f4c122ed450 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x7f4c122e59c0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [4 (System error)][XYZ] > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [4]: System error. > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x7f4c122f4640][21] > > When I have a Kerberos ticket: > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_check_user_search] (0x0400): > Returning info for user [myuser at xyz.mydomain.at@xyz.mydomain.at] > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): > User's primary name is myuser at xyz.mydomain.at > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): command: > SSS_PAM_OPEN_SESSION > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: > XYZ > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): user: > myuser at xyz.mydomain.at > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not > set > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: > chupacabra.ipa.mydomain.at > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok > type: 0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 31841 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): logon > name: myuser > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): > 0x7f4c122ec4a0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x7f4c122ec4a0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x7f4c122e59c0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [0 (Success)][XYZ] > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [0]: Success. > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x7f4c122f4640][21] > > My question is why? > > Regards, > Ronald > > -- > 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 ronaldw at ronzo.at Thu Apr 6 10:58:32 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 6 Apr 2017 12:58:32 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> On 2017-04-06 11:21, Sumit Bose wrote: > On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote: >> Hi, >> >> when I try to login to an IPA client with my AD user it works perfectly when >> I already have a kerberos ticket for my user. When I do not and I try a >> password-based login it fails: > Please send the sssd_domain.log and krb5_child.log form the same time as > well. > AD trust: mydomain.at (forest root) xyz (subdomain -> where myuser resides) BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. sssd_domain.log snippet: [....] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f14f467feb0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.pamHandler on path /org/freedesktop/sssd/dataprovider (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_pam_handler] (0x0100): Got request with the following data (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): user: myuser at xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): ruser: (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): cli_pid: 31812 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): logon name: not set (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #15]: New request. Flags [0000]. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [krb5_auth_queue_send] (0x1000): Wait queue of user [myuser at xyz.mydomain.at] is empty, running request [0x7f14f4670f70] immediately. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [krb5_setup] (0x4000): No mapping for: myuser at xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f14f468c030 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f14f468c0f0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Running timer event 0x7f14f468c030 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Destroying timer event 0x7f14f468c0f0 "ltdb_timeout" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Ending timer event 0x7f14f468c030 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f14f46aad10 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f14f468c4a0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Running timer event 0x7f14f46aad10 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Destroying timer event 0x7f14f468c4a0 "ltdb_timeout" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Ending timer event 0x7f14f46aad10 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_server_status] (0x1000): Status of server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_server_status] (0x1000): Status of server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [be_resolve_server_process] (0x0200): Found address for server ipa1.ipa.mydomain.at: [10.66.39.130] TTL 86400 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa1.ipa.mydomain.at' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/pubconf/.krb5info_dummy_hs3EBJ] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/pubconf/.krb5info_dummy_hs3EBJ] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [31814] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_handler_setup] (0x2000): Signal handler set up for pid [31814] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_sig_handler] (0x1000): Waiting for child [31814]. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_sig_handler] (0x0100): child [31814] finished successfully. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: src/providers/krb5/krb5_auth.c: krb5_auth_done: 939 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'ipa1.ipa.mydomain.at' as 'not working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'ipa1.ipa.mydomain.at' as 'not working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_server_status] (0x1000): Status of server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa1.ipa.mydomain.at' is 'not working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_server_status] (0x1000): Status of server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa1.ipa.mydomain.at' is 'not working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [be_mark_dom_offline] (0x1000): Marking subdomain xyz.mydomain.at offline (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [be_mark_subdom_offline] (0x1000): Marking subdomain xyz.mydomain.at as inactive (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [31815] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_handler_setup] (0x2000): Signal handler set up for pid [31815] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_sig_handler] (0x1000): Waiting for child [31815]. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [child_sig_handler] (0x0100): child [31815] finished successfully. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [parse_krb5_child_response] (0x1000): child response [0][3][41]. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_WORKING. Called from: src/providers/krb5/krb5_auth.c: krb5_auth_done: 1036 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'ipa1.ipa.mydomain.at' as 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [set_server_common_status] (0x0100): Marking server 'ipa1.ipa.mydomain.at' as 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'ipa1.ipa.mydomain.at' as 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [krb5_mod_ccname] (0x4000): Save ccname [KEYRING:persistent:1073895519] for user [myuser at xyz.mydomain.at]. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f14f46b1d80 [...] krb5_child.log snippet: (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [main] (0x0400): krb5_child started. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [unpack_buffer] (0x1000): total buffer size: [156] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [unpack_buffer] (0x0100): cmd [241] uid [1073895519] gid [1073895519] validate [true] enterprise principal [false] offline [false] UPN [myuser at BCC.MYDOMAIN.AT] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1073895519] old_ccname: [KEYRING:persistent:1073895519] keytab: [/etc/krb5.keytab] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [switch_creds] (0x0200): Switch user to [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1073895519] and is not active and TGT is valid. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/testclient.ipa.mydomain.at at LINUX.MYDOMAIN.AT] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/testclient.ipa.mydomain.at at LINUX.MYDOMAIN.AT in keytab. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [match_principal] (0x1000): Principal matched to the sample (host/testclient.ipa.mydomain.at at LINUX.MYDOMAIN.AT). (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [become_user] (0x0200): Trying to become user [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [main] (0x2000): Running as [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [k5c_setup] (0x2000): Running as [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [main] (0x0400): Will perform online auth (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [BCC.MYDOMAIN.AT] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.830664: Getting initial credentials for myuser at BCC.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.830855: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_LINUX.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.830976: Retrieving host/testclient.ipa.mydomain.at at LINUX.MYDOMAIN.AT -> krb5_ccache_conf_data/fast_avail/krbtgt\/BCC.MYDOMAIN.AT\@BCC.MYDOMAIN.AT at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_LINUX.MYDOMAIN.AT with result: -1765328243/Matching credential not found (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.831121: Sending request (167 bytes) to BCC.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.834221: Retrying AS request with master KDC (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.834290: Getting initial credentials for myuser at BCC.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.834368: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_LINUX.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.834434: Retrieving host/testclient.ipa.mydomain.at at LINUX.MYDOMAIN.AT -> krb5_ccache_conf_data/fast_avail/krbtgt\/BCC.MYDOMAIN.AT\@BCC.MYDOMAIN.AT at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_LINUX.MYDOMAIN.AT with result: -1765328243/Matching credential not found (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [sss_child_krb5_trace_cb] (0x4000): [31814] 1491467952.834506: Sending request (167 bytes) to BCC.MYDOMAIN.AT (master) (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [get_and_save_tgt] (0x0020): 1296: [-1765328230][Cannot find KDC for realm "BCC.MYDOMAIN.AT"] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [map_krb5_error] (0x0020): 1365: [-1765328230][Cannot find KDC for realm "BCC.MYDOMAIN.AT"] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [k5c_send_data] (0x0200): Received error code 1432158228 (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [pack_response_packet] (0x2000): response packet size: [4] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [k5c_send_data] (0x4000): Response sent. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31814]]]] [main] (0x0400): krb5_child completed successfully (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [main] (0x0400): krb5_child started. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [unpack_buffer] (0x1000): total buffer size: [156] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [unpack_buffer] (0x0100): cmd [241] uid [1073895519] gid [1073895519] validate [true] enterprise principal [false] offline [true] UPN [myuser at BCC.MYDOMAIN.AT] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1073895519] old_ccname: [KEYRING:persistent:1073895519] keytab: [/etc/krb5.keytab] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [switch_creds] (0x0200): Switch user to [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1073895519] and is not active and TGT is valid. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [become_user] (0x0200): Trying to become user [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [main] (0x2000): Running as [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [become_user] (0x0200): Trying to become user [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [become_user] (0x0200): Already user [1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [k5c_setup] (0x2000): Running as [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [main] (0x0400): Will perform offline auth (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [k5c_send_data] (0x0200): Received error code 0 (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [pack_response_packet] (0x2000): response packet size: [53] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [k5c_send_data] (0x4000): Response sent. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31815]]]] [main] (0x0400): krb5_child completed successfully (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [main] (0x0400): krb5_child started. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [unpack_buffer] (0x1000): total buffer size: [51] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [unpack_buffer] (0x0100): cmd [249] uid [1073895519] gid [1073895519] validate [true] enterprise principal [false] offline [true] UPN [myuser at BCC.MYDOMAIN.AT] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [become_user] (0x0200): Trying to become user [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [main] (0x2000): Running as [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [become_user] (0x0200): Trying to become user [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [become_user] (0x0200): Already user [1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [k5c_setup] (0x2000): Running as [1073895519][1073895519]. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [main] (0x0400): Will perform pre-auth (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [BCC.MYDOMAIN.AT] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [sss_child_krb5_trace_cb] (0x4000): [31817] 1491467952.889026: Getting initial credentials for myuser at BCC.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [sss_child_krb5_trace_cb] (0x4000): [31817] 1491467952.889307: Sending request (167 bytes) to BCC.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [sss_child_krb5_trace_cb] (0x4000): [31817] 1491467952.892050: Retrying AS request with master KDC (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [sss_child_krb5_trace_cb] (0x4000): [31817] 1491467952.892107: Getting initial credentials for myuser at BCC.MYDOMAIN.AT (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [sss_child_krb5_trace_cb] (0x4000): [31817] 1491467952.892252: Sending request (167 bytes) to BCC.MYDOMAIN.AT (master) (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328230} during pre-auth. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [k5c_send_data] (0x0200): Received error code 0 (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [pack_response_packet] (0x2000): response packet size: [4] (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [k5c_send_data] (0x4000): Response sent. (Thu Apr 6 10:39:12 2017) [[sssd[krb5_child[31817]]]] [main] (0x0400): krb5_child completed successfully Regards, Ronald From ronaldw at ronzo.at Thu Apr 6 11:12:06 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 6 Apr 2017 13:12:06 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> Message-ID: <281814a2-a69b-4da5-f20e-c1cc2dccabdf@ronzo.at> On 2017-04-06 12:58, Ronald Wimmer wrote: > [...] > BCC (appearing in krb5_child.log) is not a domain here. It is my > company's name and might derive from some information in the AD. > After doing an LDAP search on the domain controller of my AD domain (xyz.mydomain.at) I found out that my userPrincipalName is myuser at bcc.mydomain.at - this can definitely not be changed! From sbose at redhat.com Thu Apr 6 10:16:19 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Apr 2017 12:16:19 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> Message-ID: <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > On 2017-04-06 11:21, Sumit Bose wrote: > > On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote: > > > Hi, > > > > > > when I try to login to an IPA client with my AD user it works perfectly when > > > I already have a kerberos ticket for my user. When I do not and I try a > > > password-based login it fails: > > Please send the sssd_domain.log and krb5_child.log form the same time as > > well. > > > > AD trust: > mydomain.at (forest root) > xyz (subdomain -> where myuser resides) > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's > name and might derive from some information in the AD. Yes, it is about the userPrincipalName attribute read from AD. Which IPA server version do you use? Since RHEL-7.3 IPA supports those principals coming from AD. For older versions you should add a workaround which is e.g. described at the end of https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html HTH bye, Sumit From ronaldw at ronzo.at Thu Apr 6 11:55:02 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 6 Apr 2017 13:55:02 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> On 2017-04-06 12:16, Sumit Bose wrote: > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > [...] >> AD trust: >> mydomain.at (forest root) >> xyz (subdomain -> where myuser resides) >> >> BCC (appearing in krb5_child.log) is not a domain here. It is my company's >> name and might derive from some information in the AD. > Yes, it is about the userPrincipalName attribute read from AD. Which IPA > server version do you use? Since RHEL-7.3 IPA supports those principals > coming from AD. For older versions you should add a workaround which is > e.g. described at the end of > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html > > HTH > > bye, > Sumit I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to override it? From freeipa at nehlsen.se Thu Apr 6 15:33:58 2017 From: freeipa at nehlsen.se (Mikael) Date: Thu, 6 Apr 2017 17:33:58 +0200 Subject: [Freeipa-users] Problem with sid creation In-Reply-To: References: Message-ID: <20177dfa-48fd-3e14-eaa7-40db9ed66700@nehlsen.se> Hello! I try to create sids for all my users when running ipa-adtrust-install but there are no signs of the sids in ldap and I get the following error in the error log for the directory server. [06/Apr/2017:17:18:02.336841997 +0200] sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [06/Apr/2017:17:18:02.343570622 +0200] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [662] into an unused SID. [06/Apr/2017:17:18:02.344113670 +0200] do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [06/Apr/2017:17:18:02.344760841 +0200] sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. Any idea why? /Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at greg-gilbert.com Thu Apr 6 15:47:40 2017 From: greg at greg-gilbert.com (greg at greg-gilbert.com) Date: Thu, 06 Apr 2017 11:47:40 -0400 Subject: [Freeipa-users] How long should it take to propagate user role changes? In-Reply-To: <03fc10d8-e110-0df6-5ec2-e019c6e2a14d@redhat.com> References: <8dc58605-ed44-59e6-068b-5a12c4850534@greg-gilbert.com> <03fc10d8-e110-0df6-5ec2-e019c6e2a14d@redhat.com> Message-ID: <870a3f630fac7ee1e55201a416440cee@greg-gilbert.com> Hey, Is that the sssd configuration on the server or the client? There's no sss_cache executable on the client; is that correct? I noticed that when I remove a user from the sudo role, the clients notice it almost immediately, but when I readd the sudo role, it doesn't come back. I usually have to restart sssd on the client. I tried setting entry_cache_timeout on the client to 60 and even setting cache_credentials to false, but those don't seem to have changed anything. For reference, here's part of the sssd.conf on the client: [domain/ipa.services.FOO] cache_credentials = False krb5_store_password_if_offline = True ipa_domain = ipa.services.FOO id_provider = ipa auth_provider = ipa access_provider = permit ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = 10.100.15.40 chpass_provider = ipa ipa_server = _srv_, ipa.services.FOO dns_discovery_domain = ipa.services.FOO entry_cache_timeout = 60 Am I doing something wrong here? On 2017-04-06 03:11, Martin Ba?ti wrote: > On 06.04.2017 01:57, Greg Gilbert wrote: > >> Hey. I'm a bit new to FreeIPA, so apologies if this has already been addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7, and FreeIPA client 4.3.1 on Ubuntu nodes. >> >> I've noticed that when I make changes to policies, it either takes a long time to propagate out to the client nodes, or requires a manual restart of the sssd service. In this case, I'm testing adding and removing a user from a sudo rule. Is this the correct behavior, or is there a misconfiguration on my part somewhere? >> >> - greg > > Hello, > > it is caused by SSSD caches, to refresh particular objects in cache see `man sss_cache`. > > You can lower TTL for records in cache, but the lower TTL, the higher load on server (`man sssd.conf` search for cache). > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Apr 6 15:54:59 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Apr 2017 18:54:59 +0300 Subject: [Freeipa-users] Problem with sid creation In-Reply-To: <20177dfa-48fd-3e14-eaa7-40db9ed66700@nehlsen.se> References: <20177dfa-48fd-3e14-eaa7-40db9ed66700@nehlsen.se> Message-ID: <20170406155459.kzm2b2zygafcq3pv@redhat.com> On to, 06 huhti 2017, Mikael wrote: >Hello! > >I try to create sids for all my users when running ipa-adtrust-install >but there are no signs of the sids in ldap and I get the following >error in the error log for the directory server. > >[06/Apr/2017:17:18:02.336841997 +0200] sidgen_task_thread - [file >ipa_sidgen_task.c, line 194]: Sidgen task starts ... > >[06/Apr/2017:17:18:02.343570622 +0200] find_sid_for_ldap_entry - [file >ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [662] into an >unused SID. > >[06/Apr/2017:17:18:02.344113670 +0200] do_work - [file >ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. > >[06/Apr/2017:17:18:02.344760841 +0200] sidgen_task_thread - [file >ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. > > >Any idea why? Read https://www.redhat.com/archives/freeipa-users/2017-February/msg00114.html and the corresponding thread. -- / Alexander Bokovoy From greg at greg-gilbert.com Thu Apr 6 16:01:29 2017 From: greg at greg-gilbert.com (greg at greg-gilbert.com) Date: Thu, 06 Apr 2017 12:01:29 -0400 Subject: [Freeipa-users] How long should it take to propagate user role changes? In-Reply-To: <870a3f630fac7ee1e55201a416440cee@greg-gilbert.com> References: <8dc58605-ed44-59e6-068b-5a12c4850534@greg-gilbert.com> <03fc10d8-e110-0df6-5ec2-e019c6e2a14d@redhat.com> <870a3f630fac7ee1e55201a416440cee@greg-gilbert.com> Message-ID: <2b34d58cf389963a4262fe8ffdd8b790@greg-gilbert.com> Actually I just saw Jakub's response, and that helped me out. I just added this to the sssd.conf on the client, and it seems to work: [domain/ipa.services.FOO] ldap_sudo_smart_refresh_interval = 60 ldap_sudo_full_refresh_interval = 21600 Thanks, all! On 2017-04-06 11:47, greg at greg-gilbert.com wrote: > Hey, > > Is that the sssd configuration on the server or the client? There's no sss_cache executable on the client; is that correct? > > I noticed that when I remove a user from the sudo role, the clients notice it almost immediately, but when I readd the sudo role, it doesn't come back. I usually have to restart sssd on the client. I tried setting entry_cache_timeout on the client to 60 and even setting cache_credentials to false, but those don't seem to have changed anything. For reference, here's part of the sssd.conf on the client: > > [domain/ipa.services.FOO] > > cache_credentials = False > krb5_store_password_if_offline = True > ipa_domain = ipa.services.FOO > id_provider = ipa > auth_provider = ipa > access_provider = permit > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = 10.100.15.40 > chpass_provider = ipa > ipa_server = _srv_, ipa.services.FOO > dns_discovery_domain = ipa.services.FOO > entry_cache_timeout = 60 > > Am I doing something wrong here? > > On 2017-04-06 03:11, Martin Ba?ti wrote: > > On 06.04.2017 01:57, Greg Gilbert wrote: Hey. I'm a bit new to FreeIPA, so apologies if this has already been addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7, and FreeIPA client 4.3.1 on Ubuntu nodes. > > I've noticed that when I make changes to policies, it either takes a long time to propagate out to the client nodes, or requires a manual restart of the sssd service. In this case, I'm testing adding and removing a user from a sudo rule. Is this the correct behavior, or is there a misconfiguration on my part somewhere? > > - greg > > Hello, > > it is caused by SSSD caches, to refresh particular objects in cache see `man sss_cache`. > > You can lower TTL for records in cache, but the lower TTL, the higher load on server (`man sssd.conf` search for cache). > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From iulian.roman at gmail.com Thu Apr 6 16:14:33 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Thu, 6 Apr 2017 18:14:33 +0200 Subject: [Freeipa-users] ipa-getkeytab client equivalent for Unix Message-ID: Hello, Can anybody explain briefly what ipa-getkeytab runs under the hood in order to use similar logic for unix clients (will help in automating the registration to IPA server) ? Thank You ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stijn.deweirdt at ugent.be Thu Apr 6 16:29:58 2017 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Thu, 6 Apr 2017 18:29:58 +0200 Subject: [Freeipa-users] user keytab retrieval Message-ID: hi all, (this is IPA 4.4.0-14.el7.centos.4) i'm a bit puzzled by the following: i want to retrieve a user keytab using ipa-getkeytab -r (since the keytab for the same user was already retrieved on another host). when doing so, i get Failed to parse result: Insufficient access rights however, i can get the keytab without the -r option. anyone care to explain what access rights are required (or why this error occurs)? many thanks, stijn From mike at chinewalking.com Thu Apr 6 17:21:01 2017 From: mike at chinewalking.com (mike at chinewalking.com) Date: Thu, 06 Apr 2017 19:21:01 +0200 Subject: [Freeipa-users] Fwd: Marking subdomain offline Message-ID: Hi, My IPA<->AD trust setup experiences intermittent failures during login events. The AD subdomain goes in an inactive/offline state and users logging in are put into a 'delayed authentication' queue. Usually logging in after a minute or so succeeds as the subdomain is reset and the user is cached for following events. At all times getent/id and kinit's are succesfull, even with a purged sssd cache. SRV records are correctly resolved, except for _kerberos-master. I have not been able to further troubleshoot the intermittent failures. Traffic captures show no strange behaviour, yet the sssd_domain log is clearly showing AD to be unreachable at times. All AD servers are W2012 and DNS masking _ldap and _kerberos to single nodes, factoring out any faulty Windows configs, so far has not had any effect (Would it?). sssd's data_provider_fo.c :> be_fo_reset_svc() calls fo_get_service(), which returns EOK. I'm not familiar yet with the variables at play, would adding debug statements here reveal faults that may cause this? Any pointers are very much appreciated. Mike [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain lookup failed, will try to reset sudomain.. [sssd[be[unix.foo.local]]] [ipa_server_trusted_dom_setup_send] (0x1000): Trust direction of subdom foo.local from forest foo.local is: one-way inbound: local domain trusts the remote domain [sssd[be[unix.foo.local]]] [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for foo.local [sssd[be[unix.foo.local]]] [ipa_getkeytab_send] (0x0400): Retrieving keytab for UNIX$@FOO.local from ipa01.unix.foo.local into /var/lib/sss/keytabs/foo.local.keytab6AXxWV using ccache /var/lib/sss/db/ccache_UNIX.FOO.local [sssd[be[unix.foo.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [6242] [sssd[be[unix.foo.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [6242] [sssd[be[unix.foo.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f71cd9ddb80], connected[1], ops[(nil)], ldap[0x7f71cd9e65a0] [sssd[be[unix.foo.local]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list [sssd[be[unix.foo.local]]] [ad_online_cb] (0x0400): The AD provider is online [sssd[be[unix.foo.local]]] [be_ptask_online_cb] (0x0400): Back end is online [sssd[be[unix.foo.local]]] [be_ptask_enable] (0x0080): Task [Subdomains Refresh]: already enabled Keytab successfully retrieved and stored in: /var/lib/sss/keytabs/foo.local.keytab6AXxWV [sssd[be[unix.foo.local]]] [child_sig_handler] (0x1000): Waiting for child [6242]. [sssd[be[unix.foo.local]]] [child_sig_handler] (0x0100): child [6242] finished successfully. [sssd[be[unix.foo.local]]] [ipa_getkeytab_recv] (0x2000): ipa-getkeytab status 0 [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): Keytab successfully retrieved to /var/lib/sss/keytabs/foo.local.keytab6AXxWV [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x2000): Keytab renamed to /var/lib/sss/keytabs/foo.local.keytab [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): Keytab /var/lib/sss/keytabs/foo.local.keytab6AXxWV contains the expected principals [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): Established trust context for foo.local [sssd[be[unix.foo.local]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/keytabs/foo.local.keytab6AXxWV] [sssd[be[unix.foo.local]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/keytabs/foo.local.keytab6AXxWV] [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_retried] (0x0400): Sudomain re-set, will retry lookup [sssd[be[unix.foo.local]]] [be_fo_reset_svc] (0x1000): Resetting all servers in service foo.local [sssd[be[unix.foo.local]]] [be_fo_reset_svc] (0x0080): Cannot retrieve service [foo.local] [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account [sssd[be[unix.foo.local]]] [be_mark_dom_offline] (0x1000): Marking subdomain foo.local offline [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. [sssd[be[unix.foo.local]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. [sssd[be[unix.foo.local]]] [dp_reply_std_set] (0x0080): DP Error is OK on failed request? [sssd[be[unix.foo.local]]] [dp_req_done] (0x0400): DP Request [Account #4]: Request handler finished [0]: Success From jhrozek at redhat.com Thu Apr 6 18:18:42 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 6 Apr 2017 20:18:42 +0200 Subject: [Freeipa-users] Fwd: Marking subdomain offline In-Reply-To: References: Message-ID: <20170406181842.ft5p7cjnsneiazpu@hendrix> On Thu, Apr 06, 2017 at 07:21:01PM +0200, mike at chinewalking.com wrote: > Hi, > > My IPA<->AD trust setup experiences intermittent failures during login > events. The AD subdomain goes in an inactive/offline state and users logging > in are put into a 'delayed authentication' queue. Usually logging in after a > minute or so succeeds as the subdomain is reset and the user is cached for > following events. At all times getent/id and kinit's are succesfull, even > with a purged sssd cache. > SRV records are correctly resolved, except for _kerberos-master. > > I have not been able to further troubleshoot the intermittent failures. > Traffic captures show no strange behaviour, yet the sssd_domain log is > clearly showing AD to be unreachable at times. All AD servers are W2012 and > DNS masking _ldap and _kerberos to single nodes, factoring out any faulty > Windows configs, so far has not had any effect (Would it?). > > sssd's data_provider_fo.c :> be_fo_reset_svc() calls fo_get_service(), which > returns EOK. I'm not familiar yet with the variables at play, would adding > debug statements here reveal faults that may cause this? Could you paste a bit more context? I think what would work is to trim the logs (truncate --size 0), then reproduce the issue and search for the first occurence of "NOT_WORKING" message from any of the fo_* functions. From spammewoods at cox.net Thu Apr 6 18:36:43 2017 From: spammewoods at cox.net (spammewoods at cox.net) Date: Thu, 6 Apr 2017 18:36:43 +0000 (GMT) Subject: [Freeipa-users] RHEL 6.9 AD Smart Card login Message-ID: <4a0752.33ae.15b448deccb.Webtop.0@cox.net> I have created a two way trust between my IDM server and Active Directory. I have been able to successful get RHEL 7.3 IDM server and RHEL 7.3 IDM clients to allow Active Directory login using CAC smart cards into Gnome. I'm using SSSD for the smart card login process instead of authconfig and pkcs11. I'm currently trying to get the same thing working for RHEL 6.9, but I have not been able to get it to work. The latest version of SSSD on RHEL 6.9 is 1.13.3 and from my understanding I need to have at least 1.14.0 for SSSD to handle AD smart card logins. So, I have tried to configure pam_pkcs11.conf file to use the pwent mapper to link the Common Name (CN) to the Active Directory User account. I have created an User ID Override for the AD user and added CN name from the Certificate on the smart card into the GECOS field. I also have added all three certificates from the CAC smart card into the User ID Override. When I try and log in, I get this error message in /var/log/secure: Apr 6 13:21:57 site-lws05 pam: gdm-smartcard: pam_pkcs11(gdm-smartcard:auth): pam_get_pwd() failed: Conversation error Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #1 Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #2 Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: pam_pkcs11(gdm-smartcard:auth): no valid certificate which meets all requirements found Here is the some details: IDM Domain: idm.domain.local Windows Domain: domain.local RHEL 7.3 IDM Server: site-idm01.idm.domain.local RHEL 6.9 IDM Client : site-lws05.idm.domain.local When I run the getent command on local accounts and IDM accounts I get user details, but when I run the command on AD accounts it doesn't find them. So, I'm wondering if that's why its not finding the CN name in the GECOS field. I'm trying to avoid using the cn_map on the clients, because we have a large amount of users and thats alot of extra work to manage that file. That's why I wanted to use the pwent mapper. Here is my SSSD config file from the RHEL 6.9 client: [domain/idm.domain.local] override_shell = /bin/bash debug_level = 9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = idm.domain.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = site-lws05.idm.domain.local chpass_provider = ipa ipa_server = _srv_, site-idm01.idm.domain.local ldap_tls_cacert = /etc/ipa/ca.crt [sssd] debug_level = 9 services = nss, sudo, pam, ssh, ifp domains = idm.domain.local certificate_verification = no_ocsp ldap_user_certificate = userCertificate;binary [nss] debug_level = 9 homedir_substring = /home [pam] debug_level = 9 pam_cert_auth = True [sudo] debug_level = 9 [autofs] debug_level = 9 [ssh] debug_level = 9 [pac] debug_level = 9 [ifp] debug_level = 9 Here is my nssswitch file from the RHEL 6.9 client: # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files nisplus nis #shadow: db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplus sudoers: files sss Here is my system-auth from the RHEL 6.9 client: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [success=1 default=ignore] pam_succeed_if.so service notin login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_pkcs11.so card_only auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Here is my password-auth from the RHEL 6.9 client: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Here is my smartcard-auth from the RHEL 6.9 client: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [success=done ignore=ignore default=die] pam_pkcs11.so wait_for_card card_only auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password required pam_pkcs11.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so From dag at sonsorol.org Thu Apr 6 18:39:02 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 06 Apr 2017 14:39:02 -0400 Subject: [Freeipa-users] Fwd: Marking subdomain offline In-Reply-To: References: Message-ID: <58E68B46.6030909@sonsorol.org> I see similar things in our environment where IPA is used as "glue" between AD Forests that have a 1-way trust relationship. We believe that the root cause has something to do with the 30+ domain controllers the IPA client tries to make contact with (in seemingly random order) across the AD Forest. Very hard to reproduce but the "subdomain marked offline" problem is one we see often in the sssd logs. We think that there are some AD servers in our sprawling environment that we either can't reach properly over the network (firewalls, etc.) or are just plain not configured to talk properly to us. Login success depends on hitting a happy domain controller. We are VERY interested in the recent updates to IPA server that seem to indicate we can 'pin" clients to certain specific AD controllers and from my understanding we just need to wait until the SSSD software gets broad support for this feature as well. Once we can do that we plan to pin our clients to named controllers and see if that helps with any of the intermittent login problems. One workaround we've started to use for power users is collecting public SSH keys and hosting them in the IPA server -- as long as IPA knows that the user "exists" in AD and has a roughly complete group membership list than logging in with SSH key instead of AD password bypasses the transient password checking failures and is very quick. Chris > mike at chinewalking.com > April 6, 2017 at 1:21 PM > Hi, > > My IPA<->AD trust setup experiences intermittent failures during login > events. The AD subdomain goes in an inactive/offline state and users > logging in are put into a 'delayed authentication' queue. Usually > logging in after a minute or so succeeds as the subdomain is reset and > the user is cached for following events. At all times getent/id and > kinit's are succesfull, even with a purged sssd cache. > SRV records are correctly resolved, except for _kerberos-master. > > I have not been able to further troubleshoot the intermittent > failures. Traffic captures show no strange behaviour, yet the > sssd_domain log is clearly showing AD to be unreachable at times. All > AD servers are W2012 and DNS masking _ldap and _kerberos to single > nodes, factoring out any faulty Windows configs, so far has not had > any effect (Would it?). > > sssd's data_provider_fo.c :> be_fo_reset_svc() calls fo_get_service(), > which returns EOK. I'm not familiar yet with the variables at play, > would adding debug statements here reveal faults that may cause this? > > Any pointers are very much appreciated. > > Mike > > > [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_step] (0x0400): > Looking up AD account > [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_done] (0x0080): > Sudomain lookup failed, will try to reset sudomain.. > [sssd[be[unix.foo.local]]] [ipa_server_trusted_dom_setup_send] > (0x1000): Trust direction of subdom foo.local from forest foo.local > is: one-way inbound: local domain trusts the remote domain > [sssd[be[unix.foo.local]]] [ipa_server_trusted_dom_setup_1way] > (0x0400): Will re-fetch keytab for foo.local > [sssd[be[unix.foo.local]]] [ipa_getkeytab_send] (0x0400): Retrieving > keytab for UNIX$@FOO.local from ipa01.unix.foo.local into > /var/lib/sss/keytabs/foo.local.keytab6AXxWV using ccache > /var/lib/sss/db/ccache_UNIX.FOO.local > [sssd[be[unix.foo.local]]] [child_handler_setup] (0x2000): Setting up > signal handler up for pid [6242] > [sssd[be[unix.foo.local]]] [child_handler_setup] (0x2000): Signal > handler set up for pid [6242] > [sssd[be[unix.foo.local]]] [sdap_process_result] (0x2000): Trace: > sh[0x7f71cd9ddb80], connected[1], ops[(nil)], ldap[0x7f71cd9e65a0] > [sssd[be[unix.foo.local]]] [sdap_process_result] (0x2000): Trace: end > of ldap_result list > [sssd[be[unix.foo.local]]] [ad_online_cb] (0x0400): The AD provider is > online > [sssd[be[unix.foo.local]]] [be_ptask_online_cb] (0x0400): Back end is > online > [sssd[be[unix.foo.local]]] [be_ptask_enable] (0x0080): Task > [Subdomains Refresh]: already enabled > Keytab successfully retrieved and stored in: > /var/lib/sss/keytabs/foo.local.keytab6AXxWV > [sssd[be[unix.foo.local]]] [child_sig_handler] (0x1000): Waiting for > child [6242]. > [sssd[be[unix.foo.local]]] [child_sig_handler] (0x0100): child [6242] > finished successfully. > [sssd[be[unix.foo.local]]] [ipa_getkeytab_recv] (0x2000): > ipa-getkeytab status 0 > [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): > Keytab successfully retrieved to > /var/lib/sss/keytabs/foo.local.keytab6AXxWV > [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x2000): > Keytab renamed to /var/lib/sss/keytabs/foo.local.keytab > [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): > Keytab /var/lib/sss/keytabs/foo.local.keytab6AXxWV contains the > expected principals > [sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): > Established trust context for foo.local > [sssd[be[unix.foo.local]]] [unique_filename_destructor] (0x2000): > Unlinking [/var/lib/sss/keytabs/foo.local.keytab6AXxWV] > [sssd[be[unix.foo.local]]] [unlink_dbg] (0x2000): File already > removed: [/var/lib/sss/keytabs/foo.local.keytab6AXxWV] > [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_retried] (0x0400): > Sudomain re-set, will retry lookup > [sssd[be[unix.foo.local]]] [be_fo_reset_svc] (0x1000): Resetting all > servers in service foo.local > [sssd[be[unix.foo.local]]] [be_fo_reset_svc] (0x0080): Cannot retrieve > service [foo.local] > [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_step] (0x0400): > Looking up AD account > [sssd[be[unix.foo.local]]] [be_mark_dom_offline] (0x1000): Marking > subdomain foo.local offline > [sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_done] (0x0040): > ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. > [sssd[be[unix.foo.local]]] [ipa_subdomain_account_done] (0x0040): > ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. > [sssd[be[unix.foo.local]]] [dp_reply_std_set] (0x0080): DP Error is OK > on failed request? > [sssd[be[unix.foo.local]]] [dp_req_done] (0x0400): DP Request [Account > #4]: Request handler finished [0]: Success > From rcritten at redhat.com Thu Apr 6 18:39:37 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 6 Apr 2017 14:39:37 -0400 Subject: [Freeipa-users] ipa-getkeytab client equivalent for Unix In-Reply-To: References: Message-ID: <74e431e3-8a13-1e7e-350d-c0f36f25d0e0@redhat.com> Iulian Roman wrote: > Hello, > > Can anybody explain briefly what ipa-getkeytab runs under the hood in > order to use similar logic for unix clients (will help in automating > the registration to IPA server) ? > > Thank You ! Honestly your best bet would be to pull the freeipa source and look at client/ipa-getkeytab.c. In short it fetches keytabs over LDAP using an extended operation. rob From rcritten at redhat.com Thu Apr 6 18:48:05 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 6 Apr 2017 14:48:05 -0400 Subject: [Freeipa-users] user keytab retrieval In-Reply-To: References: Message-ID: Stijn De Weirdt wrote: > hi all, > > (this is IPA 4.4.0-14.el7.centos.4) > > i'm a bit puzzled by the following: i want to retrieve a user keytab > using ipa-getkeytab -r (since the keytab for the same user was already > retrieved on another host). > > when doing so, i get > > Failed to parse result: Insufficient access rights > > however, i can get the keytab without the -r option. > > anyone care to explain what access rights are required (or why this > error occurs)? Being able to retrieve an existing key means being able to read it which isn't granted by default. It depends on how you want to grant this access: to this one user, to all users, to groups, etc. The attribute you want is ipaProtectedOperation;read_keys but use it very carefully because you are granting read access to keys. rob From sbose at redhat.com Thu Apr 6 18:50:49 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Apr 2017 20:50:49 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> Message-ID: <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: > On 2017-04-06 12:16, Sumit Bose wrote: > > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > > [...] > > > AD trust: > > > mydomain.at (forest root) > > > xyz (subdomain -> where myuser resides) > > > > > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's > > > name and might derive from some information in the AD. > > Yes, it is about the userPrincipalName attribute read from AD. Which IPA > > server version do you use? Since RHEL-7.3 IPA supports those principals > > coming from AD. For older versions you should add a workaround which is > > e.g. described at the end of > > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html > > > > HTH > > > > bye, > > Sumit > > I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to > override it? Please check on the server with ipa trust-find if the BCC domain is listed as 'UPN suffixes:'. If not please try ipa trust-fetch-domains and check again. If the domain is listed then a 7.3 IPA client should be able to detect it automatically on older clients you should set 'krb5_use_enterprise_principal = True' manually in sssd.conf. 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 mike at chinewalking.com Thu Apr 6 19:39:16 2017 From: mike at chinewalking.com (mike at chinewalking.com) Date: Thu, 06 Apr 2017 21:39:16 +0200 Subject: [Freeipa-users] Fwd: Marking subdomain offline In-Reply-To: <20170406181842.ft5p7cjnsneiazpu@hendrix> References: <20170406181842.ft5p7cjnsneiazpu@hendrix> Message-ID: On 2017-04-06 20:18, Jakub Hrozek wrote: > On Thu, Apr 06, 2017 at 07:21:01PM +0200, mike at chinewalking.com wrote: >> Hi, >> >> My IPA<->AD trust setup experiences intermittent failures during login >> events. The AD subdomain goes in an inactive/offline state and users >> logging >> in are put into a 'delayed authentication' queue. Usually logging in >> after a >> minute or so succeeds as the subdomain is reset and the user is cached >> for >> following events. At all times getent/id and kinit's are succesfull, >> even >> with a purged sssd cache. >> SRV records are correctly resolved, except for _kerberos-master. >> >> I have not been able to further troubleshoot the intermittent >> failures. >> Traffic captures show no strange behaviour, yet the sssd_domain log is >> clearly showing AD to be unreachable at times. All AD servers are >> W2012 and >> DNS masking _ldap and _kerberos to single nodes, factoring out any >> faulty >> Windows configs, so far has not had any effect (Would it?). >> >> sssd's data_provider_fo.c :> be_fo_reset_svc() calls fo_get_service(), >> which >> returns EOK. I'm not familiar yet with the variables at play, would >> adding >> debug statements here reveal faults that may cause this? > > Could you paste a bit more context? I think what would work is to trim > the logs (truncate --size 0), then reproduce the issue and search for > the first occurence of "NOT_WORKING" message from any of the fo_* > functions. After truncating the logs I noticed a comparable error that was fixed earlier today. I created a number of existing groups (sudo, app, etc) with low GIDs during initial deployment of IPA. One group caused issues and I deleted it earlier on. Now another group triggered exactly the same sequence of errors: [{"CODE_FILE=src/providers/ipa/ipa_id.c", 36}{"CODE_FUNC=ipa_initgr_get_overrides_step"{"The group name=sudo at unix.FOO.local,cn=groups,cn=unix.foo.local,cn=sysdb has no UUID attribute objectSIDString, error!\n" [{"CODE_FILE=src/providers/ipa/ipa_subdomains_id.c", 47}{"CODE_FUNC=ipa_id_get_groups_overrides_done", 42}{"IPA resolve user groups overrides failed [22].\n" [{"CODE_FUNC=be_mark_dom_offline", 29}{"Marking subdomain foo.local offline\n" With all these troublesome groups removed I have not been able to reproduce the issues. I will further test with different users and mapped groups. I guess the main fault was incorrect log handling. Multiple logins caused overlooking the real error and only showed the mentions of offline AD backends and subdomains. I am not sure why these Posix groups had no objectSIDString while others did. Thank you, Mike From stijn.deweirdt at ugent.be Thu Apr 6 20:18:36 2017 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Thu, 6 Apr 2017 22:18:36 +0200 Subject: [Freeipa-users] user keytab retrieval In-Reply-To: References: Message-ID: <433799b5-0790-da84-fd7d-15f8608b7eeb@ugent.be> hi rob, >> i'm a bit puzzled by the following: i want to retrieve a user keytab >> using ipa-getkeytab -r (since the keytab for the same user was already >> retrieved on another host). >> >> when doing so, i get >> >> Failed to parse result: Insufficient access rights >> >> however, i can get the keytab without the -r option. >> >> anyone care to explain what access rights are required (or why this >> error occurs)? > > Being able to retrieve an existing key means being able to read it which > isn't granted by default. ok, but why is a "regular" ipa-getkeytab no problem? > > It depends on how you want to grant this access: to this one user, to > all users, to groups, etc. i only need to get the user keytab on a few machines; i could probably scp it from one host to the other. but i assumed that ipa-getkeytab -r would do the same. > > The attribute you want is ipaProtectedOperation;read_keys but use it > very carefully because you are granting read access to keys. ok, i'll try to read a bit more about it first. stijn From rcritten at redhat.com Thu Apr 6 20:31:41 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 6 Apr 2017 16:31:41 -0400 Subject: [Freeipa-users] user keytab retrieval In-Reply-To: <433799b5-0790-da84-fd7d-15f8608b7eeb@ugent.be> References: <433799b5-0790-da84-fd7d-15f8608b7eeb@ugent.be> Message-ID: <18085583-94c5-f87f-13f1-11b437b0162f@redhat.com> Stijn De Weirdt wrote: > hi rob, > >>> i'm a bit puzzled by the following: i want to retrieve a user keytab >>> using ipa-getkeytab -r (since the keytab for the same user was already >>> retrieved on another host). >>> >>> when doing so, i get >>> >>> Failed to parse result: Insufficient access rights >>> >>> however, i can get the keytab without the -r option. >>> >>> anyone care to explain what access rights are required (or why this >>> error occurs)? >> >> Being able to retrieve an existing key means being able to read it which >> isn't granted by default. > ok, but why is a "regular" ipa-getkeytab no problem? Because writing keys is granted by default. >> >> It depends on how you want to grant this access: to this one user, to >> all users, to groups, etc. > i only need to get the user keytab on a few machines; i could probably > scp it from one host to the other. but i assumed that ipa-getkeytab -r > would do the same. > >> >> The attribute you want is ipaProtectedOperation;read_keys but use it >> very carefully because you are granting read access to keys. > ok, i'll try to read a bit more about it first. You may end up having to hand-write an ACI to handle this. Given you only want to allow it for a few entries you can add the ACI directly under the entries you want to allow reading to limit exposure. rob From ronaldw at ronzo.at Thu Apr 6 21:26:51 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 06 Apr 2017 23:26:51 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <20170406232651.Horde.llNqozpM52v88rGCCkcq-F3@webmail.your-server.de> Zitat von Sumit Bose : > On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: >> On 2017-04-06 12:16, Sumit Bose wrote: >> > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: >> > [...] >> > > AD trust: >> > > mydomain.at (forest root) >> > > xyz (subdomain -> where myuser resides) >> > > >> > > BCC (appearing in krb5_child.log) is not a domain here. It is >> my company's >> > > name and might derive from some information in the AD. >> > Yes, it is about the userPrincipalName attribute read from AD. Which IPA >> > server version do you use? Since RHEL-7.3 IPA supports those principals >> > coming from AD. For older versions you should add a workaround which is >> > e.g. described at the end of >> > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html >> > >> > HTH >> > >> > bye, >> > Sumit >> >> I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to >> override it? > > Please check on the server with > > ipa trust-find > > if the BCC domain is listed as 'UPN suffixes:'. If not please try > > ipa trust-fetch-domains > > and check again. If the domain is listed then a 7.3 IPA client should be > able to detect it automatically on older clients you should set > 'krb5_use_enterprise_principal = True' manually in sssd.conf. Unfortunately, ipa trust-find shows some UPN suffixes but BCC is not in the list. Any other options left? From jhrozek at redhat.com Fri Apr 7 06:34:21 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 7 Apr 2017 08:34:21 +0200 Subject: [Freeipa-users] Fwd: Marking subdomain offline In-Reply-To: <58E68B46.6030909@sonsorol.org> References: <58E68B46.6030909@sonsorol.org> Message-ID: <20170407063421.tlhqv53q5lewj2kr@hendrix> On Thu, Apr 06, 2017 at 02:39:02PM -0400, Chris Dagdigian wrote: > > I see similar things in our environment where IPA is used as "glue" between > AD Forests that have a 1-way trust relationship. We believe that the root > cause has something to do with the 30+ domain controllers the IPA client > tries to make contact with (in seemingly random order) across the AD Forest. When an AD user logs to an IPA client, there are actually two actions -- a user lookup and the authentication. The user lookup is in fact done by the SSSD instance running on one of the IPA masters, the clients just talks to the masters, but the SSSD on the master talks to one AD DCs. Authentication is done directly against one of AD DCs. > Very hard to reproduce but the "subdomain marked offline" problem is one we > see often in the sssd logs. We think that there are some AD servers in our > sprawling environment that we either can't reach properly over the network > (firewalls, etc.) or are just plain not configured to talk properly to us. > Login success depends on hitting a happy domain controller. > > We are VERY interested in the recent updates to IPA server that seem to > indicate we can 'pin" clients to certain specific AD controllers and from my > understanding we just need to wait until the SSSD software gets broad > support for this feature as well. Once we can do that we plan to pin our > clients to named controllers and see if that helps with any of the > intermittent login problems. I don't think there are any changes needed to the the IPA server (maybe some management framework), but in general you're looking for this feature: https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html (after we migrated the upstream projects from fedorahosted to pagure, our documentation is still in a bit of a flux, but we're migrating the docs gradually..) As the design page says, you will be able to set up the AD DCs the IPA masters talk to using the subdomain configuration, but the DCs the clients authenticate to must currently be set in krb5.conf on the clients until https://pagure.io/SSSD/sssd/issue/3336 is implemented. > > One workaround we've started to use for power users is collecting public SSH > keys and hosting them in the IPA server -- as long as IPA knows that the > user "exists" in AD and has a roughly complete group membership list than > logging in with SSH key instead of AD password bypasses the transient > password checking failures and is very quick. Another workaround (for the IPA masters at least) would be to put the reachable AD DCs into a site and assign the IPA masters to this site. From ronaldw at ronzo.at Fri Apr 7 07:46:45 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Fri, 7 Apr 2017 09:46:45 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <2462f604-e77f-f30c-3e4a-389a82531835@ronzo.at> On 2017-04-06 20:50, Sumit Bose wrote: > On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: >> On 2017-04-06 12:16, Sumit Bose wrote: >>> On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: >>> [...] >>>> AD trust: >>>> mydomain.at (forest root) >>>> xyz (subdomain -> where myuser resides) >>>> >>>> BCC (appearing in krb5_child.log) is not a domain here. It is my company's >>>> name and might derive from some information in the AD. >>> Yes, it is about the userPrincipalName attribute read from AD. Which IPA >>> server version do you use? Since RHEL-7.3 IPA supports those principals >>> coming from AD. For older versions you should add a workaround which is >>> e.g. described at the end of >>> https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html >>> >>> HTH >>> >>> bye, >>> Sumit >> >> I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to >> override it? > > Please check on the server with > > ipa trust-find > > if the BCC domain is listed as 'UPN suffixes:'. If not please try > > ipa trust-fetch-domains > > and check again. If the domain is listed then a 7.3 IPA client should be > able to detect it automatically on older clients you should set > 'krb5_use_enterprise_principal = True' manually in sssd.conf. I just checked with our AD guys. ipa trust-find only shows five UPN suffixes. There are many more which are not shown inlcuding bcc.mydomain.at Any idea why only a subset is shown? From sbose at redhat.com Fri Apr 7 08:28:16 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 7 Apr 2017 10:28:16 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <2462f604-e77f-f30c-3e4a-389a82531835@ronzo.at> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <2462f604-e77f-f30c-3e4a-389a82531835@ronzo.at> Message-ID: <20170407082816.GR3438@p.Speedport_W_724V_Typ_A_05011603_00_011> On Fri, Apr 07, 2017 at 09:46:45AM +0200, Ronald Wimmer wrote: > On 2017-04-06 20:50, Sumit Bose wrote: > > On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: > > > On 2017-04-06 12:16, Sumit Bose wrote: > > > > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > > > > [...] > > > > > AD trust: > > > > > mydomain.at (forest root) > > > > > xyz (subdomain -> where myuser resides) > > > > > > > > > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's > > > > > name and might derive from some information in the AD. > > > > Yes, it is about the userPrincipalName attribute read from AD. Which IPA > > > > server version do you use? Since RHEL-7.3 IPA supports those principals > > > > coming from AD. For older versions you should add a workaround which is > > > > e.g. described at the end of > > > > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html > > > > > > > > HTH > > > > > > > > bye, > > > > Sumit > > > > > > I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to > > > override it? > > > > Please check on the server with > > > > ipa trust-find > > > > if the BCC domain is listed as 'UPN suffixes:'. If not please try > > > > ipa trust-fetch-domains > > > > and check again. If the domain is listed then a 7.3 IPA client should be > > able to detect it automatically on older clients you should set > > 'krb5_use_enterprise_principal = True' manually in sssd.conf. > > I just checked with our AD guys. ipa trust-find only shows five UPN > suffixes. There are many more which are not shown inlcuding bcc.mydomain.at > > Any idea why only a subset is shown? I'm not aware of any limitation here. Have you tried to run 'ipa trust-fetch-domains ad.forest.root' to update the list? If this does not help please add 'log level = 100' to /usr/share/ipa/smb.conf.empty so that it looks like: [global] log level = 100 and run trust-fetch-domains again. The debug output can then be found in /var/log/httpd/error_log. The logs might contain data which should not be shared publicly, so feel free to send them to me directly. 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 sbose at redhat.com Fri Apr 7 08:35:12 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 7 Apr 2017 10:35:12 +0200 Subject: [Freeipa-users] RHEL 6.9 AD Smart Card login In-Reply-To: <4a0752.33ae.15b448deccb.Webtop.0@cox.net> References: <4a0752.33ae.15b448deccb.Webtop.0@cox.net> Message-ID: <20170407083512.GS3438@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Apr 06, 2017 at 06:36:43PM +0000, spammewoods at cox.net wrote: > I have created a two way trust between my IDM server and Active Directory. > I have been able to successful get RHEL 7.3 IDM server and RHEL 7.3 IDM > clients to allow Active Directory login using CAC smart cards into Gnome. > I'm using SSSD for the smart card login process instead of authconfig and > pkcs11. I'm currently trying to get the same thing working for RHEL 6.9, > but I have not been able to get it to work. The latest version of SSSD on > RHEL 6.9 is 1.13.3 and from my understanding I need to have at least 1.14.0 > for SSSD to handle AD smart card logins. So, I have tried to configure The Smartcard authentication feature was backported to RHEL-6.9. Please note that the GDM Smartcard feature must be configured differently in RHEL6 then in RHEL7, details for RHEL-6.9 can e.g. found in https://bugzilla.redhat.com/show_bug.cgi?id=1300421#c13 HTH bye, Sumit > pam_pkcs11.conf file to use the pwent mapper to link the Common Name (CN) to > the Active Directory User account. I have created an User ID Override for > the AD user and added CN name from the Certificate on the smart card into > the GECOS field. I also have added all three certificates from the CAC > smart card into the User ID Override. > > When I try and log in, I get this error message in /var/log/secure: > Apr 6 13:21:57 site-lws05 pam: gdm-smartcard: > pam_pkcs11(gdm-smartcard:auth): pam_get_pwd() failed: Conversation error > Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: > pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #1 > Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: > pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #2 > Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: > pam_pkcs11(gdm-smartcard:auth): no valid certificate which meets all > requirements found > > Here is the some details: > IDM Domain: idm.domain.local > Windows Domain: domain.local > RHEL 7.3 IDM Server: site-idm01.idm.domain.local > RHEL 6.9 IDM Client : site-lws05.idm.domain.local > > When I run the getent command on local accounts and IDM accounts I get user > details, but when I run the command on AD accounts it doesn't find them. > So, I'm wondering if that's why its not finding the CN name in the GECOS > field. I'm trying to avoid using the cn_map on the clients, because we > have a large amount of users and thats alot of extra work to manage that > file. That's why I wanted to use the pwent mapper. > Here is my SSSD config file from the RHEL 6.9 client: > [domain/idm.domain.local] > override_shell = /bin/bash > debug_level = 9 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = idm.domain.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = site-lws05.idm.domain.local > chpass_provider = ipa > ipa_server = _srv_, site-idm01.idm.domain.local > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > debug_level = 9 > services = nss, sudo, pam, ssh, ifp > domains = idm.domain.local > certificate_verification = no_ocsp > ldap_user_certificate = userCertificate;binary > [nss] > debug_level = 9 > homedir_substring = /home > [pam] > debug_level = 9 > pam_cert_auth = True > [sudo] > debug_level = 9 > [autofs] > debug_level = 9 > [ssh] > debug_level = 9 > [pac] > debug_level = 9 > [ifp] > debug_level = 9 > > Here is my nssswitch file from the RHEL 6.9 client: > # /etc/nsswitch.conf > # > # An example Name Service Switch config file. This file should be > # sorted with the most-used services at the beginning. > # > # The entry '[NOTFOUND=return]' means that the search for an > # entry should stop if the search in the previous entry turned > # up nothing. Note that if the search failed due to some other reason > # (like no NIS server responding) then the search continues with the > # next entry. > # > # Valid entries include: > # > # nisplus Use NIS+ (NIS version 3) > # nis Use NIS (NIS version 2), also called YP > # dns Use DNS (Domain Name Service) > # files Use the local files > # db Use the local database (.db) files > # compat Use NIS on compat mode > # hesiod Use Hesiod for user lookups > # [NOTFOUND=return] Stop searching if not found so far > # > # To use db, put the "db" in front of "files" for entries you want to be > # looked up first in the databases > # > # Example: > #passwd: db files nisplus nis > #shadow: db files nisplus nis > #group: db files nisplus nis > passwd: files sss > shadow: files sss > group: files sss > #hosts: db files nisplus nis dns > hosts: files dns > # Example - obey only what nisplus tells us... > #services: nisplus [NOTFOUND=return] files > #networks: nisplus [NOTFOUND=return] files > #protocols: nisplus [NOTFOUND=return] files > #rpc: nisplus [NOTFOUND=return] files > #ethers: nisplus [NOTFOUND=return] files > #netmasks: nisplus [NOTFOUND=return] files > bootparams: nisplus [NOTFOUND=return] files > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > netgroup: files sss > publickey: nisplus > automount: files sss > aliases: files nisplus > sudoers: files sss > > Here is my system-auth from the RHEL 6.9 client: > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth [success=1 default=ignore] pam_succeed_if.so service notin > login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid > auth [success=done authinfo_unavail=ignore ignore=ignore default=die] > pam_pkcs11.so card_only > auth sufficient pam_fprintd.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > password requisite pam_cracklib.so try_first_pass retry=3 type= > password sufficient pam_unix.so sha512 shadow nullok try_first_pass > use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_oddjob_mkhomedir.so umask=0077 > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > Here is my password-auth from the RHEL 6.9 client: > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > password requisite pam_cracklib.so try_first_pass retry=3 type= > password sufficient pam_unix.so sha512 shadow nullok try_first_pass > use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_oddjob_mkhomedir.so umask=0077 > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > Here is my smartcard-auth from the RHEL 6.9 client: > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth [success=done ignore=ignore default=die] pam_pkcs11.so > wait_for_card card_only > auth required pam_deny.so > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > password required pam_pkcs11.so > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_oddjob_mkhomedir.so umask=0077 > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_sss.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 simo at redhat.com Fri Apr 7 11:45:28 2017 From: simo at redhat.com (Simo Sorce) Date: Fri, 07 Apr 2017 07:45:28 -0400 Subject: [Freeipa-users] user keytab retrieval In-Reply-To: <433799b5-0790-da84-fd7d-15f8608b7eeb@ugent.be> References: <433799b5-0790-da84-fd7d-15f8608b7eeb@ugent.be> Message-ID: <1491565528.23726.4.camel@redhat.com> On Thu, 2017-04-06 at 22:18 +0200, Stijn De Weirdt wrote: > hi rob, > > > > i'm a bit puzzled by the following: i want to retrieve a user > > > keytab > > > using ipa-getkeytab -r (since the keytab for the same user was > > > already > > > retrieved on another host). > > > > > > when doing so, i get > > > > > > Failed to parse result: Insufficient access rights > > > > > > however, i can get the keytab without the -r option. > > > > > > anyone care to explain what access rights are required (or why > > > this > > > error occurs)? > > > > Being able to retrieve an existing key means being able to read it > > which > > isn't granted by default. > > ok, but why is a "regular" ipa-getkeytab no problem? A regular keytab fetch operation invalidates previously obtained keys, so when that happens, if the owner has not done it, it figures out pretty quickly. Reading out keys leaves no traces, so that operation is restricted, otherwise a rogue admin could exfiltrate all keys from a realm, undetected. You should create a host-group for each "cluster" of servers that need to present the same identity, then allow this group read to the specific key you want them to access. Ideally using the host's key to fetch the shared service key. Simo. From yamakasi.014 at gmail.com Fri Apr 7 21:06:24 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 7 Apr 2017 23:06:24 +0200 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server Message-ID: When I have a full ipa setup and I want to add a host to it that is installed or needs to be installed as IPA LDAP server only, is that possible ? Of course the ipa-server-install complains that the agent is already configured on the host but there might be a way ? Or just copy the config back faster the IPA LDAP only server is installed ? Thanks, Matt From rcritten at redhat.com Fri Apr 7 21:11:38 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 7 Apr 2017 17:11:38 -0400 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server In-Reply-To: References: Message-ID: Matt . wrote: > When I have a full ipa setup and I want to add a host to it that is > installed or needs to be installed as IPA LDAP server only, is that > possible ? If you're asking if only 389-ds can be configured on an IPA server, no, not using any IPA tools in any case. > Of course the ipa-server-install complains that the agent is already > configured on the host but there might be a way ? Or just copy the > config back faster the IPA LDAP only server is installed ? I don't understand. Seeing the error message and commands might help. rob From yamakasi.014 at gmail.com Fri Apr 7 21:18:03 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 7 Apr 2017 23:18:03 +0200 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server In-Reply-To: References: Message-ID: Nope, I provision my servers and they are added to my FreeIPA environment which auths my systeadmins. But on a server I provisioned I need to install FreeIPA as well, but without dns and ca, so it's doing ldap only actually. When I want to install FreeIPA server on this IPA client it tells me (which is logical): ipa.ipapython.install.cli.install_tool(Server): ERROR IPA client is already configured on this system. Please uninstall it before configuring the IPA server, using 'ipa-client-install --uninstall' So what I want to do is install FreeIPA server on it but using local system accounts to be auth against the former IPA server the client was assigned to. So: IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed with FreeIPA (no dns and CA) as well but I want to have local sysaccounts that login to cli and such auth against IPA01 after it's installed with FreeIPA and the clientconfig for sssd is not there anymore because of the 'ipa-client-install --uninstall' 2017-04-07 23:11 GMT+02:00 Rob Crittenden : > Matt . wrote: >> When I have a full ipa setup and I want to add a host to it that is >> installed or needs to be installed as IPA LDAP server only, is that >> possible ? > > If you're asking if only 389-ds can be configured on an IPA server, no, > not using any IPA tools in any case. > >> Of course the ipa-server-install complains that the agent is already >> configured on the host but there might be a way ? Or just copy the >> config back faster the IPA LDAP only server is installed ? > > I don't understand. Seeing the error message and commands might help. > > rob > From rcritten at redhat.com Fri Apr 7 21:24:54 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 7 Apr 2017 17:24:54 -0400 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server In-Reply-To: References: Message-ID: <50f041f1-ee19-8783-a761-bc4376a4a6b2@redhat.com> Matt . wrote: > Nope, I provision my servers and they are added to my FreeIPA > environment which auths my systeadmins. But on a server I provisioned > I need to install FreeIPA as well, but without dns and ca, so it's > doing ldap only actually. > > When I want to install FreeIPA server on this IPA client it tells me > (which is logical): > > ipa.ipapython.install.cli.install_tool(Server): ERROR IPA client is > already configured on this system. > Please uninstall it before configuring the IPA server, using > 'ipa-client-install --uninstall' > > So what I want to do is install FreeIPA server on it but using local > system accounts to be auth against the former IPA server the client > was assigned to. > > So: > > IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed > with FreeIPA (no dns and CA) as well but I want to have local > sysaccounts that login to cli and such auth against IPA01 after it's > installed with FreeIPA and the clientconfig for sssd is not there > anymore because of the 'ipa-client-install --uninstall' Still very confusing. LDAP has nothing to do with this. IPA is always at least LDAP + Kerberos + Apache + a few other minor services. So it's better to just say no DNS and no CA, though that isn't really relevant since those are always optional. It sounds like what you want to do is, on the same box, install IPA server and configure the local machine to point to a DIFFERENT IPA server for user/group lookups? You might be able to do it via sssd but it would be an unsupportable nightmare. rob > > 2017-04-07 23:11 GMT+02:00 Rob Crittenden : >> Matt . wrote: >>> When I have a full ipa setup and I want to add a host to it that is >>> installed or needs to be installed as IPA LDAP server only, is that >>> possible ? >> >> If you're asking if only 389-ds can be configured on an IPA server, no, >> not using any IPA tools in any case. >> >>> Of course the ipa-server-install complains that the agent is already >>> configured on the host but there might be a way ? Or just copy the >>> config back faster the IPA LDAP only server is installed ? >> >> I don't understand. Seeing the error message and commands might help. >> >> rob >> From yamakasi.014 at gmail.com Fri Apr 7 21:32:08 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 7 Apr 2017 23:32:08 +0200 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server In-Reply-To: <50f041f1-ee19-8783-a761-bc4376a4a6b2@redhat.com> References: <50f041f1-ee19-8783-a761-bc4376a4a6b2@redhat.com> Message-ID: You are almost right, the box only needs to lookup users/groups from another IPA server for environment admins. The "LDAP Only" on this IPA server (and client) won't do anything on the whole network layer, only some webapp is talking to it and use users don't have anything todo with the network at all but I think it's nice when I don't have to maintain my local users there to login to the box for maintenance so I thought it would be nice when SSSD checked my default IPA-environment server for that. 2017-04-07 23:24 GMT+02:00 Rob Crittenden : > Matt . wrote: >> Nope, I provision my servers and they are added to my FreeIPA >> environment which auths my systeadmins. But on a server I provisioned >> I need to install FreeIPA as well, but without dns and ca, so it's >> doing ldap only actually. >> >> When I want to install FreeIPA server on this IPA client it tells me >> (which is logical): >> >> ipa.ipapython.install.cli.install_tool(Server): ERROR IPA client is >> already configured on this system. >> Please uninstall it before configuring the IPA server, using >> 'ipa-client-install --uninstall' >> >> So what I want to do is install FreeIPA server on it but using local >> system accounts to be auth against the former IPA server the client >> was assigned to. >> >> So: >> >> IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed >> with FreeIPA (no dns and CA) as well but I want to have local >> sysaccounts that login to cli and such auth against IPA01 after it's >> installed with FreeIPA and the clientconfig for sssd is not there >> anymore because of the 'ipa-client-install --uninstall' > > Still very confusing. LDAP has nothing to do with this. IPA is always at > least LDAP + Kerberos + Apache + a few other minor services. So it's > better to just say no DNS and no CA, though that isn't really relevant > since those are always optional. > > It sounds like what you want to do is, on the same box, install IPA > server and configure the local machine to point to a DIFFERENT IPA > server for user/group lookups? > > You might be able to do it via sssd but it would be an unsupportable > nightmare. > > rob > >> >> 2017-04-07 23:11 GMT+02:00 Rob Crittenden : >>> Matt . wrote: >>>> When I have a full ipa setup and I want to add a host to it that is >>>> installed or needs to be installed as IPA LDAP server only, is that >>>> possible ? >>> >>> If you're asking if only 389-ds can be configured on an IPA server, no, >>> not using any IPA tools in any case. >>> >>>> Of course the ipa-server-install complains that the agent is already >>>> configured on the host but there might be a way ? Or just copy the >>>> config back faster the IPA LDAP only server is installed ? >>> >>> I don't understand. Seeing the error message and commands might help. >>> >>> rob >>> > From lslebodn at redhat.com Sat Apr 8 10:49:30 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 8 Apr 2017 12:49:30 +0200 Subject: [Freeipa-users] SSSD hangs on IPA master In-Reply-To: References: <20170404091904.gwlofxwejlcc4mqz@hendrix> Message-ID: <20170408104929.GA23731@10.4.128.1> On (06/04/17 11:06), Ronald Wimmer wrote: >On 2017-04-04 11:19, Jakub Hrozek wrote: >> On Tue, Apr 04, 2017 at 09:51:04AM +0200, Ronald Wimmer wrote: >> > Hi, >> > >> > my IPA master has an AD trust (several thousand users). Since the trust has >> > been set up I am experiencing that I cannot login on the web interface. Even >> > connecting via SSH does not work or takes extremely long. When I managed to >> > log in as root via SSH (after waiting and trying several times or rebooting >> > the machine) I could not restart SSSD (systemctl restart sssd). I had to >> > kill the SSSD processes manually and then everything seemed to work fine >> > again. >> > >> > What could be going on? Could the SSSD cache be to big (122M)? Where should >> > I take a deeper look? >> > >> > Any hints are highly appreciated! >> SSSD logs that capture the problem are always a good start. >> >I found out that the CPU was quite busy (sssd_be process) and that there was >a lot I/O in the cache directory. So I upgraded from 1 to 4 virtual CPUs and >followed your recommendations regarding large deployments: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ > >No problems so far... > May I ask which version of sssd do you use? LS From lslebodn at redhat.com Sat Apr 8 10:53:39 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 8 Apr 2017 12:53:39 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> Message-ID: <20170408105339.GB23731@10.4.128.1> On (04/04/17 09:41), Ronald Wimmer wrote: >On 2017-03-31 13:35, Lukas Slebodnik wrote: >> On (29/03/17 10:47), Ronald Wimmer wrote: >> > Hi, >> > >> > yesterday I suddenly was unable to use the webinterface of my ipa master. SSH >> > login (with root user) did not work also. >> > >> > When I uncommented the setting "memcache_timeout = 600" in the sssd config >> > file of the master everything seemed to work fine again. (my ipa setup has a >> > trust to AD) >> > >> I doubt it had anything to do memcache_timeout. >> I would say that restart of sssd helped. But it difficult to say >> without log files. either sssd logs or at least /var/log/secure >> (journald for pam). >You were right. I uncommented the setting and the problem ocurred again. > Did you find anything suspicious in journald? Is sssd_be busy (or any other process)? high CPU, IO operations ... It would be good to know more details. Restarting sssd is not a solution. LS From yamakasi.014 at gmail.com Sat Apr 8 11:37:17 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 8 Apr 2017 13:37:17 +0200 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server In-Reply-To: <50f041f1-ee19-8783-a761-bc4376a4a6b2@redhat.com> References: <50f041f1-ee19-8783-a761-bc4376a4a6b2@redhat.com> Message-ID: The issue you get here is that the IPA client is not enrolled anymore when you did an uninstall of the client before the IPA install on that "previous" client which needs to be client again after the IPA install on it. This sounds messy but could be ideal for some situations of useraccess on systems. 2017-04-07 23:24 GMT+02:00 Rob Crittenden : > Matt . wrote: >> Nope, I provision my servers and they are added to my FreeIPA >> environment which auths my systeadmins. But on a server I provisioned >> I need to install FreeIPA as well, but without dns and ca, so it's >> doing ldap only actually. >> >> When I want to install FreeIPA server on this IPA client it tells me >> (which is logical): >> >> ipa.ipapython.install.cli.install_tool(Server): ERROR IPA client is >> already configured on this system. >> Please uninstall it before configuring the IPA server, using >> 'ipa-client-install --uninstall' >> >> So what I want to do is install FreeIPA server on it but using local >> system accounts to be auth against the former IPA server the client >> was assigned to. >> >> So: >> >> IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed >> with FreeIPA (no dns and CA) as well but I want to have local >> sysaccounts that login to cli and such auth against IPA01 after it's >> installed with FreeIPA and the clientconfig for sssd is not there >> anymore because of the 'ipa-client-install --uninstall' > > Still very confusing. LDAP has nothing to do with this. IPA is always at > least LDAP + Kerberos + Apache + a few other minor services. So it's > better to just say no DNS and no CA, though that isn't really relevant > since those are always optional. > > It sounds like what you want to do is, on the same box, install IPA > server and configure the local machine to point to a DIFFERENT IPA > server for user/group lookups? > > You might be able to do it via sssd but it would be an unsupportable > nightmare. > > rob > >> >> 2017-04-07 23:11 GMT+02:00 Rob Crittenden : >>> Matt . wrote: >>>> When I have a full ipa setup and I want to add a host to it that is >>>> installed or needs to be installed as IPA LDAP server only, is that >>>> possible ? >>> >>> If you're asking if only 389-ds can be configured on an IPA server, no, >>> not using any IPA tools in any case. >>> >>>> Of course the ipa-server-install complains that the agent is already >>>> configured on the host but there might be a way ? Or just copy the >>>> config back faster the IPA LDAP only server is installed ? >>> >>> I don't understand. Seeing the error message and commands might help. >>> >>> rob >>> > From ronaldw at ronzo.at Sat Apr 8 15:39:42 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Sat, 8 Apr 2017 17:39:42 +0200 Subject: [Freeipa-users] SSSD hangs on IPA master In-Reply-To: <20170408104929.GA23731@10.4.128.1> References: <20170404091904.gwlofxwejlcc4mqz@hendrix> <20170408104929.GA23731@10.4.128.1> Message-ID: <08a1c648-eda7-193b-e89e-57bdc1eaf579@ronzo.at> On 2017-04-08 12:49, Lukas Slebodnik wrote: > [...] > May I ask which version of sssd do you use? SSSD 1.14 From ronaldw at ronzo.at Sat Apr 8 15:55:00 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Sat, 8 Apr 2017 17:55:00 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: <20170408105339.GB23731@10.4.128.1> References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> <20170408105339.GB23731@10.4.128.1> Message-ID: On 2017-04-08 12:53, Lukas Slebodnik wrote: > On (04/04/17 09:41), Ronald Wimmer wrote: >> On 2017-03-31 13:35, Lukas Slebodnik wrote: >>> On (29/03/17 10:47), Ronald Wimmer wrote: >>>> Hi, >>>> >>>> yesterday I suddenly was unable to use the webinterface of my ipa master. SSH >>>> login (with root user) did not work also. >>>> >>>> When I uncommented the setting "memcache_timeout = 600" in the sssd config >>>> file of the master everything seemed to work fine again. (my ipa setup has a >>>> trust to AD) >>>> >>> I doubt it had anything to do memcache_timeout. >>> I would say that restart of sssd helped. But it difficult to say >>> without log files. either sssd logs or at least /var/log/secure >>> (journald for pam). >> You were right. I uncommented the setting and the problem ocurred again. >> > Did you find anything suspicious in journald? > Is sssd_be busy (or any other process)? > high CPU, IO operations ... > > It would be good to know more details. Restarting sssd is not a solution. sssd_be consumed a lot of CPU and produced a lot of I/O in the sssd cache directory. After following https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ the problems did nod reappear. Regards, Ronald From yamakasi.014 at gmail.com Sat Apr 8 21:51:23 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 8 Apr 2017 23:51:23 +0200 Subject: [Freeipa-users] Auto create kerberos/ldap SRV records on subdomain In-Reply-To: References: <20170404184822.fnkaxjqldgizku2h@redhat.com> Message-ID: I have tested this but the hosts don't get an enrolled status. I have tried _kerberos TXT "MYREAL.DOMAIN.TLD" and without the quotes. I can't see any logging about it. Any idea ? Thanks! Matt 2017-04-04 20:50 GMT+02:00 Matt . : > Hi Alexander, > > Superb, thanks a lot for this quick fix! > > Matt > > 2017-04-04 20:48 GMT+02:00 Alexander Bokovoy : >> On ti, 04 huhti 2017, Matt . wrote: >>> >>> Hi guys, >>> >>> Is it possible to create in a simple way the SRV domains for kerberos >>> on subdomains ? it's a pain to add them all manually when you have a >>> lot of subdomains. >>> >>> I hope someone has a solution. >> >> Create TXT record _kerberos.sub.domain.tld that contains name of your >> Kerberos realm in upper case. For MIT Kerberos clients this is enough to >> discover their proper Kerberos realm and DNS domain for SRV record >> discovery. >> >> -- >> / Alexander Bokovoy From yamakasi.014 at gmail.com Sat Apr 8 22:36:29 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Sun, 9 Apr 2017 00:36:29 +0200 Subject: [Freeipa-users] Auto create kerberos/ldap SRV records on subdomain In-Reply-To: References: <20170404184822.fnkaxjqldgizku2h@redhat.com> Message-ID: As far as I can find out I need a _ldap._tcp SRV 0 100 389 ipa-01.mydomain.tld. in my subdomain, is there no more "general" way to catch them all ? 2017-04-08 23:51 GMT+02:00 Matt . : > I have tested this but the hosts don't get an enrolled status. I have > tried _kerberos TXT "MYREAL.DOMAIN.TLD" and without the quotes. I > can't see any logging about it. Any idea ? > > Thanks! > > Matt > > 2017-04-04 20:50 GMT+02:00 Matt . : >> Hi Alexander, >> >> Superb, thanks a lot for this quick fix! >> >> Matt >> >> 2017-04-04 20:48 GMT+02:00 Alexander Bokovoy : >>> On ti, 04 huhti 2017, Matt . wrote: >>>> >>>> Hi guys, >>>> >>>> Is it possible to create in a simple way the SRV domains for kerberos >>>> on subdomains ? it's a pain to add them all manually when you have a >>>> lot of subdomains. >>>> >>>> I hope someone has a solution. >>> >>> Create TXT record _kerberos.sub.domain.tld that contains name of your >>> Kerberos realm in upper case. For MIT Kerberos clients this is enough to >>> discover their proper Kerberos realm and DNS domain for SRV record >>> discovery. >>> >>> -- >>> / Alexander Bokovoy From yamakasi.014 at gmail.com Sat Apr 8 23:53:25 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Sun, 9 Apr 2017 01:53:25 +0200 Subject: [Freeipa-users] Auto create kerberos/ldap SRV records on subdomain In-Reply-To: References: <20170404184822.fnkaxjqldgizku2h@redhat.com> Message-ID: OK, cname does it's thing :) 2017-04-09 0:36 GMT+02:00 Matt . : > As far as I can find out I need a _ldap._tcp SRV 0 100 389 > ipa-01.mydomain.tld. in my subdomain, is there no more "general" way > to catch them all ? > > 2017-04-08 23:51 GMT+02:00 Matt . : >> I have tested this but the hosts don't get an enrolled status. I have >> tried _kerberos TXT "MYREAL.DOMAIN.TLD" and without the quotes. I >> can't see any logging about it. Any idea ? >> >> Thanks! >> >> Matt >> >> 2017-04-04 20:50 GMT+02:00 Matt . : >>> Hi Alexander, >>> >>> Superb, thanks a lot for this quick fix! >>> >>> Matt >>> >>> 2017-04-04 20:48 GMT+02:00 Alexander Bokovoy : >>>> On ti, 04 huhti 2017, Matt . wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> Is it possible to create in a simple way the SRV domains for kerberos >>>>> on subdomains ? it's a pain to add them all manually when you have a >>>>> lot of subdomains. >>>>> >>>>> I hope someone has a solution. >>>> >>>> Create TXT record _kerberos.sub.domain.tld that contains name of your >>>> Kerberos realm in upper case. For MIT Kerberos clients this is enough to >>>> discover their proper Kerberos realm and DNS domain for SRV record >>>> discovery. >>>> >>>> -- >>>> / Alexander Bokovoy From rcritten at redhat.com Sun Apr 9 02:09:57 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 8 Apr 2017 22:09:57 -0400 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server In-Reply-To: References: <50f041f1-ee19-8783-a761-bc4376a4a6b2@redhat.com> Message-ID: <6dea7cd0-8efe-0d31-b57b-34687cd12599@redhat.com> Matt . wrote: > The issue you get here is that the IPA client is not enrolled anymore > when you did an uninstall of the client before the IPA install on that > "previous" client which needs to be client again after the IPA install > on it. > > This sounds messy but could be ideal for some situations of useraccess > on systems. Installing an IPA master configures it as a client for that master, there is no way around it. You can't (or shouldn't) mix and match discrete IPA installations. Eventually there will be intra-IPA trust which will do you what I think you are looking for. rob > > 2017-04-07 23:24 GMT+02:00 Rob Crittenden : >> Matt . wrote: >>> Nope, I provision my servers and they are added to my FreeIPA >>> environment which auths my systeadmins. But on a server I provisioned >>> I need to install FreeIPA as well, but without dns and ca, so it's >>> doing ldap only actually. >>> >>> When I want to install FreeIPA server on this IPA client it tells me >>> (which is logical): >>> >>> ipa.ipapython.install.cli.install_tool(Server): ERROR IPA client is >>> already configured on this system. >>> Please uninstall it before configuring the IPA server, using >>> 'ipa-client-install --uninstall' >>> >>> So what I want to do is install FreeIPA server on it but using local >>> system accounts to be auth against the former IPA server the client >>> was assigned to. >>> >>> So: >>> >>> IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed >>> with FreeIPA (no dns and CA) as well but I want to have local >>> sysaccounts that login to cli and such auth against IPA01 after it's >>> installed with FreeIPA and the clientconfig for sssd is not there >>> anymore because of the 'ipa-client-install --uninstall' >> >> Still very confusing. LDAP has nothing to do with this. IPA is always at >> least LDAP + Kerberos + Apache + a few other minor services. So it's >> better to just say no DNS and no CA, though that isn't really relevant >> since those are always optional. >> >> It sounds like what you want to do is, on the same box, install IPA >> server and configure the local machine to point to a DIFFERENT IPA >> server for user/group lookups? >> >> You might be able to do it via sssd but it would be an unsupportable >> nightmare. >> >> rob >> >>> >>> 2017-04-07 23:11 GMT+02:00 Rob Crittenden : >>>> Matt . wrote: >>>>> When I have a full ipa setup and I want to add a host to it that is >>>>> installed or needs to be installed as IPA LDAP server only, is that >>>>> possible ? >>>> >>>> If you're asking if only 389-ds can be configured on an IPA server, no, >>>> not using any IPA tools in any case. >>>> >>>>> Of course the ipa-server-install complains that the agent is already >>>>> configured on the host but there might be a way ? Or just copy the >>>>> config back faster the IPA LDAP only server is installed ? >>>> >>>> I don't understand. Seeing the error message and commands might help. >>>> >>>> rob >>>> >> From yamakasi.014 at gmail.com Sun Apr 9 10:42:46 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Sun, 9 Apr 2017 12:42:46 +0200 Subject: [Freeipa-users] IPA Ldap only as Client on different IPA server In-Reply-To: <6dea7cd0-8efe-0d31-b57b-34687cd12599@redhat.com> References: <50f041f1-ee19-8783-a761-bc4376a4a6b2@redhat.com> <6dea7cd0-8efe-0d31-b57b-34687cd12599@redhat.com> Message-ID: HI Rob, As you say I figured out the same indeed and tested to see what happens, no way around it (also cert stuff and so on). I would have been a workaround for... I'm looking forward to some intra-IPA trust in the future, would be awesome! Thanks! 2017-04-09 4:09 GMT+02:00 Rob Crittenden : > Matt . wrote: >> The issue you get here is that the IPA client is not enrolled anymore >> when you did an uninstall of the client before the IPA install on that >> "previous" client which needs to be client again after the IPA install >> on it. >> >> This sounds messy but could be ideal for some situations of useraccess >> on systems. > > Installing an IPA master configures it as a client for that master, > there is no way around it. > > You can't (or shouldn't) mix and match discrete IPA installations. > Eventually there will be intra-IPA trust which will do you what I think > you are looking for. > > rob > >> >> 2017-04-07 23:24 GMT+02:00 Rob Crittenden : >>> Matt . wrote: >>>> Nope, I provision my servers and they are added to my FreeIPA >>>> environment which auths my systeadmins. But on a server I provisioned >>>> I need to install FreeIPA as well, but without dns and ca, so it's >>>> doing ldap only actually. >>>> >>>> When I want to install FreeIPA server on this IPA client it tells me >>>> (which is logical): >>>> >>>> ipa.ipapython.install.cli.install_tool(Server): ERROR IPA client is >>>> already configured on this system. >>>> Please uninstall it before configuring the IPA server, using >>>> 'ipa-client-install --uninstall' >>>> >>>> So what I want to do is install FreeIPA server on it but using local >>>> system accounts to be auth against the former IPA server the client >>>> was assigned to. >>>> >>>> So: >>>> >>>> IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed >>>> with FreeIPA (no dns and CA) as well but I want to have local >>>> sysaccounts that login to cli and such auth against IPA01 after it's >>>> installed with FreeIPA and the clientconfig for sssd is not there >>>> anymore because of the 'ipa-client-install --uninstall' >>> >>> Still very confusing. LDAP has nothing to do with this. IPA is always at >>> least LDAP + Kerberos + Apache + a few other minor services. So it's >>> better to just say no DNS and no CA, though that isn't really relevant >>> since those are always optional. >>> >>> It sounds like what you want to do is, on the same box, install IPA >>> server and configure the local machine to point to a DIFFERENT IPA >>> server for user/group lookups? >>> >>> You might be able to do it via sssd but it would be an unsupportable >>> nightmare. >>> >>> rob >>> >>>> >>>> 2017-04-07 23:11 GMT+02:00 Rob Crittenden : >>>>> Matt . wrote: >>>>>> When I have a full ipa setup and I want to add a host to it that is >>>>>> installed or needs to be installed as IPA LDAP server only, is that >>>>>> possible ? >>>>> >>>>> If you're asking if only 389-ds can be configured on an IPA server, no, >>>>> not using any IPA tools in any case. >>>>> >>>>>> Of course the ipa-server-install complains that the agent is already >>>>>> configured on the host but there might be a way ? Or just copy the >>>>>> config back faster the IPA LDAP only server is installed ? >>>>> >>>>> I don't understand. Seeing the error message and commands might help. >>>>> >>>>> rob >>>>> >>> > From jhrozek at redhat.com Sun Apr 9 19:11:14 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 9 Apr 2017 21:11:14 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> <20170408105339.GB23731@10.4.128.1> Message-ID: <20170409191114.g7e3t3baz7rgwvpb@hendrix> On Sat, Apr 08, 2017 at 05:55:00PM +0200, Ronald Wimmer wrote: > On 2017-04-08 12:53, Lukas Slebodnik wrote: > > On (04/04/17 09:41), Ronald Wimmer wrote: > > > On 2017-03-31 13:35, Lukas Slebodnik wrote: > > > > On (29/03/17 10:47), Ronald Wimmer wrote: > > > > > Hi, > > > > > > > > > > yesterday I suddenly was unable to use the webinterface of my ipa master. SSH > > > > > login (with root user) did not work also. > > > > > > > > > > When I uncommented the setting "memcache_timeout = 600" in the sssd config > > > > > file of the master everything seemed to work fine again. (my ipa setup has a > > > > > trust to AD) > > > > > > > > > I doubt it had anything to do memcache_timeout. > > > > I would say that restart of sssd helped. But it difficult to say > > > > without log files. either sssd logs or at least /var/log/secure > > > > (journald for pam). > > > You were right. I uncommented the setting and the problem ocurred again. > > > > > Did you find anything suspicious in journald? > > Is sssd_be busy (or any other process)? > > high CPU, IO operations ... > > > > It would be good to know more details. Restarting sssd is not a solution. > > sssd_be consumed a lot of CPU and produced a lot of I/O in the sssd cache > directory. After following https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ > the problems did nod reappear. btw even after the performance improvements we did in 1.14 we an issue where even parsing the entries takes too long. What we did in 1.14 was that if the entries didn't change compared to what is already in the cache, then we skipped saving the full entry again just to bump the timestamp. Making the parsing faster is planned for the next version. (btw there was a bug where on upgrade, this new performance improvement didn't take effect for objects that were already cached. Removing the cache is a simple workaround and it's something we should fix soon in the code..) From rbulling at obscure.org Mon Apr 10 00:16:11 2017 From: rbulling at obscure.org (Richard Bullington-McGuire) Date: Sun, 9 Apr 2017 20:16:11 -0400 (EDT) Subject: [Freeipa-users] An enhanced passwd/group/shadow -> IPA import script Message-ID: Recently I needed to import hundreds of users from the UNIX standard files /etc/passwd and friends to a new IPA server, and I found Robert Crittenden's excellent sketch of a Python program to do the import: https://www.redhat.com/archives/freeipa-users/2010-September/msg00105.html I extended it to and asked for and received for permission to publish the derived work under the MIT license. This new set of scripts supports importing groups, group members, shadow passwords, and has some configuration parameters baked into the scripts themselves. There is also a script to unlock a locked account (such as admin if it gets locked) via LDAP in the distribution. These scripts are now available here: https://github.com/obscureorganization/ipa-tools Further dialog with @rcritten yielded an issue for improving performance, I welcome contributions in the form of email posts or pull requests: https://github.com/obscureorganization/ipa-tools/issues/1 Thanks again go to Robert Crittenden and Red Hat for everything you've done to improve identity management! -- Richard Bullington-McGuire +1 571 236 0938 President of The Obscure Organization - https://www.obscure.org/ PGP key fingerprint: D9B2 B6A6 17A8 8989 918C 3D59 0621 BDC5 DAC3 028E From tymrehm at gmail.com Mon Apr 10 04:04:58 2017 From: tymrehm at gmail.com (Tym Rehm) Date: Mon, 10 Apr 2017 00:04:58 -0400 Subject: [Freeipa-users] SSH access to only specific hosts useding ssh keys Message-ID: Hey all, New user here. I have a user "user1" that I want to allow a couple of different users "userX and userY" to be allowed to ssh into "server1" and "server2", but not both servers using ssh-keys. So as an example. UserX will ssh user1 at server2 with ssh-key, but I don't want userY to be able to successfully run the same command. I currently have userX and userY's public ssh-key attached to user1 and I have created a HBAC rule to allow user1 to connect with ssh on both server1 and server2. This is allowing user1 to connect to both servers fine, without a password. It also is allowing users (X & Y) to ssh user1 at server1 and user1 at server2. How can stop that to restrict userX to be able to ssh as user1 on server1, but not server2? Do I need to do something with the keytabs or add the ssh-keys for userX to the server1 host only? Sorry if this is confusing and thank you for your help on this. -- -- Do not meddle in the affairs of dragons cause you are crunchy and good with ketchup. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Apr 10 06:17:06 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Apr 2017 08:17:06 +0200 Subject: [Freeipa-users] SSH access to only specific hosts useding ssh keys In-Reply-To: References: Message-ID: <20170410061706.5l3jixg5kdyqoolf@hendrix> On Mon, Apr 10, 2017 at 12:04:58AM -0400, Tym Rehm wrote: > Hey all, New user here. > > I have a user "user1" that I want to allow a couple of different users > "userX and userY" to be allowed to ssh into "server1" and "server2", but > not both servers using ssh-keys. > > So as an example. UserX will ssh user1 at server2 with ssh-key, but I don't > want userY to be able to successfully run the same command. > > I currently have userX and userY's public ssh-key attached to user1 and I > have created a HBAC rule to allow user1 to connect with ssh on both server1 > and server2. This is allowing user1 to connect to both servers fine, > without a password. It also is allowing users (X & Y) to ssh user1 at server1 > and user1 at server2. > > How can stop that to restrict userX to be able to ssh as user1 on server1, > but not server2? > > Do I need to do something with the keytabs or add the ssh-keys for userX to > the server1 host only? I'm honestly not sure if I understand the problem well, but would it be helpful to add SSH keys to an ID view that is attached to one of the servers only? From ronaldw at ronzo.at Mon Apr 10 09:49:05 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Mon, 10 Apr 2017 11:49:05 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <20170407082816.GR3438@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <2462f604-e77f-f30c-3e4a-389a82531835@ronzo.at> <20170407082816.GR3438@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <8dd34636-e3ed-6e42-827e-aeb137ffeaa4@ronzo.at> On 2017-04-07 10:28, Sumit Bose wrote: > [...] > I'm not aware of any limitation here. Have you tried to run 'ipa > trust-fetch-domains ad.forest.root' to update the list? > > If this does not help please add 'log level = 100' to > /usr/share/ipa/smb.conf.empty so that it looks like: > > [global] > log level = 100 > > and run trust-fetch-domains again. The debug output can then be found > in /var/log/httpd/error_log. [...] Not one error in the error_log - absolutely nothing. Our AD guys confirmed that there are many more UPN suffixes than the five I can see when I run ipa trust-find. Can somebody confirm that this UPN suffix mismatch is exactly the problem preventing password-based login in my case? From lslebodn at redhat.com Mon Apr 10 10:16:27 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 10 Apr 2017 12:16:27 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> <20170408105339.GB23731@10.4.128.1> Message-ID: <20170410101627.GE6893@10.4.128.1> On (08/04/17 17:55), Ronald Wimmer wrote: >On 2017-04-08 12:53, Lukas Slebodnik wrote: >> On (04/04/17 09:41), Ronald Wimmer wrote: >> > On 2017-03-31 13:35, Lukas Slebodnik wrote: >> > > On (29/03/17 10:47), Ronald Wimmer wrote: >> > > > Hi, >> > > > >> > > > yesterday I suddenly was unable to use the webinterface of my ipa master. SSH >> > > > login (with root user) did not work also. >> > > > >> > > > When I uncommented the setting "memcache_timeout = 600" in the sssd config >> > > > file of the master everything seemed to work fine again. (my ipa setup has a >> > > > trust to AD) >> > > > >> > > I doubt it had anything to do memcache_timeout. >> > > I would say that restart of sssd helped. But it difficult to say >> > > without log files. either sssd logs or at least /var/log/secure >> > > (journald for pam). >> > You were right. I uncommented the setting and the problem ocurred again. >> > >> Did you find anything suspicious in journald? >> Is sssd_be busy (or any other process)? >> high CPU, IO operations ... >> >> It would be good to know more details. Restarting sssd is not a solution. > >sssd_be consumed a lot of CPU and produced a lot of I/O in the sssd cache >directory. After following https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ >the problems did nod reappear. > Did you try all recommended steps or just few? Do you know which one was the most useful in your case? LS From ronaldw at ronzo.at Mon Apr 10 11:07:08 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Mon, 10 Apr 2017 13:07:08 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: <20170410101627.GE6893@10.4.128.1> References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> <20170408105339.GB23731@10.4.128.1> <20170410101627.GE6893@10.4.128.1> Message-ID: On 2017-04-10 12:16, Lukas Slebodnik wrote: > [...] > sssd_be consumed a lot of CPU and produced a lot of I/O in the sssd cache > directory. After following https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ > the problems did nod reappear. > > Did you try all recommended steps or just few? > > Do you know which one was the most useful in your case? > I think the biggest benefit came from moving the sssd cache into RAM. From jhrozek at redhat.com Mon Apr 10 11:23:22 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Apr 2017 13:23:22 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> <20170408105339.GB23731@10.4.128.1> <20170410101627.GE6893@10.4.128.1> Message-ID: <20170410112322.oavoi7hwgbiyy45e@hendrix> On Mon, Apr 10, 2017 at 01:07:08PM +0200, Ronald Wimmer wrote: > On 2017-04-10 12:16, Lukas Slebodnik wrote: > > [...] > > sssd_be consumed a lot of CPU and produced a lot of I/O in the sssd cache > > directory. After following https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ > > the problems did nod reappear. > > > > Did you try all recommended steps or just few? > > > > Do you know which one was the most useful in your case? > > > > I think the biggest benefit came from moving the sssd cache into RAM. This shouldn't be the case with 1.14+ and wasn't in my testing. Did you remove the cache (really remove, not just expire with sss_cache) after you upgraded from 1.13 to 1.14? If yes, can you run some simple systemtap scripts? From ronaldw at ronzo.at Mon Apr 10 11:42:19 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Mon, 10 Apr 2017 13:42:19 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: <20170410112322.oavoi7hwgbiyy45e@hendrix> References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> <20170331113521.GH10135@10.4.128.1> <20170408105339.GB23731@10.4.128.1> <20170410101627.GE6893@10.4.128.1> <20170410112322.oavoi7hwgbiyy45e@hendrix> Message-ID: <62e6160e-c6b6-aef7-b52f-e3f283fa4c7e@ronzo.at> On 2017-04-10 13:23, Jakub Hrozek wrote: > [...] > This shouldn't be the case with 1.14+ and wasn't in my testing. Did you > remove the cache (really remove, not just expire with sss_cache) after > you upgraded from 1.13 to 1.14? > > If yes, can you run some simple systemtap scripts? I did not upgrade from an older version. I experienced the problems with SSSD 1.14. I followed the steps in the performance tuning guide and moved the cache directory into RAM. After that I deleted the directory's content and restarted SSSD. From jameslast29 at gmail.com Mon Apr 10 14:14:13 2017 From: jameslast29 at gmail.com (Johan Vermeulen) Date: Mon, 10 Apr 2017 16:14:13 +0200 Subject: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts Message-ID: Hello All, just getting started with FreeIPA and one of the first features I'm trying is adding hosts, something I can't do in our current ldap-setup. So I'm looking forward to being able to do this. But after adding a host, the only way I see to disable it is unprovision it. And after doing that, I can' t find a way to re-provision the host. Can anybody point me in the right direction regarding this? Many thanks, J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Apr 10 19:37:47 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Apr 2017 15:37:47 -0400 Subject: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts In-Reply-To: References: Message-ID: <28b2458f-cdd3-0993-dc7c-c37362d68547@redhat.com> Johan Vermeulen wrote: > Hello All, > > just getting started with FreeIPA and one of the first features I'm > trying is adding hosts, something I can't do in our current > ldap-setup. So I'm looking forward to being able to do this. > But after adding a host, the only way I see to disable it is unprovision > it. And after doing that, I can' t find a way to re-provision the host. > > Can anybody point me in the right direction regarding this? I'm not sure I follow what you're doing and don't want to guess and send you on a wild goose chase :-) Can you elaborate on your workflow and the output you're seeing when you try to re-provision? rob From datakid at gmail.com Mon Apr 10 22:51:55 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Tue, 11 Apr 2017 08:51:55 +1000 Subject: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts In-Reply-To: References: Message-ID: On 11 April 2017 at 00:14, Johan Vermeulen wrote: > Hello All, > > just getting started with FreeIPA and one of the first features I'm trying > is adding hosts, something I can't do in our current > ldap-setup. So I'm looking forward to being able to do this. > But after adding a host, the only way I see to disable it is unprovision > it. And after doing that, I can' t find a way to re-provision the host. > > Can anybody point me in the right direction regarding this? > > Many thanks, J. > > Rob is right - it depends on what you are doing. But, in the mean time, here are a couple of pointers: How to enable/disable hosts https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/host-disable.html If what you are after is having it in the domain but restricting access, then you are looking for "Host Based Access Control" https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html 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: From solerm at unicc.org Tue Apr 11 06:51:32 2017 From: solerm at unicc.org (SOLER SANGUESA Miguel) Date: Tue, 11 Apr 2017 06:51:32 +0000 Subject: [Freeipa-users] Problem starting smb service after ipa-adtrust-install Message-ID: hello I'm unable to start smb after executing ipa-adtrust-install. the execution of ipa-adtrust-install is: [root at hostname ~]# ipa-adtrust-install --enable-compat --add-agents -d The log file for this installation can be found in /var/log/ipaserver-install.log ipa : DEBUG /sbin/ipa-adtrust-install was invoked with options: {'enable_compat': True, 'add_agents': True, 'no_msdcs': False, 'rid_base': 1000, 'secondary_rid_base': 100000000, 'netbios_name': None, 'debug': True, 'add_sids': False, 'unattended': False} ipa : DEBUG missing options might be asked for interactively later ipa : DEBUG IPA version 4.4.0-14.el7_3.6 ipa : DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' ipa : DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' ============================================================================== This program will setup components needed to establish trust to AD domains for the IPA Server. This includes: * Configure Samba * Add trust related objects to IPA LDAP server To accept the default shown in brackets, press the Enter key. ipa : DEBUG importing all plugin modules in ipaserver.plugins... ... ipa : DEBUG importing plugin module ipaserver.plugins.hbac ipa : DEBUG ipaserver.plugins.hbac is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.otp ipa : DEBUG ipaserver.plugins.otp is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.pkinit ipa : DEBUG ipaserver.plugins.pkinit is not a valid plugin module ... ipa : DEBUG Starting external process ipa : DEBUG args=klist -V ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=Kerberos 5 version 1.14.1 ipa : DEBUG stderr= ipa : DEBUG importing plugin module ipaserver.plugins.rabase ipa : DEBUG ipaserver.plugins.rabase is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.sudo ipa : DEBUG ipaserver.plugins.sudo is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.virtual ipa : DEBUG ipaserver.plugins.virtual is not a valid plugin module ipa : DEBUG importing plugin module ipaserver.plugins.xmlserver IPA generated smb.conf detected. Overwrite smb.conf? [no]: yes Configuring cross-realm trusts for IPA server requires password for user 'admin'. This user is a regular system account used for IPA server administration. admin password: ipa : DEBUG Starting external process ipa : DEBUG args=kinit admin ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=Password for admin at MY.IPA.SUBDOMAIN: ipa : DEBUG stderr= ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_48972688 ipa.ipaserver.plugins.user.user_show: DEBUG raw: user_show(u'admin', version=u'2.213') ipa.ipaserver.plugins.user.user_show: DEBUG user_show(u'admin', rights=False, all=False, raw=False, version=u'2.213', no_members=False) ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa.ipaserver.plugins.group.group_show: DEBUG raw: group_show(u'admins', version=u'2.213') ipa.ipaserver.plugins.group.group_show: DEBUG group_show(u'admins', rights=False, all=False, raw=False, version=u'2.213', no_members=False) ipa : DEBUG Searching for objects with missing SID with filter=(&(objectclass=ipaobject)(!(objectclass=mepmanagedentry))(|(objectclass=posixaccount)(objectclass=posixgroup)(objectclass=ipaidobject))(!(ipantsecurityidentifier=*))), base_dn=dc=my,dc=ipa,dc=subdomain WARNING: 12 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]: The following operations may take some minutes to complete. Please wait until the prompt is returned. ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa : DEBUG Configuring CIFS Configuring CIFS ipa : DEBUG [1/22]: stopping smbd [1/22]: stopping smbd ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl is-active smb.service ipa : DEBUG Process finished, return code=3 ipa : DEBUG stdout=failed ipa : DEBUG stderr= ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl stop winbind.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl stop smb.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG duration: 0 seconds ipa : DEBUG [2/22]: creating samba domain object [2/22]: creating samba domain object ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa : DEBUG Samba domain object already exists Samba domain object already exists ipa : DEBUG duration: 0 seconds ipa : DEBUG [3/22]: creating samba config registry [3/22]: creating samba config registry ipa : DEBUG Starting external process ipa : DEBUG args=/usr/bin/net conf import /tmp/tmpTiRBM4 ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG duration: 0 seconds ipa : DEBUG [4/22]: writing samba config file [4/22]: writing samba config file ipa : DEBUG duration: 0 seconds ipa : DEBUG [5/22]: adding cifs Kerberos principal [5/22]: adding cifs Kerberos principal ipa.ipaserver.plugins.service.service_add: DEBUG raw: service_add(u'cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN', version=u'2.213') ipa.ipaserver.plugins.service.service_add: DEBUG service_add(, force=False, all=False, raw=False, version=u'2.213', no_members=False) ipa.ipaserver.plugins.host.host_show: DEBUG raw: host_show(u'hostname.MY.IPA.SUBDOMAIN', version=u'2.213') ipa.ipaserver.plugins.host.host_show: DEBUG host_show(u'hostname.MY.IPA.SUBDOMAIN', rights=False, all=False, raw=False, version=u'2.213', no_members=False) ipa : DEBUG found 1 A records for hostname.MY.IPA.SUBDOMAIN.: XX.XX.XX.XX ipa : DEBUG The DNS response does not contain an answer to the question: hostname.MY.IPA.SUBDOMAIN. IN AAAA ipa : DEBUG Starting external process ipa : DEBUG args=ipa-rmkeytab --principal cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN -k /etc/samba/samba.keytab ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr=Removing principal cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN ipa : DEBUG Removing service credentials cache ipa : DEBUG Ccache path: '/var/run/samba/krb5cc_samba' ipa : DEBUG Starting external process ipa : DEBUG args=/usr/bin/kdestroy -c /var/run/samba/krb5cc_samba ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Starting external process ipa : DEBUG args=ipa-getkeytab --server hostname.MY.IPA.SUBDOMAIN --principal cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN -k /etc/samba/samba.keytab ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr=Keytab successfully retrieved and stored in: /etc/samba/samba.keytab ipa : DEBUG duration: 0 seconds ipa : DEBUG [6/22]: adding cifs and host Kerberos principals to the adtrust agents group [6/22]: adding cifs and host Kerberos principals to the adtrust agents group ipa : DEBUG duration: 0 seconds ipa : DEBUG [7/22]: check for cifs services defined on other replicas [7/22]: check for cifs services defined on other replicas ipa : DEBUG duration: 0 seconds ipa : DEBUG [8/22]: adding cifs principal to S4U2Proxy targets [8/22]: adding cifs principal to S4U2Proxy targets ipa : DEBUG cifs principal already targeted, nothing to do. cifs principal already targeted, nothing to do. ipa : DEBUG duration: 0 seconds ipa : DEBUG [9/22]: adding admin(group) SIDs [9/22]: adding admin(group) SIDs ipa : DEBUG Admin SID already set, nothing to do Admin SID already set, nothing to do ipa : DEBUG Admin group SID already set, nothing to do Admin group SID already set, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [10/22]: adding RID bases [10/22]: adding RID bases ipa : DEBUG RID bases already set, nothing to do RID bases already set, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [11/22]: updating Kerberos config [11/22]: updating Kerberos config ipa : DEBUG 'dns_lookup_kdc' already set to 'true', nothing to do. 'dns_lookup_kdc' already set to 'true', nothing to do. ipa : DEBUG duration: 0 seconds ipa : DEBUG [12/22]: activating CLDAP plugin [12/22]: activating CLDAP plugin ipa : DEBUG CLDAP plugin already configured, nothing to do CLDAP plugin already configured, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [13/22]: activating sidgen task [13/22]: activating sidgen task ipa : DEBUG Sidgen task plugin already configured, nothing to do Sidgen task plugin already configured, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [14/22]: configuring smbd to start on boot [14/22]: configuring smbd to start on boot ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl is-enabled smb.service ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout=disabled ipa : DEBUG stderr= ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl disable smb.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG service ADTRUST startup entry already enabled ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl disable smb.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG service EXTID startup entry already enabled ipa : DEBUG duration: 1 seconds ipa : DEBUG [15/22]: adding special DNS service records [15/22]: adding special DNS service records ipa.ipaserver.plugins.dns.dns_is_enabled: DEBUG raw: dns_is_enabled(version=u'2.213') ipa.ipaserver.plugins.dns.dns_is_enabled: DEBUG dns_is_enabled(version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG raw: dnszone_show(u'MY.IPA.SUBDOMAIN', version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG dnszone_show(, rights=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dns_update_system_records: DEBUG raw: dns_update_system_records(version=u'2.213') ipa.ipaserver.plugins.dns.dns_update_system_records: DEBUG dns_update_system_records(dry_run=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.server.server_find: DEBUG raw: server_find(None, version=u'2.213', no_members=False) ipa.ipaserver.plugins.server.server_find: DEBUG server_find(None, all=False, raw=False, version=u'2.213', no_members=False, pkey_only=False) ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG raw: topologysuffix_find(None, all=True, raw=True, version=u'2.213') ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG topologysuffix_find(None, all=True, raw=True, version=u'2.213', pkey_only=False) ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG raw: server_role_find(None, server_server=u'hostname.MY.IPA.SUBDOMAIN', status=u'enabled', version=u'2.213') ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG server_role_find(None, server_server=u'hostname.MY.IPA.SUBDOMAIN', status=u'enabled', all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG raw: server_role_find(None, server_server=u'OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN', status=u'enabled', version=u'2.213') ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG server_role_find(None, server_server=u'OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN', status=u'enabled', all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG raw: dnszone_show(, version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG dnszone_show(, rights=False, all=False, raw=False, version=u'2.213') ipa : DEBUG found 1 1 records for hostname.MY.IPA.SUBDOMAIN.: XX.XX.XX.XX ipa : DEBUG The DNS response does not contain an answer to the question: hostname.MY.IPA.SUBDOMAIN. IN AAAA ipa : DEBUG found 1 1 records for OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.: YY.YY.YY.YY ipa : DEBUG The DNS response does not contain an answer to the question: OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN. IN AAAA ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , txtrecord=[u'"MY.IPA.SUBDOMAIN"'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , txtrecord=(u'"MY.IPA.SUBDOMAIN"',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos-master._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos-master._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kpasswd._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kpasswd._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kpasswd._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kpasswd._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 123 hostname.MY.IPA.SUBDOMAIN.', u'0 100 123 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ntp._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 123 hostname.MY.IPA.SUBDOMAIN.', u'0 100 123 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ntp._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , arecord=[u'XX.XX.XX.XX', u'YY.YY.YY.YY'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , arecord=(u'XX.XX.XX.XX', u'YY.YY.YY.YY'), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos-master._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos-master._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.server.server_find: DEBUG raw: server_find(None, version=u'2.213', pkey_only=True) ipa.ipaserver.plugins.server.server_find: DEBUG server_find(None, all=False, raw=False, version=u'2.213', no_members=True, pkey_only=True) ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG raw: topologysuffix_find(None, all=True, raw=True, version=u'2.213') ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG topologysuffix_find(None, all=True, raw=True, version=u'2.213', pkey_only=False) ipa.ipaserver.plugins.location.location_find: DEBUG raw: location_find(None, version=u'2.213') ipa.ipaserver.plugins.location.location_find: DEBUG location_find(None, all=False, raw=False, version=u'2.213', pkey_only=False) ipa : DEBUG duration: 0 seconds ipa : DEBUG [16/22]: enabling trusted domains support for older clients via Schema Compatibility plugin [16/22]: enabling trusted domains support for older clients via Schema Compatibility plugin ipa : DEBUG duration: 0 seconds ipa : DEBUG [17/22]: restarting Directory Server to take MS PAC and LDAP plugins changes into account [17/22]: restarting Directory Server to take MS PAC and LDAP plugins changes into account ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl restart dirsrv at MY-IPA-SUBDOMAIN.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl is-active dirsrv at MY-IPA-SUBDOMAIN.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=active ipa : DEBUG stderr= ipa : DEBUG wait_for_open_ports: localhost [389] timeout 300 ipa : DEBUG duration: 5 seconds ipa : DEBUG [18/22]: adding fallback group [18/22]: adding fallback group ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa : DEBUG Fallback group already set, nothing to do Fallback group already set, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [19/22]: adding Default Trust View [19/22]: adding Default Trust View ipa : DEBUG Default Trust View already exists. Default Trust View already exists. ipa : DEBUG duration: 0 seconds ipa : DEBUG [20/22]: setting SELinux booleans [20/22]: setting SELinux booleans ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/selinuxenabled ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG duration: 0 seconds ipa : DEBUG [21/22]: starting CIFS services [21/22]: starting CIFS services ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl start smb.service ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout= ipa : DEBUG stderr=Job for smb.service failed because the control process exited with error code. See "systemctl status smb.service" and "journalctl -xe" for details. ipa : CRITICAL CIFS services failed to start ipa : DEBUG duration: 6 seconds ipa : DEBUG [22/22]: restarting smbd [22/22]: restarting smbd ipa : DEBUG duration: 0 seconds ipa : DEBUG Done configuring CIFS. Done configuring CIFS. ... ipa : DEBUG Starting external process ipa : DEBUG args=kinit admin ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=Password for admin at MY.IPA.SUBDOMAIN: ipa : DEBUG stderr= ipa : INFO The ipa-adtrust-install command was successful On the smb logs I can see: ... [2017/04/10 16:27:58.896485, 11, pid=22584, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1067(smbldap_open) smbldap_open: already connected to the LDAP server [2017/04/10 16:27:58.898224, 0, pid=22584, effective(0, 0), real(0, 0)] ipa_sam.c:3688(ipasam_search_domain_info) iapsam_search_domain_info: Got [2] domain info entries, but expected only 1. <*************************************************************** [2017/04/10 16:27:58.898278, 0, pid=22584, effective(0, 0), real(0, 0)] ipa_sam.c:4543(pdb_init_ipasam) pdb_init_ldapsam: WARNING: Could not get domain info, nor add one to the domain. We cannot work reliably without it. <**************************************** [2017/04/10 16:27:58.898302, 0, pid=22584, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_interface.c:179(make_pdb_method_name) pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket did not correctly init (error was NT_STATUS_CANT_ACCESS_DOMAIN_INFO) I have traced the ipa-adtrust-install and systemctl start smb, but I couldn't get the "domain info entries". Checking the LDAP directory I showed: [root at HOSTNAME]# ldapsearch -w XXXXXXXX -h localhost -s sub -b 'dc=MY,dc=IPA,dc=SUBDOMAIN' -D "cn=Directory Manager" "objectclass=ipaNTDomainAttrs" # extended LDIF # # LDAPv3 # base with scope subtree # filter: objectclass=ipaNTDomainAttrs # requesting: ALL # # my.ipa.subdomain, ad + 773d9684-12f211e7-b1abe436-0243208c, etc, my.ipa.subdomain dn: cn=my.ipa.subdomain,cn=ad+nsuniqueid=773d9684-12f211e7-b1abe436-0243208c,cn=etc,dc=MY,dc=IPA,dc=SUBDOMAIN objectClass: nsContainer objectClass: ipaNTDomainAttrs objectClass: top ipaNTSecurityIdentifier: S-1-5-21-3119812475-2647440479-1423840280 cn: my.ipa.subdomain ipaNTDomainGUID: 449b23da-6e30-4fa9-9d34-3426bcec8d0f ipaNTFlatName: IPA # my.ipa.subdomain, ad, etc, my.ipa.subdomain dn: cn=my.ipa.subdomain,cn=ad,cn=etc,dc=MY,dc=IPA,dc=SUBDOMAIN ipaNTFallbackPrimaryGroup: cn=editors,cn=groups,cn=accounts,dc=MY,dc=IPA,dc=SUBDOMAIN objectClass: nsContainer objectClass: ipaNTDomainAttrs objectClass: top ipaNTSecurityIdentifier: S-1-5-21-1187620393-3629609531-1738010010 cn: my.ipa.subdomain ipaNTDomainGUID: 09ec963b-ca7d-4a04-b533-7283d0fac036 ipaNTFlatName: IPA # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 But not sure if those are the 2 "Domains info entries". Can you please let me know how to fix this problem? ################ The environment: ##################### Red Hat Enterprise Linux Server release 7.3 (Maipo) SELinux status: disabled Domain level 1 ipa-admintools-4.4.0-14.el7_3.6.noarch ipa-client-4.4.0-14.el7_3.6.x86_64 ipa-client-common-4.4.0-14.el7_3.6.noarch ipa-common-4.4.0-14.el7_3.6.noarch ipa-debuginfo-4.4.0-14.el7_3.6.x86_64 ipa-python-compat-4.4.0-14.el7_3.6.noarch ipa-server-4.4.0-14.el7_3.6.x86_64 ipa-server-common-4.4.0-14.el7_3.6.noarch ipa-server-dns-4.4.0-14.el7_3.6.noarch ipa-server-trust-ad-4.4.0-14.el7_3.6.x86_64 libipa_hbac-1.14.0-43.el7_3.11.x86_64 python2-ipaclient-4.4.0-14.el7_3.6.noarch python2-ipalib-4.4.0-14.el7_3.6.noarch python2-ipaserver-4.4.0-14.el7_3.6.noarch python-iniparse-0.4-9.el7.noarch python-ipaddress-1.0.16-2.el7.noarch python-libipa_hbac-1.14.0-43.el7_3.11.x86_64 sssd-ipa-1.14.0-43.el7_3.11.x86_64 samba-winbind-modules-4.4.4-12.el7_3.x86_64 samba-client-4.4.4-12.el7_3.x86_64 samba-winbind-clients-4.4.4-12.el7_3.x86_64 samba-libs-4.4.4-12.el7_3.x86_64 samba-common-tools-4.4.4-12.el7_3.x86_64 samba-debuginfo-4.4.4-12.el7_3.x86_64 samba-common-4.4.4-12.el7_3.noarch samba-common-libs-4.4.4-12.el7_3.x86_64 samba-4.4.4-12.el7_3.x86_64 samba-winbind-4.4.4-12.el7_3.x86_64 samba-python-4.4.4-12.el7_3.x86_64 samba-client-libs-4.4.4-12.el7_3.x86_64 Thank you very much. ______________________________ Miguel Soler Sang?esa Consultant - Linux Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameslast29 at gmail.com Tue Apr 11 08:02:46 2017 From: jameslast29 at gmail.com (Johan Vermeulen) Date: Tue, 11 Apr 2017 10:02:46 +0200 Subject: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts In-Reply-To: <28b2458f-cdd3-0993-dc7c-c37362d68547@redhat.com> References: <28b2458f-cdd3-0993-dc7c-c37362d68547@redhat.com> Message-ID: Rob, thanks for helping me out. I support some 80 laptop users at the moment, all running Centos7. The users are now in ldap, the laptops ( hosts) are not. I'm testing the ability to add the laptops as hosts. Under "identity - hosts", when selecting a host, I go to "actions". The only way I see to disable ( block) a host, what I would do when a laptop is stolen for instance, is unprovision. I then tried to re-provision it, I see no "provision" option. I tried to "rebuild auto membership" and " new certificate" but that doesn't seem to work. I hope I'm making sense. Greetings, J. 2017-04-10 21:37 GMT+02:00 Rob Crittenden : > Johan Vermeulen wrote: > > Hello All, > > > > just getting started with FreeIPA and one of the first features I'm > > trying is adding hosts, something I can't do in our current > > ldap-setup. So I'm looking forward to being able to do this. > > But after adding a host, the only way I see to disable it is unprovision > > it. And after doing that, I can' t find a way to re-provision the host. > > > > Can anybody point me in the right direction regarding this? > > I'm not sure I follow what you're doing and don't want to guess and send > you on a wild goose chase :-) > > Can you elaborate on your workflow and the output you're seeing when you > try to re-provision? > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameslast29 at gmail.com Tue Apr 11 08:07:34 2017 From: jameslast29 at gmail.com (Johan Vermeulen) Date: Tue, 11 Apr 2017 10:07:34 +0200 Subject: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts In-Reply-To: References: Message-ID: Hello, thanks for the advise. I will try this asap. Greetings, J. 2017-04-11 0:51 GMT+02:00 Lachlan Musicman : > On 11 April 2017 at 00:14, Johan Vermeulen wrote: > >> Hello All, >> >> just getting started with FreeIPA and one of the first features I'm >> trying is adding hosts, something I can't do in our current >> ldap-setup. So I'm looking forward to being able to do this. >> But after adding a host, the only way I see to disable it is unprovision >> it. And after doing that, I can' t find a way to re-provision the host. >> >> Can anybody point me in the right direction regarding this? >> >> Many thanks, J. >> >> > > Rob is right - it depends on what you are doing. > > But, in the mean time, here are a couple of pointers: > > How to enable/disable hosts > https://access.redhat.com/documentation/en-US/Red_Hat_ > Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_ > Guide/host-disable.html > > > If what you are after is having it in the domain but restricting access, > then you are looking for "Host Based Access Control" > > https://access.redhat.com/documentation/en-US/Red_Hat_ > Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_ > Guide/configuring-host-access.html > > > 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: From sbose at redhat.com Tue Apr 11 10:21:02 2017 From: sbose at redhat.com (Sumit Bose) Date: Tue, 11 Apr 2017 12:21:02 +0200 Subject: [Freeipa-users] Password-based authentication with AD users does not work In-Reply-To: <8dd34636-e3ed-6e42-827e-aeb137ffeaa4@ronzo.at> References: <20170406092122.GK3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <79dc75b3-226d-8b7f-4f13-b993e1ad6865@ronzo.at> <20170406101618.GL3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <5289dd50-43f0-3004-f21a-95c7c85887d8@ronzo.at> <20170406185049.GP3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <2462f604-e77f-f30c-3e4a-389a82531835@ronzo.at> <20170407082816.GR3438@p.Speedport_W_724V_Typ_A_05011603_00_011> <8dd34636-e3ed-6e42-827e-aeb137ffeaa4@ronzo.at> Message-ID: <20170411102102.GM3438@p.Speedport_W_724V_Typ_A_05011603_00_011> On Mon, Apr 10, 2017 at 11:49:05AM +0200, Ronald Wimmer wrote: > On 2017-04-07 10:28, Sumit Bose wrote: > > [...] > > I'm not aware of any limitation here. Have you tried to run 'ipa > > trust-fetch-domains ad.forest.root' to update the list? > > > > If this does not help please add 'log level = 100' to > > /usr/share/ipa/smb.conf.empty so that it looks like: > > > > [global] > > log level = 100 > > > > and run trust-fetch-domains again. The debug output can then be found > > in /var/log/httpd/error_log. [...] > > Not one error in the error_log - absolutely nothing. Our AD guys confirmed > that there are many more UPN suffixes than the five I can see when I run ipa > trust-find. > > Can somebody confirm that this UPN suffix mismatch is exactly the problem > preventing password-based login in my case? To close the thread, it turned out that the original issue with authenticating with enterprise principals is a bug which is now tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1441077. 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 freeipa at jacobdevans.com Tue Apr 11 14:27:07 2017 From: freeipa at jacobdevans.com (Jake) Date: Tue, 11 Apr 2017 10:27:07 -0400 (EDT) Subject: [Freeipa-users] 'NoneType' object is not iterable when removing broken ipa-server replica Message-ID: <656355607.32182.1491920827896@jersey.jacobdevans.com> Help! I'm having issues removing a bad replica. Everytime I run: ipa-replica-manage del ipa01.example.com or ipa-replica-manage del --force ipa0 1 .example.com I get an error: 'NoneType' object is not iterable if I try to remove it from the web interface: IPA Error 903: InternalError an internal error has occurred They're removed from hosts, but I cannot get them our of the existing topology Is there a "purge this host" button that removes it, ignoring errors if it's already missing. Thanks Always, -Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 11 14:54:16 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Apr 2017 10:54:16 -0400 Subject: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts In-Reply-To: References: <28b2458f-cdd3-0993-dc7c-c37362d68547@redhat.com> Message-ID: Johan Vermeulen wrote: > Rob, > > thanks for helping me out. > I support some 80 laptop users at the moment, all running Centos7. > The users are now in ldap, the laptops ( hosts) are not. I'm testing the > ability to add the laptops as hosts. > > Under "identity - hosts", when selecting a host, I go to "actions". The > only way I see to disable ( block) a host, what I would do when > a laptop is stolen for instance, is unprovision. > I then tried to re-provision it, I see no "provision" option. I tried to > "rebuild auto membership" and " new certificate" but that doesn't seem > to work. > I hope I'm making sense. In the case of a lost or stolen laptop then disabling the host seems like a good mechanism. It will revoke and certificates issued for the host and invalidate its keytab. Provisioning happens when ipa-client-install is run on the host [1]. There is no facility for remote provisioning. rob [1] technically a host is provisioned when it has a keytab but this doesn't configure that host to actually use it and you potentially need to safely transfer this keytab to the host. From spammewoods at cox.net Tue Apr 11 16:24:51 2017 From: spammewoods at cox.net (spammewoods at cox.net) Date: Tue, 11 Apr 2017 16:24:51 +0000 (GMT) Subject: [Freeipa-users] RHEL 6.9 AD Smart Card login Message-ID: I made the changes in this Bugzilla report and its still failing. When I click on Smartcard Authenication on the GDM login screen, I get the error message "Authentication failure". It looks like this Bugzilla was for IDM users using smart cards. I'm trying to use Active Directory Users and smart cards. Here is my error log from /var/log/sssd/p11_child.log (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x0400): p11_child started. (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x2000): Running in [pre-auth] mode. (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x2000): Running with effective IDs: [0][0]. (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x2000): Running with real IDs [0][0]. (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [parse_cert_verify_opts] (0x4000): Found 'no_ocsp' option, disabling OCSP. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Default Module List: (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): common name: [NSS Internal PKCS #11 Module]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): dll name: [(null)]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): common name: [CoolKey PKCS #11 Module]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): dll name: [libcoolkeypk11.so]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Dead Module List: (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): DB Module List: (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): common name: [NSS Internal Module]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): dll name: [(null)]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): common name: [Policy File]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): dll name: [(null)]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Description [NSS User Private Key and Certificate Services Mozilla Foundation ] Manufacturer [Mozilla Foundation ] flags [1]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Description [NSS Internal Cryptographic Services Mozilla Foundation ] Manufacturer [Mozilla Foundation ] flags [1]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Description [SCM SCR 3310 00 00 Unknown ] Manufacturer [Unknown ] flags [7]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Found [SMITH.RYAN.123456] in slot [SCM SCR 3310 00 00][1] of module [2]. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Token is NOT friendly. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Trying to switch to friendly to read certificate. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Login required. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x0020): Login required but no pin available, continue. (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): found cert[SMITH.RYAN.123456:PIV ID Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): found cert[SMITH.RYAN.123456:PIV Email Signature Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): found cert[SMITH.RYAN.123456:PIV Email Encryption Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): Filtered certificates: (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): found cert[SMITH.RYAN.123456:PIV ID Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): found cert[SMITH.RYAN.123456:PIV Email Signature Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): More than one certificate found, using just the first one. On Fri, Apr 7, 2017 at 4:35 AM, Sumit Bose wrote: > On Thu, Apr 06, 2017 at 06:36:43PM +0000, spammewoods at cox.net wrote: >> I have created a two way trust between my IDM server and Active >> Directory. >> I have been able to successful get RHEL 7.3 IDM server and RHEL 7.3 >> IDM >> clients to allow Active Directory login using CAC smart cards into >> Gnome. >> I'm using SSSD for the smart card login process instead of authconfig >> and >> pkcs11. I'm currently trying to get the same thing working for RHEL >> 6.9, >> but I have not been able to get it to work. The latest version of >> SSSD on >> RHEL 6.9 is 1.13.3 and from my understanding I need to have at least >> 1.14.0 >> for SSSD to handle AD smart card logins. So, I have tried to >> configure > > The Smartcard authentication feature was backported to RHEL-6.9. > > Please note that the GDM Smartcard feature must be configured > differently in RHEL6 then in RHEL7, details for RHEL-6.9 can e.g. > found > in https://bugzilla.redhat.com/show_bug.cgi?id=1300421#c13 > > HTH > > bye, > Sumit > >> pam_pkcs11.conf file to use the pwent mapper to link the Common Name >> (CN) to >> the Active Directory User account. I have created an User ID >> Override for >> the AD user and added CN name from the Certificate on the smart card >> into >> the GECOS field. I also have added all three certificates from the >> CAC >> smart card into the User ID Override. >> >> When I try and log in, I get this error message in /var/log/secure: >> Apr 6 13:21:57 site-lws05 pam: gdm-smartcard: >> pam_pkcs11(gdm-smartcard:auth): pam_get_pwd() failed: Conversation >> error >> Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: >> pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #1 >> Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: >> pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #2 >> Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: >> pam_pkcs11(gdm-smartcard:auth): no valid certificate which meets all >> requirements found >> >> Here is the some details: >> IDM Domain: idm.domain.local >> Windows Domain: domain.local >> RHEL 7.3 IDM Server: site-idm01.idm.domain.local >> RHEL 6.9 IDM Client : site-lws05.idm.domain.local >> >> When I run the getent command on local accounts and IDM accounts I >> get user >> details, but when I run the command on AD accounts it doesn't find >> them. >> So, I'm wondering if that's why its not finding the CN name in the >> GECOS >> field. I'm trying to avoid using the cn_map on the clients, >> because we >> have a large amount of users and thats alot of extra work to manage >> that >> file. That's why I wanted to use the pwent mapper. >> Here is my SSSD config file from the RHEL 6.9 client: >> [domain/idm.domain.local] >> override_shell = /bin/bash >> debug_level = 9 >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = idm.domain.local >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = site-lws05.idm.domain.local >> chpass_provider = ipa >> ipa_server = _srv_, site-idm01.idm.domain.local >> ldap_tls_cacert = /etc/ipa/ca.crt >> [sssd] >> debug_level = 9 >> services = nss, sudo, pam, ssh, ifp >> domains = idm.domain.local >> certificate_verification = no_ocsp >> ldap_user_certificate = userCertificate;binary >> [nss] >> debug_level = 9 >> homedir_substring = /home >> [pam] >> debug_level = 9 >> pam_cert_auth = True >> [sudo] >> debug_level = 9 >> [autofs] >> debug_level = 9 >> [ssh] >> debug_level = 9 >> [pac] >> debug_level = 9 >> [ifp] >> debug_level = 9 >> >> Here is my nssswitch file from the RHEL 6.9 client: >> # /etc/nsswitch.conf >> # >> # An example Name Service Switch config file. This file should be >> # sorted with the most-used services at the beginning. >> # >> # The entry '[NOTFOUND=return]' means that the search for an >> # entry should stop if the search in the previous entry turned >> # up nothing. Note that if the search failed due to some other reason >> # (like no NIS server responding) then the search continues with the >> # next entry. >> # >> # Valid entries include: >> # >> # nisplus Use NIS+ (NIS version 3) >> # nis Use NIS (NIS version 2), also called >> YP >> # dns Use DNS (Domain Name Service) >> # files Use the local files >> # db Use the local database (.db) files >> # compat Use NIS on compat mode >> # hesiod Use Hesiod for user lookups >> # [NOTFOUND=return] Stop searching if not found so far >> # >> # To use db, put the "db" in front of "files" for entries you want to >> be >> # looked up first in the databases >> # >> # Example: >> #passwd: db files nisplus nis >> #shadow: db files nisplus nis >> #group: db files nisplus nis >> passwd: files sss >> shadow: files sss >> group: files sss >> #hosts: db files nisplus nis dns >> hosts: files dns >> # Example - obey only what nisplus tells us... >> #services: nisplus [NOTFOUND=return] files >> #networks: nisplus [NOTFOUND=return] files >> #protocols: nisplus [NOTFOUND=return] files >> #rpc: nisplus [NOTFOUND=return] files >> #ethers: nisplus [NOTFOUND=return] files >> #netmasks: nisplus [NOTFOUND=return] files >> bootparams: nisplus [NOTFOUND=return] files >> ethers: files >> netmasks: files >> networks: files >> protocols: files >> rpc: files >> services: files sss >> netgroup: files sss >> publickey: nisplus >> automount: files sss >> aliases: files nisplus >> sudoers: files sss >> >> Here is my system-auth from the RHEL 6.9 client: >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required pam_env.so >> auth [success=1 default=ignore] pam_succeed_if.so service >> notin >> login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet >> use_uid >> auth [success=done authinfo_unavail=ignore ignore=ignore >> default=die] >> pam_pkcs11.so card_only >> auth sufficient pam_fprintd.so >> auth sufficient pam_unix.so nullok try_first_pass >> auth requisite pam_succeed_if.so uid >= 500 quiet >> auth sufficient pam_sss.so use_first_pass >> auth required pam_deny.so >> account required pam_unix.so >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid < 500 quiet >> account [default=bad success=ok user_unknown=ignore] pam_sss.so >> account required pam_permit.so >> password requisite pam_cracklib.so try_first_pass retry=3 >> type= >> password sufficient pam_unix.so sha512 shadow nullok >> try_first_pass >> use_authtok >> password sufficient pam_sss.so use_authtok >> password required pam_deny.so >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session optional pam_oddjob_mkhomedir.so umask=0077 >> session [success=1 default=ignore] pam_succeed_if.so service in >> crond >> quiet use_uid >> session required pam_unix.so >> session optional pam_sss.so >> >> Here is my password-auth from the RHEL 6.9 client: >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required pam_env.so >> auth sufficient pam_unix.so nullok try_first_pass >> auth requisite pam_succeed_if.so uid >= 500 quiet >> auth sufficient pam_sss.so use_first_pass >> auth required pam_deny.so >> account required pam_unix.so >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid < 500 quiet >> account [default=bad success=ok user_unknown=ignore] pam_sss.so >> account required pam_permit.so >> password requisite pam_cracklib.so try_first_pass retry=3 >> type= >> password sufficient pam_unix.so sha512 shadow nullok >> try_first_pass >> use_authtok >> password sufficient pam_sss.so use_authtok >> password required pam_deny.so >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session optional pam_oddjob_mkhomedir.so umask=0077 >> session [success=1 default=ignore] pam_succeed_if.so service in >> crond >> quiet use_uid >> session required pam_unix.so >> session optional pam_sss.so >> >> Here is my smartcard-auth from the RHEL 6.9 client: >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required pam_env.so >> auth [success=done ignore=ignore default=die] pam_pkcs11.so >> wait_for_card card_only >> auth required pam_deny.so >> account required pam_unix.so >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid < 500 quiet >> account [default=bad success=ok user_unknown=ignore] pam_sss.so >> account required pam_permit.so >> password required pam_pkcs11.so >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session optional pam_oddjob_mkhomedir.so umask=0077 >> session [success=1 default=ignore] pam_succeed_if.so service in >> crond >> quiet use_uid >> session required pam_unix.so >> session optional pam_sss.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 > > -- > 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 dag at sonsorol.org Tue Apr 11 18:31:32 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Tue, 11 Apr 2017 14:31:32 -0400 Subject: [Freeipa-users] strange error when running "ipa help topics" Message-ID: <58ED2104.8000407@sonsorol.org> An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 11 21:25:10 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Apr 2017 17:25:10 -0400 Subject: [Freeipa-users] strange error when running "ipa help topics" In-Reply-To: <58ED2104.8000407@sonsorol.org> References: <58ED2104.8000407@sonsorol.org> Message-ID: <20251199-2837-bb18-c5e6-7e3f04f050b2@redhat.com> Chris Dagdigian wrote: > > Never seen this one before, any hints? > > testidm]# ipa help topics > ipa: ERROR: error marshalling data for XML-RPC transport: message: need > a ; got 'No valid Negotiate header in server response' > (a ) What version of client and what version of server? Newer clients fetch the schema from the server in order to build the parameters. Looks like that retrieval is failing for some reason. You can add a few -v's to the ipa command to provide more details on what is being sent and received, e.g. ipa -vvv help topics rob From rcritten at redhat.com Tue Apr 11 21:27:51 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Apr 2017 17:27:51 -0400 Subject: [Freeipa-users] 'NoneType' object is not iterable when removing broken ipa-server replica In-Reply-To: <656355607.32182.1491920827896@jersey.jacobdevans.com> References: <656355607.32182.1491920827896@jersey.jacobdevans.com> Message-ID: Jake wrote: > Help! > I'm having issues removing a bad replica. > > Everytime I run: > > ipa-replica-manage del ipa01.example.com > or > ipa-replica-manage del --force ipa01.example.com > > I get an error: 'NoneType' object is not iterable > > if I try to remove it from the web interface: > > > IPA Error 903: InternalError > > an internal error has occurred I wonder if a traceback is logged in /var/log/httpd/error_log > They're removed from hosts, but I cannot get them our of the existing > topology Not sure what you mean here. > > Is there a "purge this host" button that removes it, ignoring errors if > it's already missing. --force ignore some errors but not unknown errors like this. What version of IPA is this? rob From sbose at redhat.com Tue Apr 11 21:32:34 2017 From: sbose at redhat.com (Sumit Bose) Date: Tue, 11 Apr 2017 23:32:34 +0200 Subject: [Freeipa-users] RHEL 6.9 AD Smart Card login In-Reply-To: References: Message-ID: <20170411213234.GH25726@p.Speedport_W_724V_Typ_A_05011603_00_011> On Tue, Apr 11, 2017 at 04:24:51PM +0000, spammewoods at cox.net wrote: > I made the changes in this Bugzilla report and its still failing. When I > click on Smartcard Authenication on the GDM login screen, I get the error > message "Authentication failure". It looks like this Bugzilla was for IDM > users using smart cards. I'm trying to use Active Directory Users and > smart cards. Using IdM or AD shouldn't make a difference here. Did you change /etc/pam.d/smartcart-auth according to comment #8 (similar changes are needed on RHEL7 as well)? Please send the full SSSD logs, especially sssd_pam.log, with debug_level=10 and /var/log/secure. Feel free to send them to me directly if you do not want to share them on the list. bye, Sumit > > Here is my error log from /var/log/sssd/p11_child.log > (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x0400): > p11_child started. > (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x2000): > Running in [pre-auth] mode. > (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x2000): > Running with effective IDs: [0][0]. > (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] [main] (0x2000): > Running with real IDs [0][0]. > (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893]]]] > [parse_cert_verify_opts] (0x4000): Found 'no_ocsp' option, disabling OCSP. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Default Module List: > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > common name: [NSS Internal PKCS #11 Module]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > dll name: [(null)]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > common name: [CoolKey PKCS #11 Module]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > dll name: [libcoolkeypk11.so]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Dead Module List: > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): DB > Module List: > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > common name: [NSS Internal Module]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > dll name: [(null)]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > common name: [Policy File]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > dll name: [(null)]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Description [NSS User Private Key and Certificate Services Mozilla > Foundation ] Manufacturer [Mozilla Foundation ] flags [1]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Description [NSS Internal Cryptographic Services Mozilla Foundation > ] Manufacturer [Mozilla Foundation ] flags [1]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Description [SCM SCR 3310 00 00 Unknown ] > Manufacturer [Unknown ] flags [7]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Found [SMITH.RYAN.123456] in slot [SCM SCR 3310 00 00][1] of module [2]. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Token is NOT friendly. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Trying to switch to friendly to read certificate. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Login required. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x0020): > Login required but no pin available, continue. > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > found cert[SMITH.RYAN.123456:PIV ID > Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > found cert[SMITH.RYAN.123456:PIV Email Signature > Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > found cert[SMITH.RYAN.123456:PIV Email Encryption > Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > Filtered certificates: > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > found cert[SMITH.RYAN.123456:PIV ID > Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > found cert[SMITH.RYAN.123456:PIV Email Signature > Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME] > (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893]]]] [do_work] (0x4000): > More than one certificate found, using just the first one. > > > On Fri, Apr 7, 2017 at 4:35 AM, Sumit Bose wrote: > > > On Thu, Apr 06, 2017 at 06:36:43PM +0000, spammewoods at cox.net wrote: > > > I have created a two way trust between my IDM server and Active > > > Directory. > > > I have been able to successful get RHEL 7.3 IDM server and RHEL 7.3 > > > IDM > > > clients to allow Active Directory login using CAC smart cards into > > > Gnome. > > > I'm using SSSD for the smart card login process instead of > > > authconfig and > > > pkcs11. I'm currently trying to get the same thing working for > > > RHEL 6.9, > > > but I have not been able to get it to work. The latest version of > > > SSSD on > > > RHEL 6.9 is 1.13.3 and from my understanding I need to have at least > > > 1.14.0 > > > for SSSD to handle AD smart card logins. So, I have tried to > > > configure > > > > The Smartcard authentication feature was backported to RHEL-6.9. > > > > Please note that the GDM Smartcard feature must be configured > > differently in RHEL6 then in RHEL7, details for RHEL-6.9 can e.g. found > > in https://bugzilla.redhat.com/show_bug.cgi?id=1300421#c13 > > > > HTH > > > > bye, > > Sumit > > > > > pam_pkcs11.conf file to use the pwent mapper to link the Common Name > > > (CN) to > > > the Active Directory User account. I have created an User ID > > > Override for > > > the AD user and added CN name from the Certificate on the smart > > > card into > > > the GECOS field. I also have added all three certificates from the > > > CAC > > > smart card into the User ID Override. > > > > > > When I try and log in, I get this error message in /var/log/secure: > > > Apr 6 13:21:57 site-lws05 pam: gdm-smartcard: > > > pam_pkcs11(gdm-smartcard:auth): pam_get_pwd() failed: Conversation > > > error > > > Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: > > > pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #1 > > > Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: > > > pam_pkcs11(gdm-smartcard:auth): find_user() failed: on cert #2 > > > Apr 6 13:22:17 site-lws05 pam: gdm-smartcard: > > > pam_pkcs11(gdm-smartcard:auth): no valid certificate which meets all > > > requirements found > > > > > > Here is the some details: > > > IDM Domain: idm.domain.local > > > Windows Domain: domain.local > > > RHEL 7.3 IDM Server: site-idm01.idm.domain.local > > > RHEL 6.9 IDM Client : site-lws05.idm.domain.local > > > > > > When I run the getent command on local accounts and IDM accounts I > > > get user > > > details, but when I run the command on AD accounts it doesn't find > > > them. > > > So, I'm wondering if that's why its not finding the CN name in the > > > GECOS > > > field. I'm trying to avoid using the cn_map on the clients, > > > because we > > > have a large amount of users and thats alot of extra work to manage > > > that > > > file. That's why I wanted to use the pwent mapper. > > > Here is my SSSD config file from the RHEL 6.9 client: > > > [domain/idm.domain.local] > > > override_shell = /bin/bash > > > debug_level = 9 > > > cache_credentials = True > > > krb5_store_password_if_offline = True > > > ipa_domain = idm.domain.local > > > id_provider = ipa > > > auth_provider = ipa > > > access_provider = ipa > > > ipa_hostname = site-lws05.idm.domain.local > > > chpass_provider = ipa > > > ipa_server = _srv_, site-idm01.idm.domain.local > > > ldap_tls_cacert = /etc/ipa/ca.crt > > > [sssd] > > > debug_level = 9 > > > services = nss, sudo, pam, ssh, ifp > > > domains = idm.domain.local > > > certificate_verification = no_ocsp > > > ldap_user_certificate = userCertificate;binary > > > [nss] > > > debug_level = 9 > > > homedir_substring = /home > > > [pam] > > > debug_level = 9 > > > pam_cert_auth = True > > > [sudo] > > > debug_level = 9 > > > [autofs] > > > debug_level = 9 > > > [ssh] > > > debug_level = 9 > > > [pac] > > > debug_level = 9 > > > [ifp] > > > debug_level = 9 > > > > > > Here is my nssswitch file from the RHEL 6.9 client: > > > # /etc/nsswitch.conf > > > # > > > # An example Name Service Switch config file. This file should be > > > # sorted with the most-used services at the beginning. > > > # > > > # The entry '[NOTFOUND=return]' means that the search for an > > > # entry should stop if the search in the previous entry turned > > > # up nothing. Note that if the search failed due to some other reason > > > # (like no NIS server responding) then the search continues with the > > > # next entry. > > > # > > > # Valid entries include: > > > # > > > # nisplus Use NIS+ (NIS version 3) > > > # nis Use NIS (NIS version 2), also called > > > YP > > > # dns Use DNS (Domain Name Service) > > > # files Use the local files > > > # db Use the local database (.db) files > > > # compat Use NIS on compat mode > > > # hesiod Use Hesiod for user lookups > > > # [NOTFOUND=return] Stop searching if not found so far > > > # > > > # To use db, put the "db" in front of "files" for entries you want > > > to be > > > # looked up first in the databases > > > # > > > # Example: > > > #passwd: db files nisplus nis > > > #shadow: db files nisplus nis > > > #group: db files nisplus nis > > > passwd: files sss > > > shadow: files sss > > > group: files sss > > > #hosts: db files nisplus nis dns > > > hosts: files dns > > > # Example - obey only what nisplus tells us... > > > #services: nisplus [NOTFOUND=return] files > > > #networks: nisplus [NOTFOUND=return] files > > > #protocols: nisplus [NOTFOUND=return] files > > > #rpc: nisplus [NOTFOUND=return] files > > > #ethers: nisplus [NOTFOUND=return] files > > > #netmasks: nisplus [NOTFOUND=return] files > > > bootparams: nisplus [NOTFOUND=return] files > > > ethers: files > > > netmasks: files > > > networks: files > > > protocols: files > > > rpc: files > > > services: files sss > > > netgroup: files sss > > > publickey: nisplus > > > automount: files sss > > > aliases: files nisplus > > > sudoers: files sss > > > > > > Here is my system-auth from the RHEL 6.9 client: > > > #%PAM-1.0 > > > # This file is auto-generated. > > > # User changes will be destroyed the next time authconfig is run. > > > auth required pam_env.so > > > auth [success=1 default=ignore] pam_succeed_if.so service > > > notin > > > login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet > > > use_uid > > > auth [success=done authinfo_unavail=ignore ignore=ignore > > > default=die] > > > pam_pkcs11.so card_only > > > auth sufficient pam_fprintd.so > > > auth sufficient pam_unix.so nullok try_first_pass > > > auth requisite pam_succeed_if.so uid >= 500 quiet > > > auth sufficient pam_sss.so use_first_pass > > > auth required pam_deny.so > > > account required pam_unix.so > > > account sufficient pam_localuser.so > > > account sufficient pam_succeed_if.so uid < 500 quiet > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > > account required pam_permit.so > > > password requisite pam_cracklib.so try_first_pass retry=3 > > > type= > > > password sufficient pam_unix.so sha512 shadow nullok > > > try_first_pass > > > use_authtok > > > password sufficient pam_sss.so use_authtok > > > password required pam_deny.so > > > session optional pam_keyinit.so revoke > > > session required pam_limits.so > > > session optional pam_oddjob_mkhomedir.so umask=0077 > > > session [success=1 default=ignore] pam_succeed_if.so service in > > > crond > > > quiet use_uid > > > session required pam_unix.so > > > session optional pam_sss.so > > > > > > Here is my password-auth from the RHEL 6.9 client: > > > #%PAM-1.0 > > > # This file is auto-generated. > > > # User changes will be destroyed the next time authconfig is run. > > > auth required pam_env.so > > > auth sufficient pam_unix.so nullok try_first_pass > > > auth requisite pam_succeed_if.so uid >= 500 quiet > > > auth sufficient pam_sss.so use_first_pass > > > auth required pam_deny.so > > > account required pam_unix.so > > > account sufficient pam_localuser.so > > > account sufficient pam_succeed_if.so uid < 500 quiet > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > > account required pam_permit.so > > > password requisite pam_cracklib.so try_first_pass retry=3 > > > type= > > > password sufficient pam_unix.so sha512 shadow nullok > > > try_first_pass > > > use_authtok > > > password sufficient pam_sss.so use_authtok > > > password required pam_deny.so > > > session optional pam_keyinit.so revoke > > > session required pam_limits.so > > > session optional pam_oddjob_mkhomedir.so umask=0077 > > > session [success=1 default=ignore] pam_succeed_if.so service in > > > crond > > > quiet use_uid > > > session required pam_unix.so > > > session optional pam_sss.so > > > > > > Here is my smartcard-auth from the RHEL 6.9 client: > > > #%PAM-1.0 > > > # This file is auto-generated. > > > # User changes will be destroyed the next time authconfig is run. > > > auth required pam_env.so > > > auth [success=done ignore=ignore default=die] pam_pkcs11.so > > > wait_for_card card_only > > > auth required pam_deny.so > > > account required pam_unix.so > > > account sufficient pam_localuser.so > > > account sufficient pam_succeed_if.so uid < 500 quiet > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > > account required pam_permit.so > > > password required pam_pkcs11.so > > > session optional pam_keyinit.so revoke > > > session required pam_limits.so > > > session optional pam_oddjob_mkhomedir.so umask=0077 > > > session [success=1 default=ignore] pam_succeed_if.so service in > > > crond > > > quiet use_uid > > > session required pam_unix.so > > > session optional pam_sss.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 > > > > -- > > 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 tymrehm at gmail.com Wed Apr 12 02:50:34 2017 From: tymrehm at gmail.com (Tym Rehm) Date: Tue, 11 Apr 2017 22:50:34 -0400 Subject: [Freeipa-users] SSH access to only specific hosts useding ssh keys In-Reply-To: <20170410061706.5l3jixg5kdyqoolf@hendrix> References: <20170410061706.5l3jixg5kdyqoolf@hendrix> Message-ID: So I want a user "bob" to ssh into server1 as the username of "support" with support at server1, but not let Bob ssh into support at server2. I have Bob's ssh public key added to the support user. I can block Bob from server1 or server2 with HBAC, but I have to add support to both servers and since Bob's keys are added to Support. The support account is able to ssh into both servers. I've looked into ID view, but I'm having troubles find a good document on how to setup ID views. On Mon, Apr 10, 2017 at 2:17 AM, Jakub Hrozek wrote: > On Mon, Apr 10, 2017 at 12:04:58AM -0400, Tym Rehm wrote: > > Hey all, New user here. > > > > I have a user "user1" that I want to allow a couple of different users > > "userX and userY" to be allowed to ssh into "server1" and "server2", but > > not both servers using ssh-keys. > > > > So as an example. UserX will ssh user1 at server2 with ssh-key, but I don't > > want userY to be able to successfully run the same command. > > > > I currently have userX and userY's public ssh-key attached to user1 and I > > have created a HBAC rule to allow user1 to connect with ssh on both > server1 > > and server2. This is allowing user1 to connect to both servers fine, > > without a password. It also is allowing users (X & Y) to ssh > user1 at server1 > > and user1 at server2. > > > > How can stop that to restrict userX to be able to ssh as user1 on > server1, > > but not server2? > > > > Do I need to do something with the keytabs or add the ssh-keys for userX > to > > the server1 host only? > > I'm honestly not sure if I understand the problem well, but would it be > helpful to add SSH keys to an ID view that is attached to one of the > servers only? > > -- > 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 > -- -- Do not meddle in the affairs of dragons cause you are crunchy and good with ketchup. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Apr 12 07:20:53 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 12 Apr 2017 09:20:53 +0200 Subject: [Freeipa-users] SSH access to only specific hosts useding ssh keys In-Reply-To: References: <20170410061706.5l3jixg5kdyqoolf@hendrix> Message-ID: <20170412072053.427sfl2ro2agv2a2@hendrix> On Tue, Apr 11, 2017 at 10:50:34PM -0400, Tym Rehm wrote: > So I want a user "bob" to ssh into server1 as the username of "support" > with support at server1, but not let Bob ssh into support at server2. I have > Bob's ssh public key added to the support user. I can block Bob from > server1 or server2 with HBAC, but I have to add support to both servers and > since Bob's keys are added to Support. The support account is able to ssh > into both servers. Yeah, I think id views could help here, but I haven't tested it myself. > > I've looked into ID view, but I'm having troubles find a good document on > how to setup ID views. Does this help? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/id-views.html From christoph.kaminski at biotronik.com Wed Apr 12 07:30:38 2017 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Wed, 12 Apr 2017 09:30:38 +0200 Subject: [Freeipa-users] ldap.conf Message-ID: Hi are the files /etc/ldap.conf and /etc/openldap/ldap.conf for ipa client and/or server systeme necessary? What is the function of them? Greetz Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.kaminski at biotronik.com Wed Apr 12 07:34:59 2017 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Wed, 12 Apr 2017 09:34:59 +0200 Subject: [Freeipa-users] ldap.conf Message-ID: Hi is this ok as config for sssd on centos 7 AND 6? [domain/hso] cache_credentials = True krb5_store_password_if_offline = True id_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh, sudo, autofs config_file_version = 2 domains = hso [nss] [pam] [sudo] [autofs] [ssh] I mean it works but would I get any problems with it? Greetz Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.kaminski at biotronik.com Wed Apr 12 07:35:55 2017 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Wed, 12 Apr 2017 09:35:55 +0200 Subject: [Freeipa-users] minimal sssd config Message-ID: Hi is this ok as config for sssd on centos 7 AND 6? [domain/hso] cache_credentials = True krb5_store_password_if_offline = True id_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh, sudo, autofs config_file_version = 2 domains = hso [nss] [pam] [sudo] [autofs] [ssh] I mean it works but would I get any problems with it? Greetz Christoph Kaminski -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Apr 12 07:47:06 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 12 Apr 2017 09:47:06 +0200 Subject: [Freeipa-users] ldap.conf In-Reply-To: References: Message-ID: <20170412074706.2rseicjvwu5qogin@hendrix> On Wed, Apr 12, 2017 at 09:34:59AM +0200, Christoph Kaminski wrote: > Hi > > is this ok as config for sssd on centos 7 AND 6? > > [domain/hso] > cache_credentials = True > krb5_store_password_if_offline = True > id_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt You can drop this line as well, it's the default for the AD provider. > > [sssd] > services = nss, pam, ssh, sudo, autofs > config_file_version = 2 > domains = hso > > [nss] > > [pam] > > [sudo] > > [autofs] > > [ssh] > > I mean it works but would I get any problems with it? No, the configs are supposed to be minimal. You can even drop the empty service sections like [nss]. From jhrozek at redhat.com Wed Apr 12 07:48:15 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 12 Apr 2017 09:48:15 +0200 Subject: [Freeipa-users] ldap.conf In-Reply-To: References: Message-ID: <20170412074815.67rpo3v44hbhocmn@hendrix> On Wed, Apr 12, 2017 at 09:30:38AM +0200, Christoph Kaminski wrote: > Hi > > are the files /etc/ldap.conf and /etc/openldap/ldap.conf for ipa client > and/or server systeme necessary? What is the function of them? They configure the openldap library. If you have an application (like ldapsearch) that links against libldap, it reads the config from these files. That's the same as libkrb5 and /etc/krb5.conf btw. From jhrozek at redhat.com Wed Apr 12 07:50:22 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 12 Apr 2017 09:50:22 +0200 Subject: [Freeipa-users] ldap.conf In-Reply-To: <20170412074706.2rseicjvwu5qogin@hendrix> References: <20170412074706.2rseicjvwu5qogin@hendrix> Message-ID: <20170412075022.ctbludgvmwa2pzek@hendrix> On Wed, Apr 12, 2017 at 09:47:06AM +0200, Jakub Hrozek wrote: > You can drop this line as well, it's the default for the AD provider. s/AD/IPA/ From ronaldw at ronzo.at Wed Apr 12 08:56:26 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Wed, 12 Apr 2017 10:56:26 +0200 Subject: [Freeipa-users] Problem automounting home shares Message-ID: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> Hi, I am trying to automount user home shares from an NFS server. Up to now, without success. Some details regarding my setup: I have a CentOS 7.3 machine acting as an NFS server. It is a host within my IPA domain and enrolled as an IPA client. [root at ipanfs ~]# cat /etc/exports /homeshare *(rw,sec=krb5:krb5i:krb5p) I followed this guide https://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/ I defined a automount location called ipauserhome. In this location I have a map called auto.home with this content: * -fstype=nfs4,rw,sec=krb5 ipanfs.linux.oebb.at:/homeshare/& On an ipa client I just did "ipa-client-automount --location=ipauserhome" and "authconfig --enablemkhomedir --update". When I login on the ipa client I get the error message "Could not chdir to home directory [...] No such file or directory.". I see that home is mounted on the client auto.home on /home type autofs (rw,relatime,fd=12,pgrp=1079,timeout=300,minproto=5,maxproto=5,indirect) [root at testclient ~]# ls -alh /home total 4,0K drwxr-xr-x. 2 root root 0 12. Apr 10:22 . dr-xr-xr-x. 17 root root 4,0K 11. Apr 17:52 .. but for some reason it works not as expected. SELinux is set to permissive on both NFS server and the ipa client. Nevertheless, I get a suspicious message in /var/log/messages: Apr 12 10:22:48 testclient dbus[804]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Apr 12 10:22:48 testclient dbus-daemon: dbus[804]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /. For complete SELinux messages. run sealert -l 76dd44bd-9ba6-4bf3-ba75-72834533cb0e Apr 12 10:22:49 testclient python: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that mkhomedir should be allowed write access on the directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012# semodule -i my-mkhomedir.pp#012 Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /. For complete SELinux messages. run sealert -l 76dd44bd-9ba6-4bf3-ba75-72834533cb0e Apr 12 10:22:49 testclient python: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that mkhomedir should be allowed write access on the directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012# semodule -i my-mkhomedir.pp#012 Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /. For complete SELinux messages. run sealert -l 76dd44bd-9ba6-4bf3-ba75-72834533cb0e Apr 12 10:22:49 testclient python: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that mkhomedir should be allowed write access on the directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012# semodule -i my-mkhomedir.pp#012 Apr 12 10:23:51 testclient automount[1079]: st_expire: state 1 path /home Apr 12 10:23:51 testclient automount[1079]: expire_proc: exp_proc = 139761696524032 path /home Apr 12 10:23:51 testclient automount[1079]: expire_cleanup: got thid 139761696524032 path /home stat 0 Apr 12 10:23:51 testclient automount[1079]: expire_cleanup: sigchld: exp 139761696524032 finished, switching from 2 to 1 Apr 12 10:23:51 testclient automount[1079]: st_ready: st_ready(): state = 2 path /home Apr 12 10:25:06 testclient automount[1079]: st_expire: state 1 path /home Where to look next? Regards, Ronald From bpk678 at gmail.com Wed Apr 12 12:26:48 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Wed, 12 Apr 2017 08:26:48 -0400 Subject: [Freeipa-users] bind-dyndb-ldap replication errors Message-ID: <04d12752-139c-3ed6-a65e-837e6c06b329@gmail.com> list members, i am using bind-dyndb-ldap without freeipa, and i consistently get the below errors in my logs: update_zone (syncrepl) failed for master zone DN 'idnsName=24.168.192.in-addr.arpa.,cn=dns,ou=Daemons,dc=bpk2,dc=com'. Zones can be outdated, run `rndc reload`: unexpected error the zone that has issue varies, but it is always a zone that allows dynamic updates. it seems that some replication event fails and a manual resync of things has to be performed. any ideas what might be going on? fedora 24, with nearly all recent updates bind-9.10.4-3.P6.fc24.x86_64 bind-dyndb-ldap-10.1-1.fc24.x86_64 openldap-2.4.44-1.fc24.x86_64 i have multi master replication configured between 2 masters, and no other replication events seem to fail. i am not sure where to look for issues. named.conf: dynamic-db "bpk2.com" { library "ldap.so"; arg "uri ldap://192.168.88.1"; arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com"; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_realm BPK2.COM"; arg "krb5_keytab FILE:/etc/named.keytab"; arg "krb5_principal DNS/server1.bpk2.com"; arg "ldap_hostname server1.bpk2.com"; arg "fake_mname dns.bpk2.com."; arg "dyn_update yes"; arg "connections 2"; }; zone config: dn: idnsName=24.168.192.in-addr.arpa.,cn=dns,ou=Daemons,dc=bpk2,dc=com dnsttl: 3600 idnsallowdynupdate: TRUE idnsallowquery: any; idnsallowsyncptr: TRUE idnsname: 24.168.192.in-addr.arpa. idnssoaexpire: 604800 idnssoaminimum: 86400 idnssoamname: dns.bpk2.com. idnssoarefresh: 10800 idnssoaretry: 900 idnssoarname: root.bpk2.com. idnssoaserial: 1491999811 idnsupdatepolicy: grant dhcp wildcard * any; idnszoneactive: TRUE nsrecord: dns.bpk2.com. objectclass: top objectclass: idnsZone objectclass: idnsRecord any help would be appreciated. thanks, brendan From jameslast29 at gmail.com Wed Apr 12 12:26:48 2017 From: jameslast29 at gmail.com (Johan Vermeulen) Date: Wed, 12 Apr 2017 14:26:48 +0200 Subject: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts In-Reply-To: References: <28b2458f-cdd3-0993-dc7c-c37362d68547@redhat.com> Message-ID: Hello Rob, doing it this way indeed works. Thanks for helping me out. Greetings, J. 2017-04-11 16:54 GMT+02:00 Rob Crittenden : > Johan Vermeulen wrote: > > Rob, > > > > thanks for helping me out. > > I support some 80 laptop users at the moment, all running Centos7. > > The users are now in ldap, the laptops ( hosts) are not. I'm testing the > > ability to add the laptops as hosts. > > > > Under "identity - hosts", when selecting a host, I go to "actions". The > > only way I see to disable ( block) a host, what I would do when > > a laptop is stolen for instance, is unprovision. > > I then tried to re-provision it, I see no "provision" option. I tried to > > "rebuild auto membership" and " new certificate" but that doesn't seem > > to work. > > I hope I'm making sense. > > In the case of a lost or stolen laptop then disabling the host seems > like a good mechanism. It will revoke and certificates issued for the > host and invalidate its keytab. > > Provisioning happens when ipa-client-install is run on the host [1]. > There is no facility for remote provisioning. > > rob > > [1] technically a host is provisioned when it has a keytab but this > doesn't configure that host to actually use it and you potentially need > to safely transfer this keytab to the host. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From email at jacobdevans.com Wed Apr 12 13:00:01 2017 From: email at jacobdevans.com (Jake) Date: Wed, 12 Apr 2017 09:00:01 -0400 (EDT) Subject: [Freeipa-users] 'NoneType' object is not iterable when removing broken ipa-server replica In-Reply-To: References: <656355607.32182.1491920827896@jersey.jacobdevans.com> Message-ID: <436153625.33867.1492002001111@vegas.jacobdevans.com> Rob, IPA Version: rpm -qa ipa-server ipa-server-4.4.0-14.el7.centos.1.1.x86_64 Contents of httpd/error_log [Wed Apr 12 08:53:21.442283 2017] [:error] [pid 19175] ipa: ERROR: non-public: TypeError: 'NoneType' object is not iterable [Wed Apr 12 08:53:21.442318 2017] [:error] [pid 19175] Traceback (most recent call last): [Wed Apr 12 08:53:21.442321 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in wsgi_execute [Wed Apr 12 08:53:21.442323 2017] [:error] [pid 19175] result = command(*args, **options) [Wed Apr 12 08:53:21.442325 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Wed Apr 12 08:53:21.442327 2017] [:error] [pid 19175] return self.__do_call(*args, **options) [Wed Apr 12 08:53:21.442329 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Wed Apr 12 08:53:21.442331 2017] [:error] [pid 19175] ret = self.run(*args, **options) [Wed Apr 12 08:53:21.442332 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Wed Apr 12 08:53:21.442334 2017] [:error] [pid 19175] return self.execute(*args, **options) [Wed Apr 12 08:53:21.442335 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1571, in execute [Wed Apr 12 08:53:21.442337 2017] [:error] [pid 19175] delete_entry(pkey) [Wed Apr 12 08:53:21.442339 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1524, in delete_entry [Wed Apr 12 08:53:21.442340 2017] [:error] [pid 19175] dn = callback(self, ldap, dn, *nkeys, **options) [Wed Apr 12 08:53:21.442342 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/server.py", line 692, in pre_callback [Wed Apr 12 08:53:21.442344 2017] [:error] [pid 19175] self.api) [Wed Apr 12 08:53:21.442345 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipaserver/topology.py", line 136, in __init__ [Wed Apr 12 08:53:21.442357 2017] [:error] [pid 19175] self.graphs = _create_topology_graphs(self.api) [Wed Apr 12 08:53:21.442359 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipaserver/topology.py", line 100, in _create_topology_graphs [Wed Apr 12 08:53:21.442360 2017] [:error] [pid 19175] suffix_to_masters = map_masters_to_suffixes(masters) [Wed Apr 12 08:53:21.442362 2017] [:error] [pid 19175] File "/usr/lib/python2.7/site-packages/ipaserver/topology.py", line 83, in map_masters_to_suffixes [Wed Apr 12 08:53:21.442363 2017] [:error] [pid 19175] for suffix_name in managed_suffixes: [Wed Apr 12 08:53:21.442365 2017] [:error] [pid 19175] TypeError: 'NoneType' object is not iterable [Wed Apr 12 08:53:23.078960 2017] [:error] [pid 19176] ipa: ERROR: non-public: TypeError: 'NoneType' object is not iterable [Wed Apr 12 08:53:23.078993 2017] [:error] [pid 19176] Traceback (most recent call last): [Wed Apr 12 08:53:23.078997 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in wsgi_execute [Wed Apr 12 08:53:23.079000 2017] [:error] [pid 19176] result = command(*args, **options) [Wed Apr 12 08:53:23.079003 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Wed Apr 12 08:53:23.079006 2017] [:error] [pid 19176] return self.__do_call(*args, **options) [Wed Apr 12 08:53:23.079008 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Wed Apr 12 08:53:23.079011 2017] [:error] [pid 19176] ret = self.run(*args, **options) [Wed Apr 12 08:53:23.079013 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Wed Apr 12 08:53:23.079016 2017] [:error] [pid 19176] return self.execute(*args, **options) [Wed Apr 12 08:53:23.079019 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1571, in execute [Wed Apr 12 08:53:23.079021 2017] [:error] [pid 19176] delete_entry(pkey) [Wed Apr 12 08:53:23.079024 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1524, in delete_entry [Wed Apr 12 08:53:23.079026 2017] [:error] [pid 19176] dn = callback(self, ldap, dn, *nkeys, **options) [Wed Apr 12 08:53:23.079029 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/server.py", line 692, in pre_callback [Wed Apr 12 08:53:23.079032 2017] [:error] [pid 19176] self.api) [Wed Apr 12 08:53:23.079034 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipaserver/topology.py", line 136, in __init__ [Wed Apr 12 08:53:23.079037 2017] [:error] [pid 19176] self.graphs = _create_topology_graphs(self.api) [Wed Apr 12 08:53:23.079040 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipaserver/topology.py", line 100, in _create_topology_graphs [Wed Apr 12 08:53:23.079043 2017] [:error] [pid 19176] suffix_to_masters = map_masters_to_suffixes(masters) [Wed Apr 12 08:53:23.079045 2017] [:error] [pid 19176] File "/usr/lib/python2.7/site-packages/ipaserver/topology.py", line 83, in map_masters_to_suffixes [Wed Apr 12 08:53:23.079048 2017] [:error] [pid 19176] for suffix_name in managed_suffixes: [Wed Apr 12 08:53:23.079050 2017] [:error] [pid 19176] TypeError: 'NoneType' object is not iterable Thanks, ----- Original Message ----- From: "Rob Crittenden" To: "Jake" , "freeipa-users" Sent: Tuesday, April 11, 2017 5:27:51 PM Subject: Re: [Freeipa-users] 'NoneType' object is not iterable when removing broken ipa-server replica Jake wrote: > Help! > I'm having issues removing a bad replica. > > Everytime I run: > > ipa-replica-manage del ipa01.example.com > or > ipa-replica-manage del --force ipa01.example.com > > I get an error: 'NoneType' object is not iterable > > if I try to remove it from the web interface: > > > IPA Error 903: InternalError > > an internal error has occurred I wonder if a traceback is logged in /var/log/httpd/error_log > They're removed from hosts, but I cannot get them our of the existing > topology Not sure what you mean here. > > Is there a "purge this host" button that removes it, ignoring errors if > it's already missing. --force ignore some errors but not unknown errors like this. What version of IPA is this? rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project From solerm at unicc.org Wed Apr 12 15:12:43 2017 From: solerm at unicc.org (SOLER SANGUESA Miguel) Date: Wed, 12 Apr 2017 15:12:43 +0000 Subject: [Freeipa-users] ipa-adtrust-install failing at samba restart Message-ID: Hello, I have the same error, can you explain how did you fixed, please? Thanks & Regards. ______________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldw at ronzo.at Wed Apr 12 15:16:37 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Wed, 12 Apr 2017 17:16:37 +0200 Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> Message-ID: On 2017-04-12 14:55, Jason B. Nance wrote: > [...] > You cannot use indirect mounting and enablemkhomedir at the same time. Indirect mounts require that the directory you are attempting to mount already exists on the NFS server and that you let autofs fully manage the "parent" directory on the client machine. In this case, no one other than autofs can create directories in the top-level of /home on your clients (/home/ is a different story). > > So you either need to pre-create the home directories on your NFS server (including ownership, permissions, and any "skel" stuff you want in there like a default .bashrc) or you need to direct mount /home altogether and lose the benefits of indirect mounting (which may not matter to you). > [...] So this means I can either use /home mounted as NFS share conventionally (without autofs) in combination with mkhomedir or use autofs magic with pre-created directories. As my users come from AD I do not even know which directories would have to be created in advance. So I will have to go for option 1. From jason at tresgeek.net Wed Apr 12 15:21:46 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 12 Apr 2017 10:21:46 -0500 (CDT) Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> Message-ID: <1407782393.1609.1492010506460.JavaMail.zimbra@tresgeek.net> >> You cannot use indirect mounting and enablemkhomedir at the same time. Indirect >> mounts require that the directory you are attempting to mount already exists on >> the NFS server and that you let autofs fully manage the "parent" directory on >> the client machine. In this case, no one other than autofs can create >> directories in the top-level of /home on your clients (/home/ is a >> different story). >> >> So you either need to pre-create the home directories on your NFS server >> (including ownership, permissions, and any "skel" stuff you want in there like >> a default .bashrc) or you need to direct mount /home altogether and lose the >> benefits of indirect mounting (which may not matter to you). >> [...] > > So this means I can either use /home mounted as NFS share conventionally > (without autofs) in combination with mkhomedir or use autofs magic with > pre-created directories. You can still use autofs and mkhomdir, just use a direct mount for /home instead of indirect mounts. In other words, mount "/home" entirely vs. "/home/" individually. Regards, j From jason at tresgeek.net Wed Apr 12 12:55:32 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 12 Apr 2017 07:55:32 -0500 (CDT) Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> Message-ID: <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> Hi Ronald, > Some details regarding my setup: I have a CentOS 7.3 machine acting as > an NFS server. It is a host within my IPA domain and enrolled as an IPA > client. > > [root at ipanfs ~]# cat /etc/exports > > /homeshare *(rw,sec=krb5:krb5i:krb5p) This isn't related to your issue but you have your exports setup as if you're using NFSv3. They will still work, of course, but you aren't taking advantage of the pseudo filesystem. For example, you could have something such as: /etc/exports: /export *(rw,sync,crossmnt,no_subtree_check,sec=krb5:krb5i:krb5p,fsid=0) Then: mkdir -p /export/homeshare mount -o bind /homeshare /export/homeshare (or even /home if you have autofs disabled on your NFS server) It may be worth some Googling to see if you care about the benefits, but again, it isn't why you are having issues. > I defined a automount location called ipauserhome. In this location I > have a map called auto.home with this content: > > * -fstype=nfs4,rw,sec=krb5 ipanfs.linux.oebb.at:/homeshare/& > > On an ipa client I just did "ipa-client-automount > --location=ipauserhome" and "authconfig --enablemkhomedir --update". You cannot use indirect mounting and enablemkhomedir at the same time. Indirect mounts require that the directory you are attempting to mount already exists on the NFS server and that you let autofs fully manage the "parent" directory on the client machine. In this case, no one other than autofs can create directories in the top-level of /home on your clients (/home/ is a different story). So you either need to pre-create the home directories on your NFS server (including ownership, permissions, and any "skel" stuff you want in there like a default .bashrc) or you need to direct mount /home altogether and lose the benefits of indirect mounting (which may not matter to you). > but for some reason it works not as expected. SELinux is set to > permissive on both NFS server and the ipa client. Nevertheless, I get a > suspicious message in /var/log/messages: In permissive mode SELinux messages are still displayed in the logs but not enforced. This allows you to troubleshoot SELinux-related issues. To use NFS home directories with NFS you need to run the following on the client systems: setsebool -P use_nfs_home_dirs on Regards, j From michael.rainey.ctr at nrlssc.navy.mil Wed Apr 12 20:51:18 2017 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Wed, 12 Apr 2017 15:51:18 -0500 Subject: [Freeipa-users] User policies Message-ID: Greetings, I have a question about user policies which I hope some can provide some guidance. I have a small set of users who are tightly restricted on our network. They are only allowed to log into certain machines, and mount specific filesystems located on other machines. At the moment we have these systems locked down through a combination of local system accounts, and static mounts in fstab. I have setup a few test accounts, created an HBAC Rule, and a custom automount map for each account. Is this the best way to achieve this? Is there a way to create a policy to restrict users to specific filesystems? In my ideal world, it would be great to have the restricted user to login, have the restrictions applied, then have a non-restricted user log onto the same machine, and still have access as they would on another machine. So, what are your thoughts/ -- *Michael Rainey* Network Representative -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at ifuzioncorp.com Wed Apr 12 21:06:55 2017 From: jeremy at ifuzioncorp.com (Jeremy Utley) Date: Wed, 12 Apr 2017 16:06:55 -0500 Subject: [Freeipa-users] DM Password Change & Password Storage Message-ID: Hello all! We've got 2 replicated instances of FreeIPA 4.4.0 from the EPEL repository running on fully-updated CentOS 7 instances. We're going thru an audit right now, and I have to provide some proof of certain things related to IPA to our auditors. Unfortunately, the person who originally set these up evidently did not document the Directory Manager password in our docs, so I was forced to reset this password, using the process at: http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html This was successful, and I can now bind to the DS with the new password. I'm now trying to follow the steps at: https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password A few things are rather confusing to me. I've tried Google searching without much luck either. So hopefully you guys can answer a few questions for me. 1) First off, the doc says: 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 So do I even need to perform these steps at all, considering I'm well beyond 3.2.2. We don't have any intention of running ipa-replica-prepare for the forseeable future (we shouldn't ever need to add a third directory server here). 2) The first step (Update LDAP bind password) seems to indicate you're adding the new password in clear-text to the password.conf file - this seems like a major security issue. Am I misunderstanding what is being requested here? The old password is not in this file (All my current files have is lines for "internal" and "replicationdb" 3) The next step regenerates the cacert.p12 file, but seems to do nothing with it, just leaves it sitting in /root - what should be done with this file afterward? Thanks for any help you can give! Jeremy Utley -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikogan at flarecode.com Thu Apr 13 02:52:30 2017 From: ikogan at flarecode.com (Ilya Kogan) Date: Wed, 12 Apr 2017 22:52:30 -0400 Subject: [Freeipa-users] KRA Cannot Authenticate with LDAP After Replication Message-ID: Hi, I?m wondering if anyone might be able to help me figure out why my KRA is failing after a fairly recent installation. It's throwing exceptions about LDAP authentication that look like the following (note, I?ve truncated some of the stacks for brevity: Apr 12 21:14:22 server[7515]: Could not connect to LDAP server host ipa-1.mydomain.com port 636 Error netscape.ldap.LDAPException: error result (49) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:332) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:295) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.DBSubsystem.hasRangeConflict(DBSubsystem.java:475) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.Repository.checkRanges(Repository.java:500) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.KeyRepository.updateKeyStatus(KeyRepository.java:189) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.KeyStatusUpdateTask.run(KeyRepository.java:604) Apr 12 21:14:22 server[7515]: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... Apr 12 21:14:22 server[7515]: Could not connect to LDAP server host ipa-1.mydomain.com port 636 Error netscape.ldap.LDAPException: error result (49) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:332) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:295) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.DBSubsystem.hasRangeConflict(DBSubsystem.java:475) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.Repository.checkRanges(Repository.java:500) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.KeyRepository.updateKeyStatus(KeyRepository.java:193) Apr 12 21:14:22 server[7515]: at com.netscape.cmscore.dbs.KeyStatusUpdateTask.run(KeyRepository.java:604) ... When I restart IPA, I get the following: Apr 12 21:18:34 server[32159]: CA is started. Apr 12 21:18:34 server[32159]: SSLAuthenticatorWithFallback: Creating SSL authenticator with fallback Apr 12 21:18:34 server[32159]: SSLAuthenticatorWithFallback: Setting container Apr 12 21:18:35 server[32159]: SSLAuthenticatorWithFallback: Initializing authenticators Apr 12 21:18:35 server[32159]: SSLAuthenticatorWithFallback: Starting authenticators Apr 12 21:18:35 server[32159]: CMSEngine.initializePasswordStore() begins Apr 12 21:18:35 server[32159]: CMSEngine.initializePasswordStore(): tag=internaldb Apr 12 21:18:35 server[32159]: testLDAPConnection connecting to ipa-1.mydomain.com:636 Apr 12 21:18:35 server[32159]: testLDAPConnection: Invalid Password Apr 12 21:18:36 server[32159]: testLDAPConnection connecting to ipa-1.mydomain.com:636 Apr 12 21:18:36 server[32159]: testLDAPConnection: Invalid Password Apr 12 21:18:36 server[32159]: testLDAPConnection connecting to ipa-1.mydomain.com:636 Apr 12 21:18:36 server[32159]: testLDAPConnection: Invalid Password Apr 12 21:18:36 server[32159]: CMSEngine: init(): password test execution failed: 2 Apr 12 21:18:36 server[32159]: Password test execution failed. Is the database up? Apr 12 21:18:36 server[32159]: Password test execution failed. Is the database up? Apr 12 21:18:36 server[32159]: at com.netscape.cmscore.apps.CMSEngine.initializePasswordStore(CMSEngine.java:469) Apr 12 21:18:36 server[32159]: at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:537) Apr 12 21:18:36 server[32159]: at com.netscape.certsrv.apps.CMS.init(CMS.java:188) Apr 12 21:18:36 server[32159]: at com.netscape.certsrv.apps.CMS.start(CMS.java:1621) Apr 12 21:18:36 server[32159]: at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) Apr 12 21:18:36 server[32159]: at javax.servlet.GenericServlet.init(GenericServlet.java:158) ... If I then try to add or delete a vault, I get the following: Apr 12 22:19:08 server[32159]: SSLAuthenticatorWithFallback: Authenticate with client certificate authentication Apr 12 22:19:08 server[32159]: java.lang.NullPointerException Apr 12 22:19:08 server[32159]: at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:114) Apr 12 22:19:08 server[32159]: at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:86) Apr 12 22:19:08 server[32159]: at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:81) Apr 12 22:19:08 server[32159]: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:37) Apr 12 22:19:08 server[32159]: at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:86) Apr 12 22:19:08 server[32159]: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:47) ... Apr 12 22:19:08 server[32159]: SSLAuthenticatorWithFallback: Result: false I?ve got the following in /var/log/pki/pki-tomcat/kra/debug: [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: Starting request checkRanges [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: Serial numbers left in range: 10000 [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: Last Serial Number: 9990000 [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: Serial Numbers in next range: 10000000 [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: Serial Numbers available: 10010000 [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: Checking for a range conflict [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: In LdapBoundConnFactory::getConn() [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: masterConn is null. [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: makeConnection: errorIfDown true [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: TCP Keep-Alive: true [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: SSL handshake happened [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: Can't create master connection in LdapBoundConnFactory::getConn! Could not connect to LDAP server host ipa-1.mydomain.com port 636 Error netscape.ldap.LDAPException: error result (49) [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: DBSubsystem: hasRangeConflict. Error while checking next range.Could not connect to LDAP server host ipa-1.mydomain.com port 636 Error netscape.ldap.LDAPException: error result (49) [12/Apr/2017:21:14:22][KeyStatusUpdateTask]: request checkRanges done This is IPA 4.4.4-1.fc25, installed fairly recently. I?m not sure if this is relevant, but this was installed as a new master on new infrastructure based on an old Fedora 23, IPA 4.3 master that never had a KRA. I initially replicated to a new Fedora 23 host and upgraded that host to Fedora 25 (it may have still been connected to the 4.3 master during and after the upgrade). ipa-kra-install was then run on that Fedora 25 host which was again replicated to what is now presenting this problem. I believe the KRA started up fine at that point but I didn?t thoroughly test it. I then disconnected the old Fedora 25 host and shut down the old infrastructure. I?m now running on a single master IPA node with this broken KRA problem. Note that everything else about this installation seems to work. I wouldn?t have even really noticed if not for trying to replicate again and failing due to KRA issues. Thanks! ? Ilya Kogan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From tkrizek at redhat.com Thu Apr 13 08:15:43 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Thu, 13 Apr 2017 10:15:43 +0200 Subject: [Freeipa-users] bind-dyndb-ldap replication errors In-Reply-To: <04d12752-139c-3ed6-a65e-837e6c06b329@gmail.com> References: <04d12752-139c-3ed6-a65e-837e6c06b329@gmail.com> Message-ID: <3cc785f1-e685-9b0f-2b02-7ba2a8c36d7e@redhat.com> On 04/12/2017 02:26 PM, Brendan Kearney wrote: > list members, > > i am using bind-dyndb-ldap without freeipa, and i consistently get the > below errors in my logs: > > update_zone (syncrepl) failed for master zone DN > 'idnsName=24.168.192.in-addr.arpa.,cn=dns,ou=Daemons,dc=bpk2,dc=com'. > Zones can be outdated, run `rndc reload`: unexpected error > > the zone that has issue varies, but it is always a zone that allows > dynamic updates. it seems that some replication event fails and a > manual resync of things has to be performed. any ideas what might be > going on? > > fedora 24, with nearly all recent updates > bind-9.10.4-3.P6.fc24.x86_64 > bind-dyndb-ldap-10.1-1.fc24.x86_64 > openldap-2.4.44-1.fc24.x86_64 > > i have multi master replication configured between 2 masters, and no > other replication events seem to fail. i am not sure where to look > for issues. You might be able to track down why does the zone update fail if you run named in the foreground with a higher debug level to see more log messages: $ sudo -u named named -g -d 50 Then you can check what does bind-dyndb-ldap log before you get the mentioned error message. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From solerm at unicc.org Thu Apr 13 09:23:37 2017 From: solerm at unicc.org (SOLER SANGUESA Miguel) Date: Thu, 13 Apr 2017 09:23:37 +0000 Subject: [Freeipa-users] Problem starting smb service after ipa-adtrust-install Message-ID: <6600ccc00574413393e60b40676d16a7@ICCM01.GMS05.unicc.org> Hello I have fixed the problem myself. As it complained about the 2 records on LDAP, I did a bk of LDAP database and I deleted both records. I ran again ipa-adtrust-install and it created just 1 of them. Then I had another error: "Attribute [ipaNTSecurityIdentifier] not found", that is because I didn't put the parameter "--add-sids", so I reran ipa-adtrust-install with the parameter and it worked. Thanks & Regards. ______________________________ From: SOLER SANGUESA Miguel Sent: Tuesday, April 11, 2017 8:51 To: 'freeipa-users at redhat.com' Subject: Problem starting smb service after ipa-adtrust-install hello I'm unable to start smb after executing ipa-adtrust-install. the execution of ipa-adtrust-install is: [root at hostname ~]# ipa-adtrust-install --enable-compat --add-agents -d The log file for this installation can be found in /var/log/ipaserver-install.log ipa : DEBUG /sbin/ipa-adtrust-install was invoked with options: {'enable_compat': True, 'add_agents': True, 'no_msdcs': False, 'rid_base': 1000, 'secondary_rid_base': 100000000, 'netbios_name': None, 'debug': True, 'add_sids': False, 'unattended': False} ipa : DEBUG missing options might be asked for interactively later ipa : DEBUG IPA version 4.4.0-14.el7_3.6 ipa : DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' ipa : DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' ============================================================================== This program will setup components needed to establish trust to AD domains for the IPA Server. This includes: * Configure Samba * Add trust related objects to IPA LDAP server To accept the default shown in brackets, press the Enter key. ipa : DEBUG importing all plugin modules in ipaserver.plugins... ... ipa : DEBUG importing plugin module ipaserver.plugins.hbac ipa : DEBUG ipaserver.plugins.hbac is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.otp ipa : DEBUG ipaserver.plugins.otp is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.pkinit ipa : DEBUG ipaserver.plugins.pkinit is not a valid plugin module ... ipa : DEBUG Starting external process ipa : DEBUG args=klist -V ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=Kerberos 5 version 1.14.1 ipa : DEBUG stderr= ipa : DEBUG importing plugin module ipaserver.plugins.rabase ipa : DEBUG ipaserver.plugins.rabase is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.sudo ipa : DEBUG ipaserver.plugins.sudo is not a valid plugin module ... ipa : DEBUG importing plugin module ipaserver.plugins.virtual ipa : DEBUG ipaserver.plugins.virtual is not a valid plugin module ipa : DEBUG importing plugin module ipaserver.plugins.xmlserver IPA generated smb.conf detected. Overwrite smb.conf? [no]: yes Configuring cross-realm trusts for IPA server requires password for user 'admin'. This user is a regular system account used for IPA server administration. admin password: ipa : DEBUG Starting external process ipa : DEBUG args=kinit admin ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=Password for admin at MY.IPA.SUBDOMAIN: ipa : DEBUG stderr= ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection context.ldap2_48972688 ipa.ipaserver.plugins.user.user_show: DEBUG raw: user_show(u'admin', version=u'2.213') ipa.ipaserver.plugins.user.user_show: DEBUG user_show(u'admin', rights=False, all=False, raw=False, version=u'2.213', no_members=False) ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa.ipaserver.plugins.group.group_show: DEBUG raw: group_show(u'admins', version=u'2.213') ipa.ipaserver.plugins.group.group_show: DEBUG group_show(u'admins', rights=False, all=False, raw=False, version=u'2.213', no_members=False) ipa : DEBUG Searching for objects with missing SID with filter=(&(objectclass=ipaobject)(!(objectclass=mepmanagedentry))(|(objectclass=posixaccount)(objectclass=posixgroup)(objectclass=ipaidobject))(!(ipantsecurityidentifier=*))), base_dn=dc=my,dc=ipa,dc=subdomain WARNING: 12 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]: The following operations may take some minutes to complete. Please wait until the prompt is returned. ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa : DEBUG Configuring CIFS Configuring CIFS ipa : DEBUG [1/22]: stopping smbd [1/22]: stopping smbd ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl is-active smb.service ipa : DEBUG Process finished, return code=3 ipa : DEBUG stdout=failed ipa : DEBUG stderr= ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl stop winbind.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl stop smb.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG duration: 0 seconds ipa : DEBUG [2/22]: creating samba domain object [2/22]: creating samba domain object ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa : DEBUG Samba domain object already exists Samba domain object already exists ipa : DEBUG duration: 0 seconds ipa : DEBUG [3/22]: creating samba config registry [3/22]: creating samba config registry ipa : DEBUG Starting external process ipa : DEBUG args=/usr/bin/net conf import /tmp/tmpTiRBM4 ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG duration: 0 seconds ipa : DEBUG [4/22]: writing samba config file [4/22]: writing samba config file ipa : DEBUG duration: 0 seconds ipa : DEBUG [5/22]: adding cifs Kerberos principal [5/22]: adding cifs Kerberos principal ipa.ipaserver.plugins.service.service_add: DEBUG raw: service_add(u'cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN', version=u'2.213') ipa.ipaserver.plugins.service.service_add: DEBUG service_add(, force=False, all=False, raw=False, version=u'2.213', no_members=False) ipa.ipaserver.plugins.host.host_show: DEBUG raw: host_show(u'hostname.MY.IPA.SUBDOMAIN', version=u'2.213') ipa.ipaserver.plugins.host.host_show: DEBUG host_show(u'hostname.MY.IPA.SUBDOMAIN', rights=False, all=False, raw=False, version=u'2.213', no_members=False) ipa : DEBUG found 1 A records for hostname.MY.IPA.SUBDOMAIN.: XX.XX.XX.XX ipa : DEBUG The DNS response does not contain an answer to the question: hostname.MY.IPA.SUBDOMAIN. IN AAAA ipa : DEBUG Starting external process ipa : DEBUG args=ipa-rmkeytab --principal cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN -k /etc/samba/samba.keytab ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr=Removing principal cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN ipa : DEBUG Removing service credentials cache ipa : DEBUG Ccache path: '/var/run/samba/krb5cc_samba' ipa : DEBUG Starting external process ipa : DEBUG args=/usr/bin/kdestroy -c /var/run/samba/krb5cc_samba ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Starting external process ipa : DEBUG args=ipa-getkeytab --server hostname.MY.IPA.SUBDOMAIN --principal cifs/hostname.MY.IPA.SUBDOMAIN at MY.IPA.SUBDOMAIN -k /etc/samba/samba.keytab ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr=Keytab successfully retrieved and stored in: /etc/samba/samba.keytab ipa : DEBUG duration: 0 seconds ipa : DEBUG [6/22]: adding cifs and host Kerberos principals to the adtrust agents group [6/22]: adding cifs and host Kerberos principals to the adtrust agents group ipa : DEBUG duration: 0 seconds ipa : DEBUG [7/22]: check for cifs services defined on other replicas [7/22]: check for cifs services defined on other replicas ipa : DEBUG duration: 0 seconds ipa : DEBUG [8/22]: adding cifs principal to S4U2Proxy targets [8/22]: adding cifs principal to S4U2Proxy targets ipa : DEBUG cifs principal already targeted, nothing to do. cifs principal already targeted, nothing to do. ipa : DEBUG duration: 0 seconds ipa : DEBUG [9/22]: adding admin(group) SIDs [9/22]: adding admin(group) SIDs ipa : DEBUG Admin SID already set, nothing to do Admin SID already set, nothing to do ipa : DEBUG Admin group SID already set, nothing to do Admin group SID already set, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [10/22]: adding RID bases [10/22]: adding RID bases ipa : DEBUG RID bases already set, nothing to do RID bases already set, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [11/22]: updating Kerberos config [11/22]: updating Kerberos config ipa : DEBUG 'dns_lookup_kdc' already set to 'true', nothing to do. 'dns_lookup_kdc' already set to 'true', nothing to do. ipa : DEBUG duration: 0 seconds ipa : DEBUG [12/22]: activating CLDAP plugin [12/22]: activating CLDAP plugin ipa : DEBUG CLDAP plugin already configured, nothing to do CLDAP plugin already configured, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [13/22]: activating sidgen task [13/22]: activating sidgen task ipa : DEBUG Sidgen task plugin already configured, nothing to do Sidgen task plugin already configured, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [14/22]: configuring smbd to start on boot [14/22]: configuring smbd to start on boot ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl is-enabled smb.service ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout=disabled ipa : DEBUG stderr= ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl disable smb.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG service ADTRUST startup entry already enabled ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl disable smb.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG service EXTID startup entry already enabled ipa : DEBUG duration: 1 seconds ipa : DEBUG [15/22]: adding special DNS service records [15/22]: adding special DNS service records ipa.ipaserver.plugins.dns.dns_is_enabled: DEBUG raw: dns_is_enabled(version=u'2.213') ipa.ipaserver.plugins.dns.dns_is_enabled: DEBUG dns_is_enabled(version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG raw: dnszone_show(u'MY.IPA.SUBDOMAIN', version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG dnszone_show(, rights=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dns_update_system_records: DEBUG raw: dns_update_system_records(version=u'2.213') ipa.ipaserver.plugins.dns.dns_update_system_records: DEBUG dns_update_system_records(dry_run=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.server.server_find: DEBUG raw: server_find(None, version=u'2.213', no_members=False) ipa.ipaserver.plugins.server.server_find: DEBUG server_find(None, all=False, raw=False, version=u'2.213', no_members=False, pkey_only=False) ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG raw: topologysuffix_find(None, all=True, raw=True, version=u'2.213') ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG topologysuffix_find(None, all=True, raw=True, version=u'2.213', pkey_only=False) ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG raw: server_role_find(None, server_server=u'hostname.MY.IPA.SUBDOMAIN', status=u'enabled', version=u'2.213') ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG server_role_find(None, server_server=u'hostname.MY.IPA.SUBDOMAIN', status=u'enabled', all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG raw: server_role_find(None, server_server=u'OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN', status=u'enabled', version=u'2.213') ipa.ipaserver.plugins.serverrole.server_role_find: DEBUG server_role_find(None, server_server=u'OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN', status=u'enabled', all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG raw: dnszone_show(, version=u'2.213') ipa.ipaserver.plugins.dns.dnszone_show: DEBUG dnszone_show(, rights=False, all=False, raw=False, version=u'2.213') ipa : DEBUG found 1 1 records for hostname.MY.IPA.SUBDOMAIN.: XX.XX.XX.XX ipa : DEBUG The DNS response does not contain an answer to the question: hostname.MY.IPA.SUBDOMAIN. IN AAAA ipa : DEBUG found 1 1 records for OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.: YY.YY.YY.YY ipa : DEBUG The DNS response does not contain an answer to the question: OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN. IN AAAA ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , txtrecord=[u'"MY.IPA.SUBDOMAIN"'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , txtrecord=(u'"MY.IPA.SUBDOMAIN"',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos-master._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos-master._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kpasswd._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kpasswd._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kpasswd._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 464 hostname.MY.IPA.SUBDOMAIN.', u'0 100 464 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kpasswd._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 123 hostname.MY.IPA.SUBDOMAIN.', u'0 100 123 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ntp._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 123 hostname.MY.IPA.SUBDOMAIN.', u'0 100 123 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ntp._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , arecord=[u'XX.XX.XX.XX', u'YY.YY.YY.YY'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , arecord=(u'XX.XX.XX.XX', u'YY.YY.YY.YY'), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 389 hostname.MY.IPA.SUBDOMAIN.', u'0 100 389 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_ldap._tcp.dc._msdcs.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG raw: dnsrecord_mod(, , srvrecord=[u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'], setattr=[u'idnsTemplateAttribute;cnamerecord=_kerberos-master._udp.\\{substitutionvariable_ipalocation\\}._locations'], addattr=[u'objectclass=idnsTemplateObject'], version=u'2.213') ipa.ipaserver.plugins.dns.dnsrecord_mod: DEBUG dnsrecord_mod(, , srvrecord=(u'0 100 88 hostname.MY.IPA.SUBDOMAIN.', u'0 100 88 OTHER_IDM_SERVER.MY.IPA.SUBDOMAIN.'), setattr=(u'idnsTemplateAttribute;cnamerecord=_kerberos-master._udp.\\{substitutionvariable_ipalocation\\}._locations',), addattr=(u'objectclass=idnsTemplateObject',), rights=False, structured=False, all=False, raw=False, version=u'2.213') ipa.ipaserver.plugins.server.server_find: DEBUG raw: server_find(None, version=u'2.213', pkey_only=True) ipa.ipaserver.plugins.server.server_find: DEBUG server_find(None, all=False, raw=False, version=u'2.213', no_members=True, pkey_only=True) ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG raw: topologysuffix_find(None, all=True, raw=True, version=u'2.213') ipa.ipaserver.plugins.topology.topologysuffix_find: DEBUG topologysuffix_find(None, all=True, raw=True, version=u'2.213', pkey_only=False) ipa.ipaserver.plugins.location.location_find: DEBUG raw: location_find(None, version=u'2.213') ipa.ipaserver.plugins.location.location_find: DEBUG location_find(None, all=False, raw=False, version=u'2.213', pkey_only=False) ipa : DEBUG duration: 0 seconds ipa : DEBUG [16/22]: enabling trusted domains support for older clients via Schema Compatibility plugin [16/22]: enabling trusted domains support for older clients via Schema Compatibility plugin ipa : DEBUG duration: 0 seconds ipa : DEBUG [17/22]: restarting Directory Server to take MS PAC and LDAP plugins changes into account [17/22]: restarting Directory Server to take MS PAC and LDAP plugins changes into account ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl restart dirsrv at MY-IPA-SUBDOMAIN.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl is-active dirsrv at MY-IPA-SUBDOMAIN.service ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=active ipa : DEBUG stderr= ipa : DEBUG wait_for_open_ports: localhost [389] timeout 300 ipa : DEBUG duration: 5 seconds ipa : DEBUG [18/22]: adding fallback group [18/22]: adding fallback group ipa.ipapython.ipaldap.SchemaCache: DEBUG flushing ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket conn= ipa : DEBUG Fallback group already set, nothing to do Fallback group already set, nothing to do ipa : DEBUG duration: 0 seconds ipa : DEBUG [19/22]: adding Default Trust View [19/22]: adding Default Trust View ipa : DEBUG Default Trust View already exists. Default Trust View already exists. ipa : DEBUG duration: 0 seconds ipa : DEBUG [20/22]: setting SELinux booleans [20/22]: setting SELinux booleans ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/selinuxenabled ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG duration: 0 seconds ipa : DEBUG [21/22]: starting CIFS services [21/22]: starting CIFS services ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl start smb.service ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout= ipa : DEBUG stderr=Job for smb.service failed because the control process exited with error code. See "systemctl status smb.service" and "journalctl -xe" for details. ipa : CRITICAL CIFS services failed to start ipa : DEBUG duration: 6 seconds ipa : DEBUG [22/22]: restarting smbd [22/22]: restarting smbd ipa : DEBUG duration: 0 seconds ipa : DEBUG Done configuring CIFS. Done configuring CIFS. ... ipa : DEBUG Starting external process ipa : DEBUG args=kinit admin ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=Password for admin at MY.IPA.SUBDOMAIN: ipa : DEBUG stderr= ipa : INFO The ipa-adtrust-install command was successful On the smb logs I can see: ... [2017/04/10 16:27:58.896485, 11, pid=22584, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1067(smbldap_open) smbldap_open: already connected to the LDAP server [2017/04/10 16:27:58.898224, 0, pid=22584, effective(0, 0), real(0, 0)] ipa_sam.c:3688(ipasam_search_domain_info) iapsam_search_domain_info: Got [2] domain info entries, but expected only 1. <*************************************************************** [2017/04/10 16:27:58.898278, 0, pid=22584, effective(0, 0), real(0, 0)] ipa_sam.c:4543(pdb_init_ipasam) pdb_init_ldapsam: WARNING: Could not get domain info, nor add one to the domain. We cannot work reliably without it. <**************************************** [2017/04/10 16:27:58.898302, 0, pid=22584, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_interface.c:179(make_pdb_method_name) pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-MY-IPA-SUBDOMAIN.socket did not correctly init (error was NT_STATUS_CANT_ACCESS_DOMAIN_INFO) I have traced the ipa-adtrust-install and systemctl start smb, but I couldn't get the "domain info entries". Checking the LDAP directory I showed: [root at HOSTNAME]# ldapsearch -w XXXXXXXX -h localhost -s sub -b 'dc=MY,dc=IPA,dc=SUBDOMAIN' -D "cn=Directory Manager" "objectclass=ipaNTDomainAttrs" # extended LDIF # # LDAPv3 # base with scope subtree # filter: objectclass=ipaNTDomainAttrs # requesting: ALL # # my.ipa.subdomain, ad + 773d9684-12f211e7-b1abe436-0243208c, etc, my.ipa.subdomain dn: cn=my.ipa.subdomain,cn=ad+nsuniqueid=773d9684-12f211e7-b1abe436-0243208c,cn=etc,dc=MY,dc=IPA,dc=SUBDOMAIN objectClass: nsContainer objectClass: ipaNTDomainAttrs objectClass: top ipaNTSecurityIdentifier: S-1-5-21-3119812475-2647440479-1423840280 cn: my.ipa.subdomain ipaNTDomainGUID: 449b23da-6e30-4fa9-9d34-3426bcec8d0f ipaNTFlatName: IPA # my.ipa.subdomain, ad, etc, my.ipa.subdomain dn: cn=my.ipa.subdomain,cn=ad,cn=etc,dc=MY,dc=IPA,dc=SUBDOMAIN ipaNTFallbackPrimaryGroup: cn=editors,cn=groups,cn=accounts,dc=MY,dc=IPA,dc=SUBDOMAIN objectClass: nsContainer objectClass: ipaNTDomainAttrs objectClass: top ipaNTSecurityIdentifier: S-1-5-21-1187620393-3629609531-1738010010 cn: my.ipa.subdomain ipaNTDomainGUID: 09ec963b-ca7d-4a04-b533-7283d0fac036 ipaNTFlatName: IPA # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 But not sure if those are the 2 "Domains info entries". Can you please let me know how to fix this problem? ################ The environment: ##################### Red Hat Enterprise Linux Server release 7.3 (Maipo) SELinux status: disabled Domain level 1 ipa-admintools-4.4.0-14.el7_3.6.noarch ipa-client-4.4.0-14.el7_3.6.x86_64 ipa-client-common-4.4.0-14.el7_3.6.noarch ipa-common-4.4.0-14.el7_3.6.noarch ipa-debuginfo-4.4.0-14.el7_3.6.x86_64 ipa-python-compat-4.4.0-14.el7_3.6.noarch ipa-server-4.4.0-14.el7_3.6.x86_64 ipa-server-common-4.4.0-14.el7_3.6.noarch ipa-server-dns-4.4.0-14.el7_3.6.noarch ipa-server-trust-ad-4.4.0-14.el7_3.6.x86_64 libipa_hbac-1.14.0-43.el7_3.11.x86_64 python2-ipaclient-4.4.0-14.el7_3.6.noarch python2-ipalib-4.4.0-14.el7_3.6.noarch python2-ipaserver-4.4.0-14.el7_3.6.noarch python-iniparse-0.4-9.el7.noarch python-ipaddress-1.0.16-2.el7.noarch python-libipa_hbac-1.14.0-43.el7_3.11.x86_64 sssd-ipa-1.14.0-43.el7_3.11.x86_64 samba-winbind-modules-4.4.4-12.el7_3.x86_64 samba-client-4.4.4-12.el7_3.x86_64 samba-winbind-clients-4.4.4-12.el7_3.x86_64 samba-libs-4.4.4-12.el7_3.x86_64 samba-common-tools-4.4.4-12.el7_3.x86_64 samba-debuginfo-4.4.4-12.el7_3.x86_64 samba-common-4.4.4-12.el7_3.noarch samba-common-libs-4.4.4-12.el7_3.x86_64 samba-4.4.4-12.el7_3.x86_64 samba-winbind-4.4.4-12.el7_3.x86_64 samba-python-4.4.4-12.el7_3.x86_64 samba-client-libs-4.4.4-12.el7_3.x86_64 Thank you very much. ______________________________ Miguel Soler Sang?esa Consultant - Linux Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From hawk at tbi.univie.ac.at Thu Apr 13 09:49:11 2017 From: hawk at tbi.univie.ac.at (Richard Neuboeck) Date: Thu, 13 Apr 2017 11:49:11 +0200 Subject: [Freeipa-users] password history Message-ID: Hi there, I'm hoping someone can help me find the password history entries for a particular user. The policy is set up to store 10 passwords. Changing the password confirmS that the history works properly. From what I've found online I was lead to believe that the history entries are stored in krbPwdHistory and that I should be able to access those entries as 'Directory Manager' without restrictions. https://www.redhat.com/archives/freeipa-users/2013-July/msg00166.html However this attribute doesn't show up. Searching the database I found the appropriate entry in the policy (krbPwdHistoryLength) for how many passwords are stored but not the password history attribute itself. I've been searching the database for a specific user like this: ldapsearch -x -D 'cn=Directory Manager' -W -b 'uid=frink,cn=users,cn=accounts,dc=example,dc=com' and also searched the whole domain (default base): ldapsearch -x -D 'cn=Directory Manager' -W I've also compared the output of the whole domain prior and post to changing a users password. The attributes that changed did not include an obvious history element (unless there is some kind of magic involved). Some more details about the setup: ipa-server-4.4.0-14.el7.centos.6.x86_64, obviously running on CentOS 7. I would highly appreciate any pointers as to where I could find the history of password hashes! Thanks! Richard -- /dev/null -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ronaldw at ronzo.at Thu Apr 13 10:47:21 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 13 Apr 2017 12:47:21 +0200 Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: <1407782393.1609.1492010506460.JavaMail.zimbra@tresgeek.net> References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> <1407782393.1609.1492010506460.JavaMail.zimbra@tresgeek.net> Message-ID: <1577345e-0e43-ebfc-b8a5-9204ad37d5df@ronzo.at> On 2017-04-12 17:21, Jason B. Nance wrote: > [...] > You can still use autofs and mkhomdir, just use a direct mount for /home instead of indirect mounts. In other words, mount "/home" entirely vs. "/home/" individually. > Thanks for clarification. I made a direct map for /home now that looks like: /home -fstype=nfs4,rw,sec=sys ipanfs.mydomain.at:/homeshare If i try to login on my testclient, the user home directory gets created. Permissions (UID/GID) are set correctly but the directory is still inaccessible for the user. My question is why? Is it because i set sec to sys here? When I set it to krb5, automount does not even mount /home From abokovoy at redhat.com Thu Apr 13 11:00:06 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Apr 2017 14:00:06 +0300 Subject: [Freeipa-users] password history In-Reply-To: References: Message-ID: <20170413110006.ztgd27rzvoclfahs@redhat.com> On to, 13 huhti 2017, Richard Neuboeck wrote: >Hi there, > >I'm hoping someone can help me find the password history entries for >a particular user. > >The policy is set up to store 10 passwords. Changing the password >confirmS that the history works properly. > >From what I've found online I was lead to believe that the history >entries are stored in krbPwdHistory and that I should be able to >access those entries as 'Directory Manager' without restrictions. > >https://www.redhat.com/archives/freeipa-users/2013-July/msg00166.html > >However this attribute doesn't show up. Searching the database I >found the appropriate entry in the policy (krbPwdHistoryLength) for >how many passwords are stored but not the password history attribute >itself. > >I've been searching the database for a specific user like this: >ldapsearch -x -D 'cn=Directory Manager' -W -b >'uid=frink,cn=users,cn=accounts,dc=example,dc=com' > >and also searched the whole domain (default base): >ldapsearch -x -D 'cn=Directory Manager' -W > >I've also compared the output of the whole domain prior and post to >changing a users password. The attributes that changed did not >include an obvious history element (unless there is some kind of >magic involved). > >Some more details about the setup: >ipa-server-4.4.0-14.el7.centos.6.x86_64, obviously running on CentOS 7. > >I would highly appreciate any pointers as to where I could find the >history of password hashes! Password history is stored in passwordHistory attribute. This attribute is not returned by default, one have to specify it explicitly. -- / Alexander Bokovoy From dag at sonsorol.org Thu Apr 13 12:05:41 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 13 Apr 2017 08:05:41 -0400 Subject: [Freeipa-users] any tips or horror stories about automating dynamic enrollment and removal of IPA clients? Message-ID: <58EF6995.4080304@sonsorol.org> Hi folks, I've got a high performance computing (HPC) use case that will need AD integration for user identity management. We've got a working IPA server in AWS that has 1-way trusts going to several remote AD forests and child domains. Works fine but so far all of the enrolled clients are largely static/persistent boxes. The issue is that the HPC cluster footprint is going to be elastic by design. We'll likely keep 3-5 nodes in the grid online 24x7 but the vast majority of the compute node fleet (hundreds of nodes quite likely) will be fired up on demand as a mixture of spot, RI and hourly-rate EC2 instances. The cluster will automatically shrink in size as well when needed. Trying to think of which method I should use for managing users (mainly UID and GID values) on the compute fleet: [Option 1] Script the enrollment and de-install actions via existing hooks we have for running scripts at "first boot" as well as "pre-termination". I think this seems technically pretty straightforward but I'm not sure I really need to stuff our IPA server with host information for boxes that are considered anonymous and disposable. We don't care about them really and don't need to implement RBAC controls on them. Also slightly worried that a large-scale enrollment or uninstall action may bog down the server or (worse) perhaps only partially complete leading to an HPC grid where jobs flow into a bad box and die en-mass because "user does not exist..." [Option 2] Steal from the HPC ops playbook and minimize network services that can cause failures. Distribute static files to the worker fleet -- Bind the 24x7 persistent systems to the IPA server and force all HPC users to provide a public SSH key. Then use commands like "id References: <20170413110006.ztgd27rzvoclfahs@redhat.com> Message-ID: On 04/13/2017 01:00 PM, Alexander Bokovoy wrote: > Password history is stored in passwordHistory attribute. This attribute > is not returned by default, one have to specify it explicitly. thanks! -- /dev/null -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ronaldw at ronzo.at Thu Apr 13 12:24:48 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 13 Apr 2017 14:24:48 +0200 Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: <1577345e-0e43-ebfc-b8a5-9204ad37d5df@ronzo.at> References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> <1407782393.1609.1492010506460.JavaMail.zimbra@tresgeek.net> <1577345e-0e43-ebfc-b8a5-9204ad37d5df@ronzo.at> Message-ID: <7c0790fc-894f-315a-d1b5-189f8399459a@ronzo.at> On 2017-04-13 12:47, Ronald Wimmer wrote: > On 2017-04-12 17:21, Jason B. Nance wrote: >> [...] >> You can still use autofs and mkhomdir, just use a direct mount for >> /home instead of indirect mounts. In other words, mount "/home" >> entirely vs. "/home/" individually. >> > Thanks for clarification. I made a direct map for /home now that looks > like: > /home -fstype=nfs4,rw,sec=sys ipanfs.mydomain.at:/homeshare > > If i try to login on my testclient, the user home directory gets > created. Permissions (UID/GID) are set correctly but the directory is > still inaccessible for the user. > > My question is why? Is it because i set sec to sys here? When I set it > to krb5, automount does not even mount /home > It was my own fault. I somehow messed up the /etc/krb5.keytab on the testclient. After correcting it everything works like a charm. Regards, Ronald From gmzgames.de at googlemail.com Thu Apr 13 13:21:20 2017 From: gmzgames.de at googlemail.com (Gerald-Markus Zabos) Date: Thu, 13 Apr 2017 15:21:20 +0200 Subject: [Freeipa-users] any tips or horror stories about automating dynamic enrollment and removal of IPA clients? In-Reply-To: <58EF6995.4080304@sonsorol.org> References: <58EF6995.4080304@sonsorol.org> Message-ID: <1492089680.4713.47.camel@googlemail.com> Am Donnerstag, den 13.04.2017, 08:05 -0400 schrieb Chris Dagdigian: > Right now I'm leaning towards Option #2 but would love to hear > experiences regarding moderate-scale automatic enrollment and removal of > clients! > > -Chris Hi Chris, we're facing a similar use case from day to day, but changed from AWS to another cloud provider. Our use case works on both, so i am refering to AWS. We decided... ...to use SGE for our HPC infrastructure ...recycle network ranges for 100 static IP addresses + 100 static hostnames ...to use scripts & cronjobs & ansible (depending on "qstat" and "qhost" output) on the cluster head node to determine how many additional cluster nodes have to be created as an additional reserve for "What-if-we-need-more-nodes?" scenarios ...to create cluster nodes via ansible-playbook on AWS from a pre-defined image, do software installation & configuration via ansible-playbook, do the IPA domain join via ansible-playbook ("ipa-client-install --domain= --mkhomedir --hostname=. --ip-address= -p -w --unattended") ...to destroy cluster nodes in two steps: 1) ansible-playbook "ipa-client-install --uninstall", 2) ansible-playbook destroy cluster node on AWS via API (Right now, i am working on a bulk creation script of IPA users/groups for expanding our single HPC cluster into several ones, whereas we have the same set of users (~65-100) with differing suffix in the username e.g. "it_ops01", "it_ops20", etc...) We're using 2x IPA-Servers (ESXi VMs, 4GB RAM, 2 CPU) in replication with another 2x IPA Servers (same dimensions) on our main physical datacenter. Didn't see much impact on the IPA servers during enrollment/removal of domain hosts. So far after three months of operations, we had several "bad box" scenarios, all of them because of problems with SGE. We solved these problems manually, by removing/adding cluster nodes via SGE commands. As you can see, i tend to [Option 1], since it does all the magic with pre-defined software commands(sge, ansible, ipa cli), instead of jumping around with additional scripts doing work, which can be done by "built-in" commands. For us, this works best. Regards, Gerald -- Gerald-Markus Zabos Web: http://www.gmzgames.de From simo at redhat.com Thu Apr 13 13:31:31 2017 From: simo at redhat.com (Simo Sorce) Date: Thu, 13 Apr 2017 09:31:31 -0400 Subject: [Freeipa-users] any tips or horror stories about automating dynamic enrollment and removal of IPA clients? In-Reply-To: <58EF6995.4080304@sonsorol.org> References: <58EF6995.4080304@sonsorol.org> Message-ID: <1492090291.3662.178.camel@redhat.com> On Thu, 2017-04-13 at 08:05 -0400, Chris Dagdigian wrote: > Hi folks, > > I've got a high performance computing (HPC) use case that will need AD > integration for user identity management. We've got a working IPA server > in AWS that has 1-way trusts going to several remote AD forests and > child domains. Works fine but so far all of the enrolled clients are > largely static/persistent boxes. > > The issue is that the HPC cluster footprint is going to be elastic by > design. We'll likely keep 3-5 nodes in the grid online 24x7 but the vast > majority of the compute node fleet (hundreds of nodes quite likely) will > be fired up on demand as a mixture of spot, RI and hourly-rate EC2 > instances. The cluster will automatically shrink in size as well when > needed. > > Trying to think of which method I should use for managing users (mainly > UID and GID values) on the compute fleet: > > [Option 1] Script the enrollment and de-install actions via existing > hooks we have for running scripts at "first boot" as well as > "pre-termination". I think this seems technically pretty > straightforward but I'm not sure I really need to stuff our IPA server > with host information for boxes that are considered anonymous and > disposable. We don't care about them really and don't need to implement > RBAC controls on them. Also slightly worried that a large-scale > enrollment or uninstall action may bog down the server or (worse) > perhaps only partially complete leading to an HPC grid where jobs flow > into a bad box and die en-mass because "user does not exist..." > > [Option 2] Steal from the HPC ops playbook and minimize network > services that can cause failures. Distribute static files to the worker > fleet -- Bind the 24x7 persistent systems to the IPA server and force > all HPC users to provide a public SSH key. Then use commands like "id > that we can manufacture static /etc/passwd, /etc/shadow and /etc/group > files that can be pushed out to the compute node fleet. The main win > here is that we can maintain consistent IPA-derived > UID/GID/username/group data cluster wide while totally removing the need > for an elastic set of anonymous boxes to be individually enrolled and > removed from IPA all the time. > > Right now I'm leaning towards Option #2 but would love to hear > experiences regarding moderate-scale automatic enrollment and removal of > clients! One option could also be to keep a (set of) keytab(s) you can copy on the elastic hosts and preconfigure their sssd daemon. At boot you copy the keytab in the host and start sssd and everything should magically work. They all are basically the same identity so using the same key for all of them may be acceptable. >From the IPA side it will look like suddenly the same host has multiple IP addresses and is opening one connection from each of them, but that is ok. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From abokovoy at redhat.com Thu Apr 13 14:16:19 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Apr 2017 17:16:19 +0300 Subject: [Freeipa-users] any tips or horror stories about automating dynamic enrollment and removal of IPA clients? In-Reply-To: <1492090291.3662.178.camel@redhat.com> References: <58EF6995.4080304@sonsorol.org> <1492090291.3662.178.camel@redhat.com> Message-ID: <20170413141619.xvevdkp2r4n4hcpp@redhat.com> On to, 13 huhti 2017, Simo Sorce wrote: >On Thu, 2017-04-13 at 08:05 -0400, Chris Dagdigian wrote: >> Hi folks, >> >> I've got a high performance computing (HPC) use case that will need AD >> integration for user identity management. We've got a working IPA server >> in AWS that has 1-way trusts going to several remote AD forests and >> child domains. Works fine but so far all of the enrolled clients are >> largely static/persistent boxes. >> >> The issue is that the HPC cluster footprint is going to be elastic by >> design. We'll likely keep 3-5 nodes in the grid online 24x7 but the vast >> majority of the compute node fleet (hundreds of nodes quite likely) will >> be fired up on demand as a mixture of spot, RI and hourly-rate EC2 >> instances. The cluster will automatically shrink in size as well when >> needed. >> >> Trying to think of which method I should use for managing users (mainly >> UID and GID values) on the compute fleet: >> >> [Option 1] Script the enrollment and de-install actions via existing >> hooks we have for running scripts at "first boot" as well as >> "pre-termination". I think this seems technically pretty >> straightforward but I'm not sure I really need to stuff our IPA server >> with host information for boxes that are considered anonymous and >> disposable. We don't care about them really and don't need to implement >> RBAC controls on them. Also slightly worried that a large-scale >> enrollment or uninstall action may bog down the server or (worse) >> perhaps only partially complete leading to an HPC grid where jobs flow >> into a bad box and die en-mass because "user does not exist..." >> >> [Option 2] Steal from the HPC ops playbook and minimize network >> services that can cause failures. Distribute static files to the worker >> fleet -- Bind the 24x7 persistent systems to the IPA server and force >> all HPC users to provide a public SSH key. Then use commands like "id >> > that we can manufacture static /etc/passwd, /etc/shadow and /etc/group >> files that can be pushed out to the compute node fleet. The main win >> here is that we can maintain consistent IPA-derived >> UID/GID/username/group data cluster wide while totally removing the need >> for an elastic set of anonymous boxes to be individually enrolled and >> removed from IPA all the time. >> >> Right now I'm leaning towards Option #2 but would love to hear >> experiences regarding moderate-scale automatic enrollment and removal of >> clients! > >One option could also be to keep a (set of) keytab(s) you can copy on >the elastic hosts and preconfigure their sssd daemon. At boot you copy >the keytab in the host and start sssd and everything should magically >work. They all are basically the same identity so using the same key for >all of them may be acceptable. It would be better to avoid using Kerberos authentication here at all. Multiple hosts authenticating with the same key would cause a lot of updates in the LDAP entry representing this principal. This is going to break replication if this is the only key that is used by multiple hosts against multiple IPA masters. -- / Alexander Bokovoy From simo at redhat.com Thu Apr 13 14:25:45 2017 From: simo at redhat.com (Simo Sorce) Date: Thu, 13 Apr 2017 10:25:45 -0400 Subject: [Freeipa-users] any tips or horror stories about automating dynamic enrollment and removal of IPA clients? In-Reply-To: <20170413141619.xvevdkp2r4n4hcpp@redhat.com> References: <58EF6995.4080304@sonsorol.org> <1492090291.3662.178.camel@redhat.com> <20170413141619.xvevdkp2r4n4hcpp@redhat.com> Message-ID: <1492093545.3662.182.camel@redhat.com> On Thu, 2017-04-13 at 17:16 +0300, Alexander Bokovoy wrote: > On to, 13 huhti 2017, Simo Sorce wrote: > >On Thu, 2017-04-13 at 08:05 -0400, Chris Dagdigian wrote: > >> Hi folks, > >> > >> I've got a high performance computing (HPC) use case that will need AD > >> integration for user identity management. We've got a working IPA server > >> in AWS that has 1-way trusts going to several remote AD forests and > >> child domains. Works fine but so far all of the enrolled clients are > >> largely static/persistent boxes. > >> > >> The issue is that the HPC cluster footprint is going to be elastic by > >> design. We'll likely keep 3-5 nodes in the grid online 24x7 but the vast > >> majority of the compute node fleet (hundreds of nodes quite likely) will > >> be fired up on demand as a mixture of spot, RI and hourly-rate EC2 > >> instances. The cluster will automatically shrink in size as well when > >> needed. > >> > >> Trying to think of which method I should use for managing users (mainly > >> UID and GID values) on the compute fleet: > >> > >> [Option 1] Script the enrollment and de-install actions via existing > >> hooks we have for running scripts at "first boot" as well as > >> "pre-termination". I think this seems technically pretty > >> straightforward but I'm not sure I really need to stuff our IPA server > >> with host information for boxes that are considered anonymous and > >> disposable. We don't care about them really and don't need to implement > >> RBAC controls on them. Also slightly worried that a large-scale > >> enrollment or uninstall action may bog down the server or (worse) > >> perhaps only partially complete leading to an HPC grid where jobs flow > >> into a bad box and die en-mass because "user does not exist..." > >> > >> [Option 2] Steal from the HPC ops playbook and minimize network > >> services that can cause failures. Distribute static files to the worker > >> fleet -- Bind the 24x7 persistent systems to the IPA server and force > >> all HPC users to provide a public SSH key. Then use commands like "id > >> >> that we can manufacture static /etc/passwd, /etc/shadow and /etc/group > >> files that can be pushed out to the compute node fleet. The main win > >> here is that we can maintain consistent IPA-derived > >> UID/GID/username/group data cluster wide while totally removing the need > >> for an elastic set of anonymous boxes to be individually enrolled and > >> removed from IPA all the time. > >> > >> Right now I'm leaning towards Option #2 but would love to hear > >> experiences regarding moderate-scale automatic enrollment and removal of > >> clients! > > > >One option could also be to keep a (set of) keytab(s) you can copy on > >the elastic hosts and preconfigure their sssd daemon. At boot you copy > >the keytab in the host and start sssd and everything should magically > >work. They all are basically the same identity so using the same key for > >all of them may be acceptable. > It would be better to avoid using Kerberos authentication here at all. > > Multiple hosts authenticating with the same key would cause a lot of > updates in the LDAP entry representing this principal. This is going to > break replication if this is the only key that is used by multiple hosts > against multiple IPA masters. If replication is a issue we should probably mask those attributes from replication as well, just like we do for attributes for failed auth. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From keesb at ghs.com Thu Apr 13 14:30:33 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 13 Apr 2017 16:30:33 +0200 Subject: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain in DHCP dyndns update Message-ID: Hey, Hopefully someone here can hint me towards a (easier) solution. In short, for correct DHCP-DDNS updates there should be a non-fqdn in /etc/hostname To install IPA client I am forced to have a fqdn in /etc/hostname. But now the DHCP-DDNS results in duplicated domain portion of the DNS entries. The details. We have a FreeIPA environment with DNS and DHCP. I've configured bind and dhcpd to do DDNS. For the most part it is working as expected. When the hostname of a system is a non-fqdn the end result is what I want to see. Say I have /etc/hostname: test02 then after it started up there is a new forward map (using "mydomain" here instead of the real thing). test01 -> 172.16.16.252 and a reverse map in 16.16.172.in-addr.arpa zone 252 -> test02.mydomain Some lines from /var/log/syslog dhcpd[82333]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' A 172.16.16.252 dhcpd[82333]: DHCPREQUEST for 172.16.16.252 (172.16.16.75) from 00:16:3e:8e:91:12 (test02) via eno1 dhcpd[82333]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' DHCID AAAB6QGH0W+JCSMwrj9sQVCeh5PToZAmWZvMpgiEtXHrZgE= dhcpd[82333]: Added new forward map from test02.mydomain to 172.16.16.252 named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating zone '16.16.172.in-addr.arpa/IN': adding an RR at '252.16.16.172.in-addr.arpa' PTR test02.mydomain. dhcpd[82333]: Added reverse map from 252.16.16.172.in-addr.arpa. to test02.mydomain However, when I want to add this system as a IPA client I am forced to fill in a fqdn in /etc/hostname. So I change /etc/hostname to have test01.mydomain The provisioning succeeds and all seems well. But after a reboot the system requests DHCP to register as test01.mydomain. And the DHCP server does a DNS update for test01.mydomain.mydomain. The DNS zone for mydomain now has test01 for all the SSHFP records test01.mydomain for the A record The reverse map for 16.16.172.in-addr.arpa has 231 -> test01.mydomain.mydomain named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain A dhcpd[4550]: DHCPREQUEST for 172.16.16.252 from 00:16:3e:8e:91:12 (test02) via eno1 dhcpd[4550]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02.mydomain) via eno1 dhcpd[4550]: Removed forward map from test02.mydomain to 172.16.16.252 named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain DHCID named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' A 172.16.16.252 named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' DHCID AAAB+5EmVxuf4utDMDZxjqAiqIds6Briv5awEp5W3whNsLc= dhcpd[4550]: Added new forward map from test02.mydomain.mydomain to 172.16.16.252 named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone '16.16.172.in-addr.arpa/IN': adding an RR at '252.16.16.172.in-addr.arpa' PTR test02.mydomain.mydomain. dhcpd[4550]: Added reverse map from 252.16.16.172.in-addr.arpa. to test02.mydomain.mydomain To work around I then change the /etc/hostname back to test01, restart the network and everything if fine afterwards. named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain A dhcpd[4550]: DHCPRELEASE of 172.16.16.252 from 00:16:3e:8e:91:12 (test02.mydomain) via eno1 (found) dhcpd[4550]: Removed forward map from test02.mydomain.mydomain to 172.16.16.252 named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain DHCID dhcpd[4550]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': update unsuccessful: test02.mydomain: 'name not in use' prerequisite not satisfied (YXDOMAIN) dhcpd[4550]: DHCPREQUEST for 172.16.16.252 (172.16.16.75) from 00:16:3e:8e:91:12 (test02) via eno1 dhcpd[4550]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting rrset at 'test02.mydomain' DHCID named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' DHCID AAAB6QGH0W+JCSMwrj9sQVCeh5PToZAmWZvMpgiEtXHrZgE= named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting rrset at 'test02.mydomain' A named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' A 172.16.16.252 dhcpd[4550]: Added new forward map from test02.mydomain to 172.16.16.252 named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone '16.16.172.in-addr.arpa/IN': adding an RR at '252.16.16.172.in-addr.arpa' PTR test02.mydomain. dhcpd[4550]: Added reverse map from 252.16.16.172.in-addr.arpa. to test02.mydomain -- Kees From dag at sonsorol.org Thu Apr 13 14:44:51 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 13 Apr 2017 10:44:51 -0400 Subject: [Freeipa-users] any tips or horror stories about automating dynamic enrollment and removal of IPA clients? In-Reply-To: <1492089680.4713.47.camel@googlemail.com> References: <58EF6995.4080304@sonsorol.org> <1492089680.4713.47.camel@googlemail.com> Message-ID: <58EF8EE3.5080300@sonsorol.org> An HTML attachment was scrubbed... URL: From t.ruiten at rdmedia.com Thu Apr 13 14:49:59 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 13 Apr 2017 16:49:59 +0200 Subject: [Freeipa-users] (no subject) Message-ID: Hello! As I understand from this thread, it should be possible to setup a trust between FreeIPA and Samba4. My AD domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain, i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC to one of the FreeIPA replica's and lookup of SRV records in both domains appears to work. However when I try to add the trust I get "ipa: ERROR an internal error has occurred". I ran the trust-add command with full debug logging as described on https://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust, so I can provide these logs privately upon request. I suspect some DNS-issue, as right after I try to setup the trust, dynamic updates stop working on the AD Domain Controller with this error: tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ fluorine.clients.i.rdmedia.com at I.RDMEDIA.COM not found in Kerberos database. Failed nsupdate: 1 update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._ sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com 389 Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._ sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com 389 (add) Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTION: _ldap._tcp.Default-First-Site-Name._ sites.ForestDnsZones.clients.i.rdmedia.com. 900 IN SRV 0 100 389 fluorine.clients.i.rdmedia.com. Many thanks in advance for your assistance. -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.ruiten at rdmedia.com Thu Apr 13 14:51:25 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 13 Apr 2017 16:51:25 +0200 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC Message-ID: Apologies, now with proper subject. On 13 April 2017 at 16:49, Tiemen Ruiten wrote: > Hello! > > As I understand from this > thread, > it should be possible to setup a trust between FreeIPA and Samba4. My AD > domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain, > i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC to > one of the FreeIPA replica's and lookup of SRV records in both domains > appears to work. > > However when I try to add the trust I get "ipa: ERROR an internal error > has occurred". I ran the trust-add command with full debug logging as > described on https://www.freeipa.org/page/Active_Directory_trust_setup# > Debugging_trust, so I can provide these logs privately upon request. > > I suspect some DNS-issue, as right after I try to setup the trust, dynamic > updates stop working on the AD Domain Controller with this error: > > tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor > code may provide more information, Minor = Server DNS/fluorine.clients.i. > rdmedia.com at I.RDMEDIA.COM not found in Kerberos database. > Failed nsupdate: 1 > update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._ > sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com > 389 > Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._ > sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com > 389 (add) > Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 > ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 > ;; UPDATE SECTION: > _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones. > clients.i.rdmedia.com. 900 IN SRV 0 100 389 fluorine.clients.i.rdmedia.com > . > > Many thanks in advance for your assistance. > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Apr 13 15:09:52 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Apr 2017 18:09:52 +0300 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: References: Message-ID: <20170413150952.qyuinpdhij23bqpw@redhat.com> On to, 13 huhti 2017, Tiemen Ruiten wrote: >Apologies, now with proper subject. > >On 13 April 2017 at 16:49, Tiemen Ruiten wrote: > >> Hello! >> >> As I understand from this >> thread, >> it should be possible to setup a trust between FreeIPA and Samba4. My AD >> domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain, >> i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC to >> one of the FreeIPA replica's and lookup of SRV records in both domains >> appears to work. >> >> However when I try to add the trust I get "ipa: ERROR an internal error >> has occurred". I ran the trust-add command with full debug logging as >> described on https://www.freeipa.org/page/Active_Directory_trust_setup# >> Debugging_trust, so I can provide these logs privately upon request. >> >> I suspect some DNS-issue, as right after I try to setup the trust, dynamic >> updates stop working on the AD Domain Controller with this error: >> >> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor >> code may provide more information, Minor = Server DNS/fluorine.clients.i. >> rdmedia.com at I.RDMEDIA.COM not found in Kerberos database. >> Failed nsupdate: 1 >> update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._ >> sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com >> 389 >> Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._ >> sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com >> 389 (add) >> Outgoing update query: >> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 >> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >> ;; UPDATE SECTION: >> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones. >> clients.i.rdmedia.com. 900 IN SRV 0 100 389 fluorine.clients.i.rdmedia.com >> . >> >> Many thanks in advance for your assistance. It would help if you would provide more details on your setup. The above doesn't give a clue on: - what are FreeIPA and Samba AD DC versions - on what OS versions they run, correspondingly - what DNS zones each of them control - what commands did you run -- / Alexander Bokovoy From t.ruiten at rdmedia.com Thu Apr 13 16:08:50 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 13 Apr 2017 18:08:50 +0200 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: <20170413150952.qyuinpdhij23bqpw@redhat.com> References: <20170413150952.qyuinpdhij23bqpw@redhat.com> Message-ID: Of course: FreeIPA versions: [root at ipa-ams-01 samba]# rpm -qa | grep ipa libipa_hbac-1.14.0-43.el7_3.14.x86_64 sssd-ipa-1.14.0-43.el7_3.14.x86_64 python2-ipaclient-4.4.0-14.el7.centos.7.noarch ipa-server-trust-ad-4.4.0-14.el7.centos.7.x86_64 ipa-client-common-4.4.0-14.el7.centos.7.noarch python-iniparse-0.4-9.el7.noarch python-libipa_hbac-1.14.0-43.el7_3.14.x86_64 python2-ipalib-4.4.0-14.el7.centos.7.noarch ipa-admintools-4.4.0-14.el7.centos.7.noarch ipa-server-common-4.4.0-14.el7.centos.7.noarch ipa-server-4.4.0-14.el7.centos.7.x86_64 ipa-server-dns-4.4.0-14.el7.centos.7.noarch python-ipaddress-1.0.16-2.el7.noarch ipa-client-4.4.0-14.el7.centos.7.x86_64 python2-ipaserver-4.4.0-14.el7.centos.7.noarch ipa-common-4.4.0-14.el7.centos.7.noarch Samba AD DC versions: Also CentOS 7, Samba 4.6.2, built from source, configure with one option: --with-systemd FreeIPA controls i.rdmedia.com, prod.ams.i.rdmedia.com, test.ams.i.rdmedia.com and prod.nyc.i.rdmedia.com. AD controls only clients.i.rdmedia.com and forwards all other DNS queries to ipa-ams-01. Samba uses the BIND9_DLZ backend for DNS. Regarding the commands run: After provisioning the AD domain, I followed this guide, except I set up the global forwarder in /etc/named.conf manually. I got the "ipa: ERROR an internal error has occurred" after running: ipa trust-add --type=ad clients.i.rdmedia.com --admin Administrator --password On 13 April 2017 at 17:09, Alexander Bokovoy wrote: > On to, 13 huhti 2017, Tiemen Ruiten wrote: > >> Apologies, now with proper subject. >> >> On 13 April 2017 at 16:49, Tiemen Ruiten wrote: >> >> Hello! >>> >>> As I understand from this >>> >> msg00147.html> thread, >>> >>> it should be possible to setup a trust between FreeIPA and Samba4. My AD >>> domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain, >>> i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC >>> to >>> one of the FreeIPA replica's and lookup of SRV records in both domains >>> appears to work. >>> >>> However when I try to add the trust I get "ipa: ERROR an internal error >>> has occurred". I ran the trust-add command with full debug logging as >>> described on https://www.freeipa.org/page/Active_Directory_trust_setup# >>> Debugging_trust, so I can provide these logs privately upon request. >>> >>> I suspect some DNS-issue, as right after I try to setup the trust, >>> dynamic >>> updates stop working on the AD Domain Controller with this error: >>> >>> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor >>> code may provide more information, Minor = Server DNS/fluorine.clients.i. >>> rdmedia.com at I.RDMEDIA.COM not found in Kerberos database. >>> Failed nsupdate: 1 >>> update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._ >>> sites.ForestDnsZones.clients.i.rdmedia.com >>> fluorine.clients.i.rdmedia.com >>> 389 >>> Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._ >>> sites.ForestDnsZones.clients.i.rdmedia.com >>> fluorine.clients.i.rdmedia.com >>> 389 (add) >>> Outgoing update query: >>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 >>> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >>> ;; UPDATE SECTION: >>> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones. >>> clients.i.rdmedia.com. 900 IN SRV 0 100 389 >>> fluorine.clients.i.rdmedia.com >>> . >>> >>> Many thanks in advance for your assistance. >>> >> It would help if you would provide more details on your setup. The above > doesn't give a clue on: > - what are FreeIPA and Samba AD DC versions > - on what OS versions they run, correspondingly > - what DNS zones each of them control > - what commands did you run > > -- > / Alexander Bokovoy > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.ruiten at rdmedia.com Thu Apr 13 16:14:45 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 13 Apr 2017 18:14:45 +0200 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: References: <20170413150952.qyuinpdhij23bqpw@redhat.com> Message-ID: Excerpt from the httpd error_log on the FreeIPA replica: [Thu Apr 13 11:17:44.072996 2017] [:error] [pid 28346] ipa: INFO: [jsonserver_kerb] admin at I.RDMEDIA.COM: ping(): SUCCESS [Thu Apr 13 11:17:50.708019 2017] [:error] [pid 28347] ipa: ERROR: non-public: RuntimeError: (-1073741811, 'Unexpected information received') [Thu Apr 13 11:17:50.708121 2017] [:error] [pid 28347] Traceback (most recent call last): [Thu Apr 13 11:17:50.708132 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in wsgi_execute [Thu Apr 13 11:17:50.708140 2017] [:error] [pid 28347] result = command(*args, **options) [Thu Apr 13 11:17:50.708147 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Thu Apr 13 11:17:50.708154 2017] [:error] [pid 28347] return self.__do_call(*args, **options) [Thu Apr 13 11:17:50.708161 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Thu Apr 13 11:17:50.708168 2017] [:error] [pid 28347] ret = self.run(*args, **options) [Thu Apr 13 11:17:50.708213 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Thu Apr 13 11:17:50.708223 2017] [:error] [pid 28347] return self.execute(*args, **options) [Thu Apr 13 11:17:50.708229 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 739, in execute [Thu Apr 13 11:17:50.708237 2017] [:error] [pid 28347] result = self.execute_ad(full_join, *keys, **options) [Thu Apr 13 11:17:50.708244 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 989, in execute_ad [Thu Apr 13 11:17:50.708258 2017] [:error] [pid 28347] trust_type [Thu Apr 13 11:17:50.708265 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in join_ad_full_credentials [Thu Apr 13 11:17:50.708272 2017] [:error] [pid 28347] trust_type, trust_external) [Thu Apr 13 11:17:50.708279 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in establish_trust [Thu Apr 13 11:17:50.708285 2017] [:error] [pid 28347] self.update_ftinfo(another_domain) [Thu Apr 13 11:17:50.708292 2017] [:error] [pid 28347] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in update_ftinfo [Thu Apr 13 11:17:50.708299 2017] [:error] [pid 28347] ftinfo, 0) [Thu Apr 13 11:17:50.708305 2017] [:error] [pid 28347] RuntimeError: (-1073741811, 'Unexpected information received') [Thu Apr 13 11:17:50.709161 2017] [:error] [pid 28347] ipa: INFO: [jsonserver_kerb] admin at I.RDMEDIA.COM: trust_add/1(u'clients.i.rdmedia.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', version=u'2.213'): RuntimeError On 13 April 2017 at 18:08, Tiemen Ruiten wrote: > Of course: > > FreeIPA versions: > [root at ipa-ams-01 samba]# rpm -qa | grep ipa > libipa_hbac-1.14.0-43.el7_3.14.x86_64 > sssd-ipa-1.14.0-43.el7_3.14.x86_64 > python2-ipaclient-4.4.0-14.el7.centos.7.noarch > ipa-server-trust-ad-4.4.0-14.el7.centos.7.x86_64 > ipa-client-common-4.4.0-14.el7.centos.7.noarch > python-iniparse-0.4-9.el7.noarch > python-libipa_hbac-1.14.0-43.el7_3.14.x86_64 > python2-ipalib-4.4.0-14.el7.centos.7.noarch > ipa-admintools-4.4.0-14.el7.centos.7.noarch > ipa-server-common-4.4.0-14.el7.centos.7.noarch > ipa-server-4.4.0-14.el7.centos.7.x86_64 > ipa-server-dns-4.4.0-14.el7.centos.7.noarch > python-ipaddress-1.0.16-2.el7.noarch > ipa-client-4.4.0-14.el7.centos.7.x86_64 > python2-ipaserver-4.4.0-14.el7.centos.7.noarch > ipa-common-4.4.0-14.el7.centos.7.noarch > > Samba AD DC versions: > Also CentOS 7, Samba 4.6.2, built from source, configure with one option: > --with-systemd > > FreeIPA controls i.rdmedia.com, prod.ams.i.rdmedia.com, > test.ams.i.rdmedia.com and prod.nyc.i.rdmedia.com. > AD controls only clients.i.rdmedia.com and forwards all other DNS queries > to ipa-ams-01. > > Samba uses the BIND9_DLZ backend for DNS. > > Regarding the commands run: After provisioning the AD domain, I followed > this guide, > except I set up the global forwarder in /etc/named.conf manually. > > I got the "ipa: ERROR an internal error has occurred" after running: > > ipa trust-add --type=ad clients.i.rdmedia.com --admin Administrator > --password > > On 13 April 2017 at 17:09, Alexander Bokovoy wrote: > >> On to, 13 huhti 2017, Tiemen Ruiten wrote: >> >>> Apologies, now with proper subject. >>> >>> On 13 April 2017 at 16:49, Tiemen Ruiten wrote: >>> >>> Hello! >>>> >>>> As I understand from this >>>> >>> msg00147.html> thread, >>>> >>>> it should be possible to setup a trust between FreeIPA and Samba4. My AD >>>> domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain, >>>> i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC >>>> to >>>> one of the FreeIPA replica's and lookup of SRV records in both domains >>>> appears to work. >>>> >>>> However when I try to add the trust I get "ipa: ERROR an internal error >>>> has occurred". I ran the trust-add command with full debug logging as >>>> described on https://www.freeipa.org/page/Active_Directory_trust_setup# >>>> Debugging_trust, so I can provide these logs privately upon request. >>>> >>>> I suspect some DNS-issue, as right after I try to setup the trust, >>>> dynamic >>>> updates stop working on the AD Domain Controller with this error: >>>> >>>> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor >>>> code may provide more information, Minor = Server >>>> DNS/fluorine.clients.i. >>>> rdmedia.com at I.RDMEDIA.COM not found in Kerberos database. >>>> Failed nsupdate: 1 >>>> update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._ >>>> sites.ForestDnsZones.clients.i.rdmedia.com >>>> fluorine.clients.i.rdmedia.com >>>> 389 >>>> Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._ >>>> sites.ForestDnsZones.clients.i.rdmedia.com >>>> fluorine.clients.i.rdmedia.com >>>> 389 (add) >>>> Outgoing update query: >>>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 >>>> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >>>> ;; UPDATE SECTION: >>>> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones. >>>> clients.i.rdmedia.com. 900 IN SRV 0 100 389 >>>> fluorine.clients.i.rdmedia.com >>>> . >>>> >>>> Many thanks in advance for your assistance. >>>> >>> It would help if you would provide more details on your setup. The above >> doesn't give a clue on: >> - what are FreeIPA and Samba AD DC versions >> - on what OS versions they run, correspondingly >> - what DNS zones each of them control >> - what commands did you run >> >> -- >> / Alexander Bokovoy >> > > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcnt at use.startmail.com Thu Apr 13 17:50:16 2017 From: jcnt at use.startmail.com (Josh) Date: Thu, 13 Apr 2017 13:50:16 -0400 Subject: [Freeipa-users] replica creation problems Message-ID: <16d3ebbd-d04c-194d-0ded-ff87733ad96b@use.startmail.com> Scenario: RHEL7 IPA with DNS and without CA. Initial installation was done using --http-cert-file, --dirsrv-cert-file with certificates from an issuer A. For a number of reasons replica must be created with certificates from an issuer B. A bundle consisting of key, server certificate and a full certificate chain provided by the issuer B is prepared as replica.crt IPA Replica file created as ipa-replica-prepare --dirsrv-cert-file=replica.crt --http-cert-file=replica.crt --dirsrv-pin=key_pass --http-pin=key_pass --ip-address=n.n.n.n --password=manager_pass replica_host_name no errors/warnings during above process. Resulting file transferred to a new clean system and launched as # ipa-replica-install --setup-dns --auto-forwarders --mkhomedir /var/lib/ipa/replica-replica_host_name.gpg Directory Manager (existing master) password: Checking DNS forwarders, please wait ... Run connection check to master admin at REALM password: Connection check OK Adding [n.n.n.n replica_host_name] to your /etc/hosts file 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/42]: creating directory server user [2/42]: creating directory server instance [3/42]: updating configuration in dse.ldif [4/42]: restarting directory server [5/42]: adding default schema [6/42]: enabling memberof plugin [7/42]: enabling winsync plugin [8/42]: configuring replication version plugin [9/42]: enabling IPA enrollment plugin [10/42]: enabling ldapi [11/42]: configuring uniqueness plugin [12/42]: configuring uuid plugin [13/42]: configuring modrdn plugin [14/42]: configuring DNS plugin [15/42]: enabling entryUSN plugin [16/42]: configuring lockout plugin [17/42]: configuring topology plugin [18/42]: creating indices [19/42]: enabling referential integrity plugin [20/42]: configuring ssl for ds instance [21/42]: configuring certmap.conf [22/42]: configure autobind for root [23/42]: configure new location for managed entries [24/42]: configure dirsrv ccache [25/42]: enabling SASL mapping fallback [26/42]: restarting directory server [27/42]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 15 seconds elapsed [master_host_name] reports: Update failed! Status: [-11 - LDAP error: Connect error] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR Failed to start replication ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Log file does not list any obvious errors other then full call stack which tell me nothing, I can post it here if helps. Both machines run no firewall and are on the same subnet. Additional problems noticed during cleanup attempt: # /usr/sbin/ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Replication agreements with the following IPA masters found: master_host_name. Removing any replication agreements before uninstalling the server is strongly recommended. You can remove replication agreements by running the following command on any other IPA master: $ ipa-replica-manage del replica_host_name Are you sure you want to continue with the uninstall procedure? [no]: Aborting uninstall operation. Going to master and running $ ipa-replica-manage del replica_host_name fails with Connection to 'replica_host_name' failed: cannot connect to 'ldaps://replica_host_name:636': TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. Unable to delete replica 'replica_host_name' I attempted to provide --cacert=full_path_to_issuer_B_bundle option but nothing changed. As a matter of fact providing invalid file name to --cacert does not raise any error. Strace output confirm that file listed in --cacert is not Only appending the bundle to /etc/ipa/ca.crt resolved TLS errors. Please advise how I can find root cause of LDAP error: Connect error. I have a suspicion that master LDAP can't connect to replica LDAP for above mentioned TLS reason. Josh. From abokovoy at redhat.com Thu Apr 13 19:44:06 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Apr 2017 22:44:06 +0300 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: References: <20170413150952.qyuinpdhij23bqpw@redhat.com> Message-ID: <20170413194406.j5paq2uldrmfpobm@redhat.com> On Thu, 13 Apr 2017, Tiemen Ruiten wrote: >Excerpt from the httpd error_log on the FreeIPA replica: > >[Thu Apr 13 11:17:44.072996 2017] [:error] [pid 28346] ipa: INFO: >[jsonserver_kerb] admin at I.RDMEDIA.COM: ping(): SUCCESS >[Thu Apr 13 11:17:50.708019 2017] [:error] [pid 28347] ipa: ERROR: >non-public: RuntimeError: (-1073741811, 'Unexpected information received') Please add 'log level = 10' to /usr/share/ipa/smb.conf.empty and re-try 'ipa trust-add', then send me resulting error_log privately. >[Thu Apr 13 11:17:50.708121 2017] [:error] [pid 28347] Traceback (most >recent call last): >[Thu Apr 13 11:17:50.708132 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in >wsgi_execute >[Thu Apr 13 11:17:50.708140 2017] [:error] [pid 28347] result = >command(*args, **options) >[Thu Apr 13 11:17:50.708147 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ >[Thu Apr 13 11:17:50.708154 2017] [:error] [pid 28347] return >self.__do_call(*args, **options) >[Thu Apr 13 11:17:50.708161 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in >__do_call >[Thu Apr 13 11:17:50.708168 2017] [:error] [pid 28347] ret = >self.run(*args, **options) >[Thu Apr 13 11:17:50.708213 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run >[Thu Apr 13 11:17:50.708223 2017] [:error] [pid 28347] return >self.execute(*args, **options) >[Thu Apr 13 11:17:50.708229 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 739, in >execute >[Thu Apr 13 11:17:50.708237 2017] [:error] [pid 28347] result = >self.execute_ad(full_join, *keys, **options) >[Thu Apr 13 11:17:50.708244 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 989, in >execute_ad >[Thu Apr 13 11:17:50.708258 2017] [:error] [pid 28347] trust_type >[Thu Apr 13 11:17:50.708265 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in >join_ad_full_credentials >[Thu Apr 13 11:17:50.708272 2017] [:error] [pid 28347] trust_type, >trust_external) >[Thu Apr 13 11:17:50.708279 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in >establish_trust >[Thu Apr 13 11:17:50.708285 2017] [:error] [pid 28347] >self.update_ftinfo(another_domain) >[Thu Apr 13 11:17:50.708292 2017] [:error] [pid 28347] File >"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in >update_ftinfo >[Thu Apr 13 11:17:50.708299 2017] [:error] [pid 28347] ftinfo, 0) >[Thu Apr 13 11:17:50.708305 2017] [:error] [pid 28347] RuntimeError: >(-1073741811, 'Unexpected information received') >[Thu Apr 13 11:17:50.709161 2017] [:error] [pid 28347] ipa: INFO: >[jsonserver_kerb] admin at I.RDMEDIA.COM: trust_add/1(u'clients.i.rdmedia.com', >trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', >version=u'2.213'): RuntimeError > > >On 13 April 2017 at 18:08, Tiemen Ruiten wrote: > >> Of course: >> >> FreeIPA versions: >> [root at ipa-ams-01 samba]# rpm -qa | grep ipa >> libipa_hbac-1.14.0-43.el7_3.14.x86_64 >> sssd-ipa-1.14.0-43.el7_3.14.x86_64 >> python2-ipaclient-4.4.0-14.el7.centos.7.noarch >> ipa-server-trust-ad-4.4.0-14.el7.centos.7.x86_64 >> ipa-client-common-4.4.0-14.el7.centos.7.noarch >> python-iniparse-0.4-9.el7.noarch >> python-libipa_hbac-1.14.0-43.el7_3.14.x86_64 >> python2-ipalib-4.4.0-14.el7.centos.7.noarch >> ipa-admintools-4.4.0-14.el7.centos.7.noarch >> ipa-server-common-4.4.0-14.el7.centos.7.noarch >> ipa-server-4.4.0-14.el7.centos.7.x86_64 >> ipa-server-dns-4.4.0-14.el7.centos.7.noarch >> python-ipaddress-1.0.16-2.el7.noarch >> ipa-client-4.4.0-14.el7.centos.7.x86_64 >> python2-ipaserver-4.4.0-14.el7.centos.7.noarch >> ipa-common-4.4.0-14.el7.centos.7.noarch >> >> Samba AD DC versions: >> Also CentOS 7, Samba 4.6.2, built from source, configure with one option: >> --with-systemd >> >> FreeIPA controls i.rdmedia.com, prod.ams.i.rdmedia.com, >> test.ams.i.rdmedia.com and prod.nyc.i.rdmedia.com. >> AD controls only clients.i.rdmedia.com and forwards all other DNS queries >> to ipa-ams-01. >> >> Samba uses the BIND9_DLZ backend for DNS. >> >> Regarding the commands run: After provisioning the AD domain, I followed >> this guide, >> except I set up the global forwarder in /etc/named.conf manually. >> >> I got the "ipa: ERROR an internal error has occurred" after running: >> >> ipa trust-add --type=ad clients.i.rdmedia.com --admin Administrator >> --password >> >> On 13 April 2017 at 17:09, Alexander Bokovoy wrote: >> >>> On to, 13 huhti 2017, Tiemen Ruiten wrote: >>> >>>> Apologies, now with proper subject. >>>> >>>> On 13 April 2017 at 16:49, Tiemen Ruiten wrote: >>>> >>>> Hello! >>>>> >>>>> As I understand from this >>>>> >>>> msg00147.html> thread, >>>>> >>>>> it should be possible to setup a trust between FreeIPA and Samba4. My AD >>>>> domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain, >>>>> i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC >>>>> to >>>>> one of the FreeIPA replica's and lookup of SRV records in both domains >>>>> appears to work. >>>>> >>>>> However when I try to add the trust I get "ipa: ERROR an internal error >>>>> has occurred". I ran the trust-add command with full debug logging as >>>>> described on https://www.freeipa.org/page/Active_Directory_trust_setup# >>>>> Debugging_trust, so I can provide these logs privately upon request. >>>>> >>>>> I suspect some DNS-issue, as right after I try to setup the trust, >>>>> dynamic >>>>> updates stop working on the AD Domain Controller with this error: >>>>> >>>>> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor >>>>> code may provide more information, Minor = Server >>>>> DNS/fluorine.clients.i. >>>>> rdmedia.com at I.RDMEDIA.COM not found in Kerberos database. >>>>> Failed nsupdate: 1 >>>>> update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._ >>>>> sites.ForestDnsZones.clients.i.rdmedia.com >>>>> fluorine.clients.i.rdmedia.com >>>>> 389 >>>>> Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._ >>>>> sites.ForestDnsZones.clients.i.rdmedia.com >>>>> fluorine.clients.i.rdmedia.com >>>>> 389 (add) >>>>> Outgoing update query: >>>>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 >>>>> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >>>>> ;; UPDATE SECTION: >>>>> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones. >>>>> clients.i.rdmedia.com. 900 IN SRV 0 100 389 >>>>> fluorine.clients.i.rdmedia.com >>>>> . >>>>> >>>>> Many thanks in advance for your assistance. >>>>> >>>> It would help if you would provide more details on your setup. The above >>> doesn't give a clue on: >>> - what are FreeIPA and Samba AD DC versions >>> - on what OS versions they run, correspondingly >>> - what DNS zones each of them control >>> - what commands did you run >>> >>> -- >>> / Alexander Bokovoy >>> >> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> > > > >-- >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 -- / Alexander Bokovoy From dan at cazena.com Thu Apr 13 20:50:33 2017 From: dan at cazena.com (Dan Dietterich) Date: Thu, 13 Apr 2017 20:50:33 +0000 Subject: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled Message-ID: I am seeing inconsistent results configuring a DNS forward zone. At a bash prompt, as root, after kinit admin, I do: ipa dnsforwardzone-add domain.internal --forwarder= ww.xx.yy.zz --forward-policy=only That works fine and does not warn about DNSSEC. In a Java webapp running as root under a Jetty, I run a shell sub-process and issue the kinit and the same ipa statement. _Sometimes_, I get ipa: WARNING: DNSSEC validation failed: record 'domain.internal. SOA' failed DNSSEC validation on server ww.xx.yy.zz. Please verify your DNSSEC configuration or disable DNSSEC validation on all IPA servers. I modified the /etc/named.conf file to say: dnssec-enable no; dnssec-validation no; and systemctl restart ipa Any clue why the results are different? ipa ?version: VERSION: 4.4.0, API_VERSION: 2.213 Linux ? 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Thanks for any insight! Regards, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Fri Apr 14 07:04:43 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 14 Apr 2017 09:04:43 +0200 Subject: [Freeipa-users] replica creation problems In-Reply-To: <16d3ebbd-d04c-194d-0ded-ff87733ad96b@use.startmail.com> References: <16d3ebbd-d04c-194d-0ded-ff87733ad96b@use.startmail.com> Message-ID: <9e03b2cd-cd64-1526-989c-8e74334ad80e@redhat.com> On 04/13/2017 07:50 PM, Josh wrote: > Scenario: > > RHEL7 IPA with DNS and without CA. Initial installation was done using > --http-cert-file, --dirsrv-cert-file with certificates from an issuer A. > > For a number of reasons replica must be created with certificates from > an issuer B. > > A bundle consisting of key, server certificate and a full certificate > chain provided by the issuer B is prepared as replica.crt > > IPA Replica file created as > > ipa-replica-prepare --dirsrv-cert-file=replica.crt > --http-cert-file=replica.crt --dirsrv-pin=key_pass --http-pin=key_pass > --ip-address=n.n.n.n --password=manager_pass replica_host_name > > no errors/warnings during above process. > > Resulting file transferred to a new clean system and launched as > > # ipa-replica-install --setup-dns --auto-forwarders --mkhomedir > /var/lib/ipa/replica-replica_host_name.gpg > Directory Manager (existing master) password: > > Checking DNS forwarders, please wait ... > Run connection check to master > admin at REALM password: > Connection check OK > Adding [n.n.n.n replica_host_name] to your /etc/hosts file > 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/42]: creating directory server user > [2/42]: creating directory server instance > [3/42]: updating configuration in dse.ldif > [4/42]: restarting directory server > [5/42]: adding default schema > [6/42]: enabling memberof plugin > [7/42]: enabling winsync plugin > [8/42]: configuring replication version plugin > [9/42]: enabling IPA enrollment plugin > [10/42]: enabling ldapi > [11/42]: configuring uniqueness plugin > [12/42]: configuring uuid plugin > [13/42]: configuring modrdn plugin > [14/42]: configuring DNS plugin > [15/42]: enabling entryUSN plugin > [16/42]: configuring lockout plugin > [17/42]: configuring topology plugin > [18/42]: creating indices > [19/42]: enabling referential integrity plugin > [20/42]: configuring ssl for ds instance > [21/42]: configuring certmap.conf > [22/42]: configure autobind for root > [23/42]: configure new location for managed entries > [24/42]: configure dirsrv ccache > [25/42]: enabling SASL mapping fallback > [26/42]: restarting directory server > [27/42]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 15 seconds elapsed > [master_host_name] reports: Update failed! Status: [-11 - LDAP error: > Connect error] > > [error] RuntimeError: Failed to start replication > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROR Failed to > start replication > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See /var/log/ipareplica-install.log > for more information > > Log file does not list any obvious errors other then full call stack > which tell me nothing, I can post it here if helps. > Both machines run no firewall and are on the same subnet. > > Additional problems noticed during cleanup attempt: > > # /usr/sbin/ipa-server-install --uninstall > > This is a NON REVERSIBLE operation and will delete all data and > configuration! > > Are you sure you want to continue with the uninstall procedure? [no]: yes > > Replication agreements with the following IPA masters found: > master_host_name. Removing any replication agreements before > uninstalling the server is strongly recommended. You can remove replication > agreements by running the following command on any other IPA master: > $ ipa-replica-manage del replica_host_name > > Are you sure you want to continue with the uninstall procedure? [no]: > > Aborting uninstall operation. > > > > Going to master and running > > $ ipa-replica-manage del replica_host_name > > fails with > > Connection to 'replica_host_name' failed: cannot connect to > 'ldaps://replica_host_name:636': TLS error -8172:Peer's certificate > issuer has been marked as not trusted by the user. > Unable to delete replica 'replica_host_name' > > I attempted to provide --cacert=full_path_to_issuer_B_bundle option but > nothing changed. As a matter of fact providing invalid file name to > --cacert does not raise any error. Strace output confirm that file > listed in --cacert is not Only appending the bundle to /etc/ipa/ca.crt > resolved TLS errors. > > > Please advise how I can find root cause of LDAP error: Connect error. > I have a suspicion that master LDAP can't connect to replica LDAP for > above mentioned TLS reason. > > Josh. > Hi Josh, I did not try this type of setup myself, but I think the issue comes from missing root certificates. I would try to run $ ipa-cacert-manage --install $ ipa-certupdate on the master. This command will install issuer B certificate as a trusted CA on the master, thus allowing communications with services (eg LDAP on replica) using certificates delivered by issuer B. You may find more information in /var/log/dirsrv/slapd-DOMAINNAME/access and errors files. You can also check if the root certificates are installed in each LDAP server's NSS DB: $ certutil -L -d /etc/dirsrv/slapd-DOMAINNAME You should find issuer A and issuer B certs with CT,C,C trust flags on each machine. HTH, Flo. From abokovoy at redhat.com Fri Apr 14 08:23:27 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Apr 2017 11:23:27 +0300 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: <20170413194406.j5paq2uldrmfpobm@redhat.com> References: <20170413150952.qyuinpdhij23bqpw@redhat.com> <20170413194406.j5paq2uldrmfpobm@redhat.com> Message-ID: <20170414082327.e72mrc4s7aaauqw7@redhat.com> On to, 13 huhti 2017, Alexander Bokovoy wrote: >On Thu, 13 Apr 2017, Tiemen Ruiten wrote: >>Excerpt from the httpd error_log on the FreeIPA replica: >> >>[Thu Apr 13 11:17:44.072996 2017] [:error] [pid 28346] ipa: INFO: >>[jsonserver_kerb] admin at I.RDMEDIA.COM: ping(): SUCCESS >>[Thu Apr 13 11:17:50.708019 2017] [:error] [pid 28347] ipa: ERROR: >>non-public: RuntimeError: (-1073741811, 'Unexpected information received') >Please add 'log level = 10' to /usr/share/ipa/smb.conf.empty and re-try >'ipa trust-add', then send me resulting error_log privately. To get back to the public mailing list, Tiemen sent me logs and I confirm that this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1421869 We currently have no solution to this problem (AD is subdomain of IPA domain). -- / Alexander Bokovoy From ronaldw at ronzo.at Fri Apr 14 11:45:56 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Fri, 14 Apr 2017 13:45:56 +0200 Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: <7c0790fc-894f-315a-d1b5-189f8399459a@ronzo.at> References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> <1407782393.1609.1492010506460.JavaMail.zimbra@tresgeek.net> <1577345e-0e43-ebfc-b8a5-9204ad37d5df@ronzo.at> <7c0790fc-894f-315a-d1b5-189f8399459a@ronzo.at> Message-ID: <1e9ed174-f88d-ad34-35dd-6e8d27f396dc@ronzo.at> On 2017-04-13 14:24, Ronald Wimmer wrote: > [...] > It was my own fault. I somehow messed up the /etc/krb5.keytab on the > testclient. After correcting it everything works like a charm. No. It was not....I was mistaken. The problem is: - sec=sys when I set sec=sys, the share gets automounted and the directory gets created with the right permissions but the user gets a "Permission denied" fore some reason - sec=krb5 the share does not even get automounted sec=krb5p: Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss): looking up /home Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss): /home -> -fstype=nfs4,rw,sec=krb5p ipanfs.linux.mydomain.at:/homeshare Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun): expanded entry: -fstype=nfs4,rw,sec=krb5p ipanfs.linux.mydomain.at:/homeshare Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun): gathered options: fstype=nfs4,rw,sec=krb5p Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun): dequote("ipanfs.linux.mydomain.at:/homeshare") -> ipanfs.linux.mydomain.at:/homeshare Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun): core of entry: options=fstype=nfs4,rw,sec=krb5p, loc=ipanfs.linux.mydomain.at:/homeshare Apr 14 13:30:06 testclient automount[17792]: sun_mount: parse(sun): mounting root /home, mountpoint /home, what ipanfs.linux.mydomain.at:/homeshare, fstype nfs4, options rw,sec=krb5p Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs): root=/home name=/home what=ipanfs.linux.mydomain.at:/homeshare, fstype=nfs4, options=rw,sec=krb5p Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs): nfs options="rw,sec=krb5p", nobind=0, nosymlink=0, ro=0 Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: called with host ipanfs.linux.mydomain.at(10.66.39.164) proto 6 version 0x40 Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: nfs v4 rpc ping time: 0.000265 Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: host ipanfs.linux.mydomain.at cost 265 weight 0 Apr 14 13:30:06 testclient automount[17792]: prune_host_list: selected subset of hosts that support NFS4 over TCP Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs): calling mkdir_path /home Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs): calling mount -t nfs4 -s -o rw,sec=krb5p ipanfs.linux.mydomain.at:/homeshare /home Apr 14 13:30:06 testclient automount[17792]: spawn_mount: mtab link detected, passing -n to mount Apr 14 13:30:06 testclient gssproxy: gssproxy[889]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Apr 14 13:30:06 testclient automount[17792]: >> mount.nfs4: access denied by server while mounting ipanfs.linux.mydomain.at:/homeshare Apr 14 13:30:06 testclient automount[17792]: mount(nfs): nfs: mount failure ipanfs.linux.mydomain.at:/homeshare on /home Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token = 55 Apr 14 13:30:06 testclient automount[17792]: failed to mount /home Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5 Apr 14 13:30:06 testclient automount[17792]: handle_packet_missing_direct: token 56, name /home, request pid 17808 Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token = 56 Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5 Apr 14 13:30:06 testclient automount[17792]: handle_packet_missing_direct: token 57, name /home, request pid 17808 Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token = 57 I would like to start with sec=sys - why doest the user get a permission denied even if its home directory appears to have the right permissions? Where do I have to look into? Regards, Ronald Wimmer From ronaldw at ronzo.at Fri Apr 14 14:18:35 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Fri, 14 Apr 2017 16:18:35 +0200 Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: <1e9ed174-f88d-ad34-35dd-6e8d27f396dc@ronzo.at> References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> <1407782393.1609.1492010506460.JavaMail.zimbra@tresgeek.net> <1577345e-0e43-ebfc-b8a5-9204ad37d5df@ronzo.at> <7c0790fc-894f-315a-d1b5-189f8399459a@ronzo.at> <1e9ed174-f88d-ad34-35dd-6e8d27f396dc@ronzo.at> Message-ID: <251879f8-7a73-bc78-3603-daa3b619ed7d@ronzo.at> I got a little further. Now the share also automounts on the client with sec set to krb5 but the user still gets a "Permission denied" and cannot access his home directory. Can it be related to the fact that the user comes from AD? (Unfortunately, I cannot test with a native IPA user due to another issue.) From ronaldw at ronzo.at Fri Apr 14 14:49:38 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Fri, 14 Apr 2017 16:49:38 +0200 Subject: [Freeipa-users] Problem automounting home shares In-Reply-To: <251879f8-7a73-bc78-3603-daa3b619ed7d@ronzo.at> References: <75af27b3-1083-2e7b-d6aa-d709c9a18db3@ronzo.at> <2144436145.696.1492001732951.JavaMail.zimbra@tresgeek.net> <1407782393.1609.1492010506460.JavaMail.zimbra@tresgeek.net> <1577345e-0e43-ebfc-b8a5-9204ad37d5df@ronzo.at> <7c0790fc-894f-315a-d1b5-189f8399459a@ronzo.at> <1e9ed174-f88d-ad34-35dd-6e8d27f396dc@ronzo.at> <251879f8-7a73-bc78-3603-daa3b619ed7d@ronzo.at> Message-ID: Here are my findings. The problem seems to be related to mkhomedir. By default my homedir looks like /home/%d/%u. In this case, when a user logs in for the first time /home/%d gets created and the %u part is missing. If I create it manually everything works fine. If i set override_homedir to /home/%u in the testclients sssd (nss section) settings the directory gets created and almost everything works fine. On the first login I get a "Could not chdir to home directory /home/myuser: No such file or directory" - the directory seems to get created to late. From karlthane at gmail.com Fri Apr 14 15:29:34 2017 From: karlthane at gmail.com (Alex Thomas) Date: Fri, 14 Apr 2017 10:29:34 -0500 Subject: [Freeipa-users] Freeipa and SELinux Users Message-ID: <1492183774.6034.0@smtp.gmail.com> I am sure this is hiding in the docs somewhere but my google-fu is failing. Since I am running a network with Centos 7 servers and Fedora 25 clients, I would like to set FreeIPA so that users in ipauser are given SELinux role of user_u, and those in the admin group are given sysadm_u. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstephen at redhat.com Fri Apr 14 15:38:28 2017 From: jstephen at redhat.com (Justin Stephenson) Date: Fri, 14 Apr 2017 11:38:28 -0400 Subject: [Freeipa-users] Freeipa and SELinux Users In-Reply-To: <1492183774.6034.0@smtp.gmail.com> References: <1492183774.6034.0@smtp.gmail.com> Message-ID: <6a7087c4-158f-18f1-6309-ceaa06c1dabf@redhat.com> Maybe this is what you are looking for? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/mapping-selinux.html -Justin On 04/14/2017 11:29 AM, Alex Thomas wrote: > I am sure this is hiding in the docs somewhere but my google-fu is > failing. Since I am running a network with Centos 7 servers and Fedora > 25 clients, I would like to set FreeIPA so that users in ipauser are > given SELinux role of user_u, and those in the admin group are given > sysadm_u. > > > > From abokovoy at redhat.com Fri Apr 14 18:02:37 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Apr 2017 21:02:37 +0300 Subject: [Freeipa-users] Freeipa and SELinux Users In-Reply-To: <6a7087c4-158f-18f1-6309-ceaa06c1dabf@redhat.com> References: <1492183774.6034.0@smtp.gmail.com> <6a7087c4-158f-18f1-6309-ceaa06c1dabf@redhat.com> Message-ID: <20170414180237.aynwkjv4osbbrzhk@redhat.com> On Fri, 14 Apr 2017, Justin Stephenson wrote: >Maybe this is what you are looking for? > >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/mapping-selinux.html Also make sure to use POSIX group for mapping assignment because ipausers is non-POSIX group. > >-Justin > >On 04/14/2017 11:29 AM, Alex Thomas wrote: >>I am sure this is hiding in the docs somewhere but my google-fu is >>failing. Since I am running a network with Centos 7 servers and >>Fedora 25 clients, I would like to set FreeIPA so that users in >>ipauser are given SELinux role of user_u, and those in the admin >>group are given sysadm_u. >> >> >> >> > >-- >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 jcnt at use.startmail.com Fri Apr 14 23:56:13 2017 From: jcnt at use.startmail.com (Josh) Date: Fri, 14 Apr 2017 19:56:13 -0400 Subject: [Freeipa-users] replica creation problems In-Reply-To: <9e03b2cd-cd64-1526-989c-8e74334ad80e@redhat.com> References: <16d3ebbd-d04c-194d-0ded-ff87733ad96b@use.startmail.com> <9e03b2cd-cd64-1526-989c-8e74334ad80e@redhat.com> Message-ID: <1fceebf3-2cf9-4863-5997-e6005943094f@use.startmail.com> On 04/14/2017 03:04 AM, Florence Blanc-Renaud wrote: > Hi Josh, > > I did not try this type of setup myself, but I think the issue comes > from missing root certificates. I would try to run > $ ipa-cacert-manage --install > $ ipa-certupdate > on the master. This command will install issuer B certificate as a > trusted CA on the master, thus allowing communications with services > (eg LDAP on replica) using certificates delivered by issuer B. > > You may find more information in > /var/log/dirsrv/slapd-DOMAINNAME/access and errors files. You can also > check if the root certificates are installed in each LDAP server's NSS > DB: > $ certutil -L -d /etc/dirsrv/slapd-DOMAINNAME > You should find issuer A and issuer B certs with CT,C,C trust flags on > each machine. > > HTH, > Flo. Hello Florence, Your explanation is correct. After # ipa-cacert-manage install # kinit admin # ipa-certupdate and staring replica prepared over. replica configuration completed with no errors. However I noticed strange ipa-replica-manage behavior: # ipa-replica-manage del replica_host_name Connection to 'replica_host_name' failed: Insufficient access: Invalid credentials Unable to delete replica 'replica_host_name' # Does anyone know what is missing here? Josh. From jpazdziora at redhat.com Mon Apr 17 10:35:38 2017 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 17 Apr 2017 12:35:38 +0200 Subject: [Freeipa-users] Admin cannot retrieve keytab -- is that expected? Message-ID: <20170417103538.GC11341@redhat.com> Hello, on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve new keytab for a service but they cannot retrieve the existing keys with the -r option. Is that expected? # kdestroy -A # kinit admin Password for admin at EXAMPLE.TEST: # ipa host-add test1.example.test --force ------------------------------- Added host "test1.example.test" ------------------------------- Host name: test1.example.test Principal name: host/test1.example.test at EXAMPLE.TEST Principal alias: host/test1.example.test at EXAMPLE.TEST Password: False Keytab: False Managed by: test1.example.test # ipa service-add HTTP/test1.example.test --force ---------------------------------------------------- Added service "HTTP/test1.example.test at EXAMPLE.TEST" ---------------------------------------------------- Principal name: HTTP/test1.example.test at EXAMPLE.TEST Principal alias: HTTP/test1.example.test at EXAMPLE.TEST Managed by: test1.example.test # ipa-getkeytab -p HTTP/test1.example.test -k /tmp/http.keytab Keytab successfully retrieved and stored in: /tmp/http.keytab # ipa-getkeytab -r -p HTTP/test1.example.test -k /tmp/http.keytab.1 Failed to parse result: Insufficient access rights Failed to get keytab # -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Mon Apr 17 13:49:59 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Apr 2017 16:49:59 +0300 Subject: [Freeipa-users] Admin cannot retrieve keytab -- is that expected? In-Reply-To: <20170417103538.GC11341@redhat.com> References: <20170417103538.GC11341@redhat.com> Message-ID: <20170417134959.vzc7hl6hcg6pyi4c@redhat.com> On Mon, 17 Apr 2017, Jan Pazdziora wrote: > >Hello, > >on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve >new keytab for a service but they cannot retrieve the existing keys >with the -r option. Is that expected? Yes. Access to existing keys is intentionally restricted. There are additional commands that allow to set up how to grant such access based on the management of a service. There is no way to set up a blank permission for that, though, as permission is based on the specific attributes in the service entry. # ipa service-add foobar/$(hostname) -------------------------------------------------- Added service "foobar/nyx.xs.ipa.cool at XS.IPA.COOL" -------------------------------------------------- Principal name: foobar/nyx.xs.ipa.cool at XS.IPA.COOL Principal alias: foobar/nyx.xs.ipa.cool at XS.IPA.COOL Managed by: nyx.xs.ipa.cool # ipa service-allow-retrieve-keytab foobar/$(hostname) --groups=admins Principal name: foobar/nyx.xs.ipa.cool at XS.IPA.COOL Principal alias: foobar/nyx.xs.ipa.cool at XS.IPA.COOL Managed by: nyx.xs.ipa.cool Groups allowed to retrieve keytab: admins ------------------------- Number of members added 1 ------------------------- # ipa service-show foobar/$(hostname) --all --raw|grep ipaAllowedToPerform ipaAllowedToPerform;read_keys: cn=admins,cn=groups,cn=accounts,dc=xs,dc=ipa,dc=cool This is all documented very well: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/retrieve-existing-keytabs.html -- / Alexander Bokovoy From jpazdziora at redhat.com Mon Apr 17 14:38:06 2017 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 17 Apr 2017 16:38:06 +0200 Subject: [Freeipa-users] Admin cannot retrieve keytab -- is that expected? In-Reply-To: <20170417134959.vzc7hl6hcg6pyi4c@redhat.com> References: <20170417103538.GC11341@redhat.com> <20170417134959.vzc7hl6hcg6pyi4c@redhat.com> Message-ID: <20170417143806.GB22789@redhat.com> On Mon, Apr 17, 2017 at 04:49:59PM +0300, Alexander Bokovoy wrote: > On Mon, 17 Apr 2017, Jan Pazdziora wrote: > > > > Hello, > > > > on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve > > new keytab for a service but they cannot retrieve the existing keys > > with the -r option. Is that expected? > Yes. Access to existing keys is intentionally restricted. There are > additional commands that allow to set up how to grant such access based > on the management of a service. There is no way to set up a blank > permission for that, though, as permission is based on the specific > attributes in the service entry. > > # ipa service-add foobar/$(hostname) > -------------------------------------------------- > Added service "foobar/nyx.xs.ipa.cool at XS.IPA.COOL" > -------------------------------------------------- > Principal name: foobar/nyx.xs.ipa.cool at XS.IPA.COOL > Principal alias: foobar/nyx.xs.ipa.cool at XS.IPA.COOL > Managed by: nyx.xs.ipa.cool > > # ipa service-allow-retrieve-keytab foobar/$(hostname) --groups=admins > Principal name: foobar/nyx.xs.ipa.cool at XS.IPA.COOL > Principal alias: foobar/nyx.xs.ipa.cool at XS.IPA.COOL > Managed by: nyx.xs.ipa.cool > Groups allowed to retrieve keytab: admins > ------------------------- > Number of members added 1 > ------------------------- > > # ipa service-show foobar/$(hostname) --all --raw|grep ipaAllowedToPerform > ipaAllowedToPerform;read_keys: cn=admins,cn=groups,cn=accounts,dc=xs,dc=ipa,dc=cool Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From cmohler at oberlin.edu Mon Apr 17 16:12:16 2017 From: cmohler at oberlin.edu (Chris Mohler) Date: Mon, 17 Apr 2017 12:12:16 -0400 Subject: [Freeipa-users] Repair a corrupted database Message-ID: Hi List, I've got two boxes running FreeIPA 4.1.4. The Database on the first master is corrupted. Log looks like this: [17/Apr/2017:10:22:51 -0400] - libdb: BDB0689 changelog/id2entry.db page 27523 is on free list with type 5 [17/Apr/2017:10:22:51 -0400] - libdb: BDB0061 PANIC: Invalid argument [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - Serious Error---Failed in dblayer_txn_abort, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [17/Apr/2017:10:22:51 -0400] DSRetroclPlugin - replog: an error occured while adding change number 8485210, dn = changenumber=8485210,cn=changelog: Operations error. [17/Apr/2017:10:22:51 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - Serious Error---Failed in dblayer_txn_begin, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - FATAL ERROR at idl_new.c (1); server stopping as database recovery needed. Looks like it's broken. Good news is I have a replica that's working quite well. What I'd like to do is to recover the database or create a new database on the first master and then just fill it with the current data from the replica. Is this possible? As a lazy admin I'm hoping to avoid making the replica the CA and building a new replica. Can someone point me to a guide, docs or walk me through the procedure? Thanks From andrew.krause at breakthroughfuel.com Mon Apr 17 16:31:22 2017 From: andrew.krause at breakthroughfuel.com (Andrew Krause) Date: Mon, 17 Apr 2017 16:31:22 +0000 Subject: [Freeipa-users] Freeipa web UI: An error has occurred (IPA Error 4302: CertificateFormatError) Message-ID: Many hosts in our web ui show a null status for ?enrolled?. When you do a search that includes any of these host objects the web UI posts errors, and if you click on one of the problem hosts the same error stops anything from loading on the host page. I?ve been trying to solve this problem on my own for quite some time and have not been successful. It?s impossible to remove the host through the web UI and using CLI commands seem to remove the entry from IPA (host is not found with ipa host-find), but it is still visible in the UI. One thing that may be common with all of these hosts is that they were enrolled with our IPA system back while we were running version 3.0 and likely have had issues for quite some time. Multiple updates have happened since then, and all of our hosts added within the last year are working fine. I suspect there?s an issue with a path somewhere for a certificate database, but I?m unable to pinpoint what is going wrong. I?m currently cloning 2 of my IPA servers into a private dmz to test fixes so I can try things without worry... 1. Realized we had many certificates that were expired and not renewing with ?getcert list? on primary IPA server 2. Tried every document I could find on renewing the certificates but was never completely successful (on version 4.1 which is our current in production) 3. Upgraded to 4.4 and was actually able to renew all certificates listed on the main IPA server showing current below 4. After having success with #3 I was able to start the CA service without error and everything on the server seems to be working as expected 5. Have attempted many variations of removing a problem host and adding it back, but the errors in the web UI persist. Output from "getcert list": Number of certificates and requests being tracked: 8. Request ID '20160901214852': 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=DOMAIN.COM subject: CN=CA Audit,O=DOMAIN.COM expires: 2018-08-22 22:13:44 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 '20160901214853': 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=DOMAIN.COM subject: CN=OCSP Subsystem,O=DOMAIN.COM expires: 2018-08-22 21:49:26 UTC 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 '20160901214854': 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=DOMAIN.COM subject: CN=CA Subsystem,O=DOMAIN.COM expires: 2018-08-22 21:49:18 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 '20160901214855': 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=DOMAIN.COM subject: CN=Certificate Authority,O=DOMAIN.COM expires: 2036-09-01 05:05:00 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 '20160901214856': 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=DOMAIN.COM subject: CN=IPA RA,O=DOMAIN.COM expires: 2018-08-22 22:15:36 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 '20160901214857': 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=DOMAIN.COM subject: CN=hostname07.domain.com,O=DOMAIN.COM expires: 2018-07-31 23:31:17 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 "Server-Cert cert-pki-ca" track: yes auto-renew: yes Request ID '20160901214858': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DOMAIN.COM subject: CN=hostname07.domain.com,O=DOMAIN.COM expires: 2018-08-22 23:31:28 UTC principal name: ldap/hostname07.domain.com at DOMAIN.COM 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 DOMAIN-COM track: yes auto-renew: yes Request ID '20160901214859': 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=DOMAIN.COM subject: CN=hostname07.domain.com,O=DOMAIN.COM expires: 2018-08-22 23:31:19 UTC principal name: HTTP/hostname07.domain.com at DOMAIN.COM 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 Output for "certutil -L -d /var/lib/pki/pki-tomcat/alias/" Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u Certificate Authority - DOMAIN.COM CTu,cu,u subsystemCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u Output for latest selftests.log for pki-tomcatd: 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: Initializing self test plugins: 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading all self test plugin instances 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] CAPresence: CA is present 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SystemCertsVerification: system certs verification success 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: All CRITICAL self test plugins ran SUCCESSFULLY at startup! Any assistance would be greatly appreciated. Andrew Krause From keesb at ghs.com Tue Apr 18 06:13:37 2017 From: keesb at ghs.com (Kees Bakker) Date: Tue, 18 Apr 2017 08:13:37 +0200 Subject: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain in DHCP dyndns update In-Reply-To: <937703606.44906.1492270157388@vegas.jacobdevans.com> References: <937703606.44906.1492270157388@vegas.jacobdevans.com> Message-ID: <18befb13-8a17-f84c-1945-6884b2efa86c@ghs.com> It's a two level domain. BTW. Something to add. It happens with an Ubuntu Zesty (17.04) client. This has freeipa 4.4.x while the rest of the network (and server) runs with freeipa 4.3.x On 15-04-17 17:29, Jake wrote: > is your "mydomain" actually a one level tld or example.com > > ----- Original Message ----- > From: "Kees Bakker" > To: "freeipa-users" > Sent: Thursday, April 13, 2017 10:30:33 AM > Subject: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain in DHCP dyndns update > > Hey, > > Hopefully someone here can hint me towards a (easier) solution. > > In short, for correct DHCP-DDNS updates there should be a non-fqdn in /etc/hostname > To install IPA client I am forced to have a fqdn in /etc/hostname. But now the DHCP-DDNS > results in duplicated domain portion of the DNS entries. > > The details. > We have a FreeIPA environment with DNS and DHCP. I've configured bind and > dhcpd to do DDNS. For the most part it is working as expected. > > When the hostname of a system is a non-fqdn the end result is what I want to see. Say I have > /etc/hostname: test02 > then after it started up there is a new forward map (using "mydomain" here instead of the real thing). > test01 -> 172.16.16.252 > and a reverse map in 16.16.172.in-addr.arpa zone > 252 -> test02.mydomain > > Some lines from /var/log/syslog > dhcpd[82333]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 > named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' A 172.16.16.252 > dhcpd[82333]: DHCPREQUEST for 172.16.16.252 (172.16.16.75) from 00:16:3e:8e:91:12 (test02) via eno1 > dhcpd[82333]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 > named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' DHCID AAAB6QGH0W+JCSMwrj9sQVCeh5PToZAmWZvMpgiEtXHrZgE= > dhcpd[82333]: Added new forward map from test02.mydomain to 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating zone '16.16.172.in-addr.arpa/IN': adding an RR at '252.16.16.172.in-addr.arpa' PTR test02.mydomain. > dhcpd[82333]: Added reverse map from 252.16.16.172.in-addr.arpa. to test02.mydomain > > However, when I want to add this system as a IPA client I am forced to > fill in a fqdn in /etc/hostname. So I change /etc/hostname to have test01.mydomain > The provisioning succeeds and all seems well. > > But after a reboot the system requests DHCP to register as test01.mydomain. And > the DHCP server does a DNS update for test01.mydomain.mydomain. > The DNS zone for mydomain now has > test01 for all the SSHFP records > test01.mydomain for the A record > The reverse map for 16.16.172.in-addr.arpa has > 231 -> test01.mydomain.mydomain > > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain A > dhcpd[4550]: DHCPREQUEST for 172.16.16.252 from 00:16:3e:8e:91:12 (test02) via eno1 > dhcpd[4550]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02.mydomain) via eno1 > dhcpd[4550]: Removed forward map from test02.mydomain to 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain DHCID > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' A 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' DHCID AAAB+5EmVxuf4utDMDZxjqAiqIds6Briv5awEp5W3whNsLc= > dhcpd[4550]: Added new forward map from test02.mydomain.mydomain to 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone '16.16.172.in-addr.arpa/IN': adding an RR at '252.16.16.172.in-addr.arpa' PTR test02.mydomain.mydomain. > dhcpd[4550]: Added reverse map from 252.16.16.172.in-addr.arpa. to test02.mydomain.mydomain > > > To work around I then change the /etc/hostname back to test01, restart > the network and everything if fine afterwards. > > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain A > dhcpd[4550]: DHCPRELEASE of 172.16.16.252 from 00:16:3e:8e:91:12 (test02.mydomain) via eno1 (found) > dhcpd[4550]: Removed forward map from test02.mydomain.mydomain to 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain DHCID > dhcpd[4550]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': update unsuccessful: test02.mydomain: 'name not in use' prerequisite not satisfied (YXDOMAIN) > dhcpd[4550]: DHCPREQUEST for 172.16.16.252 (172.16.16.75) from 00:16:3e:8e:91:12 (test02) via eno1 > dhcpd[4550]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting rrset at 'test02.mydomain' DHCID > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' DHCID AAAB6QGH0W+JCSMwrj9sQVCeh5PToZAmWZvMpgiEtXHrZgE= > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': deleting rrset at 'test02.mydomain' A > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone 'mydomain/IN': adding an RR at 'test02.mydomain' A 172.16.16.252 > dhcpd[4550]: Added new forward map from test02.mydomain to 172.16.16.252 > named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating zone '16.16.172.in-addr.arpa/IN': adding an RR at '252.16.16.172.in-addr.arpa' PTR test02.mydomain. > dhcpd[4550]: Added reverse map from 252.16.16.172.in-addr.arpa. to test02.mydomain From david.goudet at lyra-network.com Mon Apr 17 17:42:34 2017 From: david.goudet at lyra-network.com (David Goudet) Date: Mon, 17 Apr 2017 19:42:34 +0200 Subject: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address In-Reply-To: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> References: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> Message-ID: Hi, Nobody has response about my questions? The main question is: Is it possible to configure SSSD to update DNS (option dyndns_update) with only IP address "primary" in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP binding)? Thank you for your help. Best regards, On 03/27/2017 06:34 PM, David Goudet wrote: > Hi, > > Thanks to dyndns_update=True parameter, SSSD service on client machine updating host DNS entry in FreeIPA. > Everything is fine on machines which have only one IP adress on network interface. > I have problem with machines which have more that one IP address on network interface: if machine have two IP address, SSSD update host DNS entry with these two IP address. > > To reproduce the problem: > Host have -IP1- and i add -IP2- > ip addr add -IP2-/26 dev em1 > > ip addr list: > em1: mtu 1496 qdisc mq state UP qlen 1000 > link/ether xxxx > inet -IP1-/26 brd XXXX scope global em1 > inet -IP2-/26 scope global secondary em1 > valid_lft forever preferred_lft forever > > DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting sssd returns -IP1- & -IP2- > > In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used for the updates", what does it means? Is it IP address of the DNS server (used to update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind (-IP1- in my case)? > > dyndns_update (boolean) > Optional. This option tells SSSD to automatically update the DNS server built into FreeIPA v2 with the IP address of this client. > The update is secured using GSS-TSIG. The IP address of the IPA LDAP connection is used for the updates, if it is not otherwise > specified by using the ?dyndns_iface? option. > > Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on client machine? > Is it possible to configure SSSD to update DNS with only IP address "primary" in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP binding)? > > My environment is: > Client: Centos 7.2 > sssd-common-1.13.0-40.el7_2.12.x86_64 > sssd-ipa-1.13.0-40.el7_2.12.x86_64 > sssd-1.13.0-40.el7_2.12.x86_64 > sssd-client-1.13.0-40.el7_2.12.x86_64 > FreeIPA server: Centos 6.7 > ipa-server-3.0.0-47.el6.centos.2.x86_64 > bind-9.8.2-0.30.rc1.el6_6.3.x86_64 > bind-utils-9.8.2-0.37.rc1.el6_7.7.x86_64 > bind-libs-9.8.2-0.37.rc1.el6_7.7.x86_64 > rpcbind-0.2.0-11.el6_7.x86_64 > bind-libs-9.8.2-0.30.rc1.el6_6.3.x86_64 > rpcbind-0.2.0-11.el6.x86_64 > bind-dyndb-ldap-2.3-8.el6.x86_64 > bind-9.8.2-0.37.rc1.el6_7.7.x86_64 > > > SSSD configuration on client: > [domain/] > > debug_level=18 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > chpass_provider = ipa > dyndns_update = True > ipa_server = _srv_, ds01., ds01. > dns_discovery_domain = > > > Named FreeIPA logs: > ------------------- > Mar 27 17:03:57 ds01. named[6607]: client -IP1-#36331: updating zone '/IN': deleting rrset at '' A > Mar 27 17:03:57 ds01. named[6607]: update_record (psearch) failed, dn 'idnsName=2,idnsname=.in-addr.arpa.,cn=dns,dc=yyy,dc=xxx' change type 0x4. Records can be outdated, run `rndc reload`: not found > Mar 27 17:03:57 ds01. named[6607]: zone /IN: sending notifies (serial 1490615011) > Mar 27 17:03:57 ds01. named[6607]: client -IP1-#46187: updating zone '/IN': deleting rrset at '.' AAAA > Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating zone '/IN': adding an RR at '.' A > Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating zone '/IN': adding an RR at '.' A > Mar 27 17:03:57 ds01. named[6607]: zone .in-addr.arpa/IN: sending notifies (serial 1490627037) > Mar 27 17:04:02 ds01. named[6607]: zone /IN: sending notifies (serial 1490627038) > > SSSD trace log on client during sssd restart: > ----------------------- > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [ipa_dyndns_update_send] (0x0400): Performing update > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] (0x4000): [.] does not look like an IP address > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of '.' in DNS > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [request_watch_destructor] (0x0400): Deleting request watch > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] (0x4000): [.] does not look like an IP address > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve AAAA record of '.' in DNS > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [request_watch_destructor] (0x0400): Deleting request watch > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_next] (0x0100): No more hosts databases to retry > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_dyndns_addrs_diff] (0x1000): Address on localhost only: -IP2- > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_dyndns_dns_addrs_done] (0x0400): Detected IP addresses change, will perform an update > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm []. > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- > realm > update delete .. in A > send > update delete .. in AAAA > send > update add .. 1200 in A -IP2- > update add .. 1200 in A -IP1- > send > -- End nsupdate message -- > .. > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [nsupdate_msg_create_common] (0x0200): Creating update message for server [ds01.] and realm []. > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- > server ds01. > realm > update delete .. in A > send > update delete .. in AAAA > send > update add .. 1200 in A -IP2- > update add .. 1200 in A -IP1- > send > -- End nsupdate message -- > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [20631] > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] (0x2000): Signal handler set up for pid [20631] > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [write_pipe_handler] (0x0400): All data has been sent! > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete > (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_args] (0x0200): nsupdate auth type: GSS-TSIG > setup_system() > > Thank you for your help! > From umarzuki at gmail.com Tue Apr 18 08:36:24 2017 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Tue, 18 Apr 2017 16:36:24 +0800 Subject: [Freeipa-users] renewing cert and migrating free-ipa 3.1 In-Reply-To: References: Message-ID: Now users complaining that passwords that have been reset cannot be used to log in. I also tried resubmit getcert but 2 resubmit failed [root at ipa ~]# getcert list Number of certificates and requests being tracked: 7. Request ID '20130112120226': 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='932018712055' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=DOA.GOV.MY subject: CN=CA Audit,O=DOA.GOV.MY expires: 2016-11-24 16:19:25 UTC pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130112120227': 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='932018712055' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=DOA.GOV.MY subject: CN=OCSP Subsystem,O=DOA.GOV.MY expires: 2016-11-24 16:18:25 UTC eku: id-kp-OCSPSigning pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130112120228': 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='932018712055' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=DOA.GOV.MY subject: CN=CA Subsystem,O=DOA.GOV.MY expires: 2016-11-24 16:18:25 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130112120229': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=DOA.GOV.MY subject: CN=IPA RA,O=DOA.GOV.MY expires: 2016-11-24 16:18:25 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20130112120230': 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='932018712055' 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=DOA.GOV.MY subject: CN=ipa.domain.com.my,O=DOA.GOV.MY expires: 2016-11-24 16:18:25 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_pkicad "Server-Cert cert-pki-ca" track: yes auto-renew: yes Request ID '20130112120232': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DOA.GOV.MY subject: CN=ipa.domain.com.my,O=DOA.GOV.MY expires: 2016-12-16 16:18:27 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv DOMAIN-COM-MY track: yes auto-renew: yes Request ID '20130112120734': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)). stuck: yes 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=DOA.GOV.MY subject: CN=ipa.domain.com.my,O=DOA.GOV.MY expires: 2016-12-16 16:18:27 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes What are my options? 2017-03-03 21:20 GMT+08:00 Umarzuki Mochlis : > At first ip-getcert list hows certificate error > > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction, explaining: Peer's Certificate has > expired.). > > but after I changed ipa server's date to before expirate date, it shows > > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction, explaining: couldn't connect to > host). > > when I tried to start ipa with "service ipa start", all services would > fail, so I need to start one by one > > systemctl start dirsrv at DOMAIN-COM-MY.service > systemctl status dirsrv at DOMAIN-COM-MY.service > systemctl start krb5kdc.service > systemctl status krb5kdc.service > systemctl start kadmin.service > systemctl status kadmin.service > systemctl start ipa_memcached.service > systemctl status ipa_memcached.service > systemctl start pki-tomcatd at pki-tomcat.service > systemctl status pki-tomcatd at pki-tomcat.service > > > # tail /var/log/messages > Jan 3 17:32:26 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... > Jan 3 17:32:29 ipa systemd[1]: Started PKI Tomcat Server pki-tomcat. > Jan 3 17:33:08 ipa certmonger[476]: 2016-01-03 17:33:08 [476] Server > failed request, will retry: -504 (libcurl failed to execute the HTTP > POST transaction, explaining: couldn't connect to host). > Jan 3 17:33:12 ipa certmonger[476]: 2016-01-03 17:33:12 [476] Server > failed request, will retry: -504 (libcurl failed to execute the HTTP > POST transaction, explaining: couldn't connect to host). > > 2017-03-03 13:20 GMT+08:00 Umarzuki Mochlis : >> After httpd failed to start even with "NSSEnforceValidCerts off" in >> /etc/httpd/conf.d/nss.conf >> It used to work for a while since we use this only for zimbra but >> today it won't start anymore. >> >> We are not using commercial certs, so which steps should I follow to >> renew certs? >> >> It seems CA has expired more than 2 weeks ago. >> >> # ipa-getcert list >> Number of certificates and requests being tracked: 7. >> Request ID '20130112120232': >> status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: -504 (libcurl >> failed to execute the HTTP POST transaction, explaining: Peer's >> Certificate has expired.). >> stuck: yes >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS >> Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=DOMAIN.COM.MY >> subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY >> expires: 2016-12-16 16:18:27 UTC >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >> DOMAIN-COM-MY >> track: yes >> auto-renew: yes >> Request ID '20130112120734': >> status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: -504 (libcurl >> failed to execute the HTTP POST transaction, explaining: Peer's >> Certificate has expired.). >> stuck: yes >> 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=DOMAIN.COM.MY >> subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY >> expires: 2016-12-16 16:18:27 UTC >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> # rpm -qa | grep ipa >> freeipa-admintools-3.1.0-2.fc18.x86_64 >> freeipa-server-3.1.0-2.fc18.x86_64 >> libipa_hbac-python-1.9.3-1.fc18.x86_64 >> python-iniparse-0.4-6.fc18.noarch >> freeipa-client-3.1.0-2.fc18.x86_64 >> freeipa-server-selinux-3.1.0-2.fc18.x86_64 >> freeipa-python-3.1.0-2.fc18.x86_64 >> libipa_hbac-1.9.3-1.fc18.x86_64 From umarzuki at gmail.com Tue Apr 18 08:38:25 2017 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Tue, 18 Apr 2017 16:38:25 +0800 Subject: [Freeipa-users] renewing cert and migrating free-ipa 3.1 In-Reply-To: References: Message-ID: please ignore that domain because I did not mask it properly From jpazdziora at redhat.com Tue Apr 18 08:41:27 2017 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 18 Apr 2017 10:41:27 +0200 Subject: [Freeipa-users] Using different HTTP/ principal for FreeIPA WebUI Message-ID: <20170418084127.GM30809@redhat.com> Hello, I'm setting up two FreeIPA replicas with load balancer in front of them per https://www.adelton.com/freeipa/freeipa-behind-load-balancer Things work when authenticating with login and password. I then want to enable GSSAPI/Negotiate for the WebUI. For that, I create host and service for the load balancer (webipa.example.com and HTTP/webipa.example.com), I add the principal to the ipa-http-delegation rule via ipa servicedelegationrule-add-member ipa-http-delegation --principals=HTTP/webipa.example.com and I fetch the keytab for the principal on the backend nodes. When I replace the original /etc/httpd/conf/ipa.keytab file with the new keytab with just the keys for HTTP/webipa.example.com, I can authenticate with my Firefox via Kerberos. However, I'm afraid that by removing the original keys for HTTP/ipa1.int.example.com (resp. HTTP/ipa2.int.example.com) principal from /etc/httpd/conf/ipa.keytab, I might break something, at least the ability to access those backend machines via GSSAPI directly (not via the load balancer). When I add the frontend keys to the original keytab file with ktutil with read_kt /etc/httpd/conf/frontend.keytab write_kt /etc/httpd/conf/ipa.keytab quit authentication fails with ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Matching credential not found (filename: /var/run/ipa_memcached/krbcc_1222)) When I try to start with the frontend.keytab content by copying it over to ipa.keytab and append the backend keyts to that file -- then I can Kerberos-authenticate via the frontend but not with going to the backend URL directly. So it looks like only the first principal in the keytab is considered at whatever stage which fails during the GSSAPI authentication. Any hints as to how to debug the setup further would be appreciated. This is with freeipa-server-4.4.4-1.fc25. Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From umarzuki at gmail.com Tue Apr 18 08:46:18 2017 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Tue, 18 Apr 2017 16:46:18 +0800 Subject: [Freeipa-users] renewing cert and migrating free-ipa 3.1 In-Reply-To: References: Message-ID: below are from httpd error log [Thu Feb 18 16:28:06.351007 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: user_find(u'yusma', sizelimit=0, pkey_only=True): SUCCESS [Thu Feb 18 16:28:06.400453 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch: user_show(u'nisa', all=True): SUCCESS [Thu Feb 18 16:28:06.412753 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch: user_show(u'noryusmaniza', all=True): SUCCESS [Thu Feb 18 16:28:06.428103 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch: user_show(u'yusmayusof', all=True): SUCCESS [Thu Feb 18 16:28:06.428335 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch(({u'params': [[u'nisa'], {u'all': True}], u'method': u'user_show'}, {u'params': [[u'noryusmaniza'], {u'all': True}], u'method': u'user_show'}, {u'params': [[u'yusmayusof'], {u'all': True}], u'method': u'user_show'})): SUCCESS [Thu Feb 18 16:28:09.254484 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch: user_show(u'yusmayusof', rights=True, all=True): SUCCESS [Thu Feb 18 16:28:09.308107 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch: pwpolicy_show(None, rights=True, user=u'yusmayusof', all=True): SUCCESS [Thu Feb 18 16:28:09.416227 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch: krbtpolicy_show(u'yusmayusof', rights=True, all=True): SUCCESS [Thu Feb 18 16:28:09.416483 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch(({u'params': [[u'yusmayusof'], {u'all': True, u'rights': True}], u'method': u'user_show'}, {u'params': [[], {u'all': True, u'user': u'yusmayusof', u'rights': True}], u'method': u'pwpolicy_show'}, {u'params': [[u'yusmayusof'], {u'all': True, u'rights': True}], u'method': u'krbtpolicy_show'})): SUCCESS [Thu Feb 18 16:28:09.921130 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: user_find(None): SUCCESS [Thu Feb 18 16:28:27.176668 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: passwd(u'yusmayusof', u'********', None): SUCCESS [Thu Feb 18 16:28:27.331989 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch: user_show(u'yusmayusof', rights=True, all=True): SUCCESS [Thu Feb 18 16:28:27.382532 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch: pwpolicy_show(None, rights=True, user=u'yusmayusof', all=True): SUCCESS [Thu Feb 18 16:28:27.486929 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch: krbtpolicy_show(u'yusmayusof', rights=True, all=True): SUCCESS [Thu Feb 18 16:28:27.487178 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: batch(({u'params': [[u'yusmayusof'], {u'all': True, u'rights': True}], u'method': u'user_show'}, {u'params': [[], {u'all': True, u'user': u'yusmayusof', u'rights': True}], u'method': u'pwpolicy_show'}, {u'params': [[u'yusmayusof'], {u'all': True, u'rights': True}], u'method': u'krbtpolicy_show'})): SUCCESS [Thu Feb 18 16:28:27.969435 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: user_find(None): SUCCESS [Thu Feb 18 16:29:22.017394 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: passwd(u'yusmayusof', u'********', None): SUCCESS [Thu Feb 18 16:29:22.169817 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch: user_show(u'yusmayusof', rights=True, all=True): SUCCESS [Thu Feb 18 16:29:22.221379 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch: pwpolicy_show(None, rights=True, user=u'yusmayusof', all=True): SUCCESS [Thu Feb 18 16:29:22.325846 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch: krbtpolicy_show(u'yusmayusof', rights=True, all=True): SUCCESS [Thu Feb 18 16:29:22.326098 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: batch(({u'params': [[u'yusmayusof'], {u'all': True, u'rights': True}], u'method': u'user_show'}, {u'params': [[], {u'all': True, u'user': u'yusmayusof', u'rights': True}], u'method': u'pwpolicy_show'}, {u'params': [[u'yusmayusof'], {u'all': True, u'rights': True}], u'method': u'krbtpolicy_show'})): SUCCESS [Thu Feb 18 16:29:22.801354 2016] [:error] [pid 311] ipa: INFO: admin at DOMAIN.COM.MY: user_find(None): SUCCESS [Thu Feb 18 16:31:55.029022 2016] [:error] [pid 310] ipa: ERROR: AuthManager.logout.xmlserver_session: session_data does not contain ccache_data [Thu Feb 18 16:31:55.029222 2016] [:error] [pid 310] ipa: INFO: admin at DOMAIN.COM.MY: session_logout(): SUCCESS [Thu Feb 18 16:35:35.585717 2016] [:error] [pid 377] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate [Thu Feb 18 16:36:59.015795 2016] [auth_kerb:error] [pid 377] [client 10.19.82.43:54553] gss_accept_sec_context() failed: No credentials were supplied, or the credentials were unavailable or inaccessible (, Unknown error), referer: https://ipa.domain.com.my/ipa/ui/ [root at ipa ~]# date Thu Feb 18 16:37:19 MYT 2016 From dsiluri at sapient.com Tue Apr 18 09:49:00 2017 From: dsiluri at sapient.com (Davide Siluri) Date: Tue, 18 Apr 2017 09:49:00 +0000 Subject: [Freeipa-users] ipa-server-install fails at client phase In-Reply-To: <1492182724832.626@sapient.com> References: <1492182724832.626@sapient.com> Message-ID: <1492508938816.22222@sapient.com> ________________________________ From: Davide Siluri Sent: 14 April 2017 17:12 To: freeipa-users at redhat.com Subject: [Freeipa-users] ipa-server-install fails at client phase Hello Ryan, I had that same issue with FreeIPA 4.4 on RH 7.3. ? In my case IPA installation linked a wrong dependency with python36u-mod_wsgi. Remove python36u package and install mod_wsgi (in my case mod_wsgi-3.4-12.el7_0.x86_64) before running IPA install procedure again. That should solve the problem. Regards Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 18 14:07:20 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Apr 2017 10:07:20 -0400 Subject: [Freeipa-users] renewing cert and migrating free-ipa 3.1 In-Reply-To: References: Message-ID: <306e8b3f-3576-37c1-3ee4-835c4c385680@redhat.com> Umarzuki Mochlis wrote: > Now users complaining that passwords that have been reset cannot be > used to log in. Passwords are completely unrelated to expired certificates. Wow, this is really quite an old install. The error message about communicating with CMS suggests that the CA isn't really up. The dogtag debug log may contain more details on that. What is the output when you use ipactl to restart the services? I have the feeling it is catching an error that your manual restart is not. I'd also not set the date back so far. It won't hurt but it will be the starting date for new certificates so you'd be cheating yourself out of 8 or so months. I'd also look at the RA agent cert to be sure it is currently correct: $ ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b uid=ipara,ou=People,o=ipaca description $ certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial The description field from the ldapsearch has the format: 2;;; The serial numbers should match. Don't do anything if they don't, just report back the result. rob > I also tried resubmit getcert but 2 resubmit failed > > [root at ipa ~]# getcert list > Number of certificates and requests being tracked: 7. > Request ID '20130112120226': > 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='932018712055' > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=DOA.GOV.MY > subject: CN=CA Audit,O=DOA.GOV.MY > expires: 2016-11-24 16:19:25 UTC > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130112120227': > 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='932018712055' > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=DOA.GOV.MY > subject: CN=OCSP Subsystem,O=DOA.GOV.MY > expires: 2016-11-24 16:18:25 UTC > eku: id-kp-OCSPSigning > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130112120228': > 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='932018712055' > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=DOA.GOV.MY > subject: CN=CA Subsystem,O=DOA.GOV.MY > expires: 2016-11-24 16:18:25 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130112120229': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=DOA.GOV.MY > subject: CN=IPA RA,O=DOA.GOV.MY > expires: 2016-11-24 16:18:25 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20130112120230': > 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='932018712055' > 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=DOA.GOV.MY > subject: CN=ipa.domain.com.my,O=DOA.GOV.MY > expires: 2016-11-24 16:18:25 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_pkicad > "Server-Cert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130112120232': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 4301 (RPC failed at > server. Certificate operation cannot be completed: Unable to > communicate with CMS (Internal Server Error)). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=DOA.GOV.MY > subject: CN=ipa.domain.com.my,O=DOA.GOV.MY > expires: 2016-12-16 16:18:27 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv DOMAIN-COM-MY > track: yes > auto-renew: yes > Request ID '20130112120734': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 4301 (RPC failed at > server. Certificate operation cannot be completed: Unable to > communicate with CMS (Internal Server Error)). > stuck: yes > 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=DOA.GOV.MY > subject: CN=ipa.domain.com.my,O=DOA.GOV.MY > expires: 2016-12-16 16:18:27 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > What are my options? > > > 2017-03-03 21:20 GMT+08:00 Umarzuki Mochlis : >> At first ip-getcert list hows certificate error >> >> ca-error: Server failed request, will retry: -504 (libcurl failed to >> execute the HTTP POST transaction, explaining: Peer's Certificate has >> expired.). >> >> but after I changed ipa server's date to before expirate date, it shows >> >> ca-error: Server failed request, will retry: -504 (libcurl failed to >> execute the HTTP POST transaction, explaining: couldn't connect to >> host). >> >> when I tried to start ipa with "service ipa start", all services would >> fail, so I need to start one by one >> >> systemctl start dirsrv at DOMAIN-COM-MY.service >> systemctl status dirsrv at DOMAIN-COM-MY.service >> systemctl start krb5kdc.service >> systemctl status krb5kdc.service >> systemctl start kadmin.service >> systemctl status kadmin.service >> systemctl start ipa_memcached.service >> systemctl status ipa_memcached.service >> systemctl start pki-tomcatd at pki-tomcat.service >> systemctl status pki-tomcatd at pki-tomcat.service >> >> >> # tail /var/log/messages >> Jan 3 17:32:26 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... >> Jan 3 17:32:29 ipa systemd[1]: Started PKI Tomcat Server pki-tomcat. >> Jan 3 17:33:08 ipa certmonger[476]: 2016-01-03 17:33:08 [476] Server >> failed request, will retry: -504 (libcurl failed to execute the HTTP >> POST transaction, explaining: couldn't connect to host). >> Jan 3 17:33:12 ipa certmonger[476]: 2016-01-03 17:33:12 [476] Server >> failed request, will retry: -504 (libcurl failed to execute the HTTP >> POST transaction, explaining: couldn't connect to host). >> >> 2017-03-03 13:20 GMT+08:00 Umarzuki Mochlis : >>> After httpd failed to start even with "NSSEnforceValidCerts off" in >>> /etc/httpd/conf.d/nss.conf >>> It used to work for a while since we use this only for zimbra but >>> today it won't start anymore. >>> >>> We are not using commercial certs, so which steps should I follow to >>> renew certs? >>> >>> It seems CA has expired more than 2 weeks ago. >>> >>> # ipa-getcert list >>> Number of certificates and requests being tracked: 7. >>> Request ID '20130112120232': >>> status: CA_UNREACHABLE >>> ca-error: Server failed request, will retry: -504 (libcurl >>> failed to execute the HTTP POST transaction, explaining: Peer's >>> Certificate has expired.). >>> stuck: yes >>> key pair storage: >>> type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS >>> Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt' >>> certificate: >>> type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS >>> Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=DOMAIN.COM.MY >>> subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY >>> expires: 2016-12-16 16:18:27 UTC >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >>> DOMAIN-COM-MY >>> track: yes >>> auto-renew: yes >>> Request ID '20130112120734': >>> status: CA_UNREACHABLE >>> ca-error: Server failed request, will retry: -504 (libcurl >>> failed to execute the HTTP POST transaction, explaining: Peer's >>> Certificate has expired.). >>> stuck: yes >>> 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=DOMAIN.COM.MY >>> subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY >>> expires: 2016-12-16 16:18:27 UTC >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>> track: yes >>> auto-renew: yes >>> >>> # rpm -qa | grep ipa >>> freeipa-admintools-3.1.0-2.fc18.x86_64 >>> freeipa-server-3.1.0-2.fc18.x86_64 >>> libipa_hbac-python-1.9.3-1.fc18.x86_64 >>> python-iniparse-0.4-6.fc18.noarch >>> freeipa-client-3.1.0-2.fc18.x86_64 >>> freeipa-server-selinux-3.1.0-2.fc18.x86_64 >>> freeipa-python-3.1.0-2.fc18.x86_64 >>> libipa_hbac-1.9.3-1.fc18.x86_64 > From ftweedal at redhat.com Wed Apr 19 02:56:40 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 19 Apr 2017 12:56:40 +1000 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: <20170419025640.GH21957@dhcp-40-8.bne.redhat.com> On Thu, Apr 13, 2017 at 04:49:59PM +0200, Tiemen Ruiten wrote: > Hello! > > As I understand from this > > thread, > it should be possible to setup a trust between FreeIPA and Samba4. My AD > domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain, > i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC to > one of the FreeIPA replica's and lookup of SRV records in both domains > appears to work. > > However when I try to add the trust I get "ipa: ERROR an internal error has > occurred". I ran the trust-add command with full debug logging as described > on https://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust, > so I can provide these logs privately upon request. > We do not yet support trusts to Samba 4 AD DC. It is an open ticket: https://pagure.io/freeipa/issue/4866 I do not think it is a priority at this time. Alexander (Cc) could possibly provide an update. Thanks, Fraser > I suspect some DNS-issue, as right after I try to setup the trust, dynamic > updates stop working on the AD Domain Controller with this error: > > tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor > code may provide more information, Minor = Server DNS/ > fluorine.clients.i.rdmedia.com at I.RDMEDIA.COM not found in Kerberos database. > Failed nsupdate: 1 > update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._ > sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com > 389 > Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._ > sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com > 389 (add) > Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 > ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 > ;; UPDATE SECTION: > _ldap._tcp.Default-First-Site-Name._ > sites.ForestDnsZones.clients.i.rdmedia.com. 900 IN SRV 0 100 389 > fluorine.clients.i.rdmedia.com. > > Many thanks in advance for your assistance. > > > -- > 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 From mbasti at redhat.com Wed Apr 19 07:59:54 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Wed, 19 Apr 2017 09:59:54 +0200 Subject: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled In-Reply-To: References: Message-ID: <3a293c5f-a76f-bdb9-a52a-757badc956bc@redhat.com> On 13.04.2017 22:50, Dan Dietterich wrote: > > I am seeing inconsistent results configuring a DNS forward zone. > > At a bash prompt, as root, after kinit admin, I do: > > ipa dnsforwardzone-add domain.internal --forwarder= ww.xx.yy.zz > --forward-policy=only > > That works fine and does not warn about DNSSEC. > > In a Java webapp running as root under a Jetty, I run a shell > sub-process and issue the kinit and the same ipa statement. > > _/Sometimes/_, I get > > ipa: WARNING: DNSSEC validation failed: record 'domain.internal. SOA' > failed DNSSEC validation on server ww.xx.yy.zz. > > Please verify your DNSSEC configuration or disable DNSSEC validation > on all IPA servers. > > I modified the /etc/named.conf file to say: > > dnssec-enable no; > > dnssec-validation no; > > and systemctl restart ipa > > Any clue why the results are different? > > ipa ?version: VERSION: 4.4.0, API_VERSION: 2.213 > > Linux ? 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > > Thanks for any insight! > > Regards, > > Dan > > > Hello, checks are done on IPA server side, how many servers do you have? Is possible that CLI connects to different servers. However in this case, DNSSEC check should always fail and report error, so it is weird why it passed. Martin -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldw at ronzo.at Wed Apr 19 08:03:12 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Wed, 19 Apr 2017 10:03:12 +0200 Subject: [Freeipa-users] How to use automounted home shares? Message-ID: <9a4f1146-a177-97d2-1247-cb67e94f082d@ronzo.at> Hi, I am implementing automounted home shares for all my IPA users. When thinking a little more about the topic two fundamental questions arose: - Is it a good idea to automount /home even if no local users exist at the moment? - Would it be better to leave local users in /home and place IPA users to e.g. /mnt/ipausers/home In both cases an IPA user would have 1 homedirectory for all ipa machines. This would mean 1 set of configuration files for RHEL 6/7, CentOS 6/7, Suse, Ubuntu and maybe some new distros to come at some point in time. Is this a good idea? How to solve the problem that some files (e.g. .profile or .bash_history) do only make sense on a per-host basis whereas others can be centrally managed? Your thoughts on this matter are highly appreciated! Regards, Ronald From mbasti at redhat.com Wed Apr 19 08:28:54 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Wed, 19 Apr 2017 10:28:54 +0200 Subject: [Freeipa-users] DM Password Change & Password Storage In-Reply-To: References: Message-ID: <7c02a46a-3774-f136-9426-b2b876d3bb65@redhat.com> On 12.04.2017 23:06, Jeremy Utley wrote: > Hello all! We've got 2 replicated instances of FreeIPA 4.4.0 from the > EPEL repository running on fully-updated CentOS 7 instances. We're > going thru an audit right now, and I have to provide some proof of > certain things related to IPA to our auditors. Unfortunately, the > person who originally set these up evidently did not document the > Directory Manager password in our docs, so I was forced to reset this > password, using the process at: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > > This was successful, and I can now bind to the DS with the new > password. I'm now trying to follow the steps at: > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > A few things are rather confusing to me. I've tried Google searching > without much luck either. So hopefully you guys can answer a few > questions for me. > > 1) First off, the doc says: > > 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 > > So do I even need to perform these steps at all, considering I'm well > beyond 3.2.2. We don't have any intention of running > ipa-replica-prepare for the forseeable future (we shouldn't ever need > to add a third directory server here). > > 2) The first step (Update LDAP bind password) seems to indicate you're > adding the new password in clear-text to the password.conf file - this > seems like a major security issue. Am I misunderstanding what is being > requested here? The old password is not in this file (All my current > files have is lines for "internal" and "replicationdb" > > 3) The next step regenerates the cacert.p12 file, but seems to do > nothing with it, just leaves it sitting in /root - what should be done > with this file afterward? > > Thanks for any help you can give! > > Jeremy Utley > > Hello, you have to follow only this howto http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html The PKI parts are relevant only for old IPA servers, so with newer versions there is no need to manually update pki servers. Martin -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Apr 19 10:31:03 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Wed, 19 Apr 2017 12:31:03 +0200 Subject: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address In-Reply-To: References: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> Message-ID: On 17.04.2017 19:42, David Goudet wrote: > Hi, > > Nobody has response about my questions? > > The main question is: Is it possible to configure SSSD to update DNS > (option dyndns_update) with only IP address "primary" in ip addr list > or which is used to FreeIPA server communication (-IP1- used on TCP > binding)? > > Thank you for your help. > > Best regards, > > > On 03/27/2017 06:34 PM, David Goudet wrote: >> Hi, >> >> Thanks to dyndns_update=True parameter, SSSD service on client >> machine updating host DNS entry in FreeIPA. >> Everything is fine on machines which have only one IP adress on >> network interface. >> I have problem with machines which have more that one IP address on >> network interface: if machine have two IP address, SSSD update host >> DNS entry with these two IP address. >> >> To reproduce the problem: >> Host have -IP1- and i add -IP2- >> ip addr add -IP2-/26 dev em1 >> >> ip addr list: >> em1: mtu 1496 qdisc mq state UP >> qlen 1000 >> link/ether xxxx >> inet -IP1-/26 brd XXXX scope global em1 >> inet -IP2-/26 scope global secondary em1 >> valid_lft forever preferred_lft forever >> >> DNS resolution (dig) before restarting sssd returns only -IP1-. After >> restarting sssd returns -IP1- & -IP2- >> >> In dyndns_update manpage, we have "The IP address of the IPA LDAP >> connection is used for the updates", what does it means? Is it IP >> address of the DNS server (used to update the DNS entry)? or is it IP >> address on client machine used during LDAP TCP bind (-IP1- in my case)? >> >> dyndns_update (boolean) >> Optional. This option tells SSSD to automatically update >> the DNS server built into FreeIPA v2 with the IP address of this client. >> The update is secured using GSS-TSIG. The IP address of >> the IPA LDAP connection is used for the updates, if it is not otherwise >> specified by using the ?dyndns_iface? option. >> >> Is it normal behaviour that SSSD add in host DNS entry every IPs >> enabled on client machine? >> Is it possible to configure SSSD to update DNS with only IP address >> "primary" in ip addr list or which is used to FreeIPA server >> communication (-IP1- used on TCP binding)? >> >> My environment is: >> Client: Centos 7.2 >> sssd-common-1.13.0-40.el7_2.12.x86_64 >> sssd-ipa-1.13.0-40.el7_2.12.x86_64 >> sssd-1.13.0-40.el7_2.12.x86_64 >> sssd-client-1.13.0-40.el7_2.12.x86_64 >> FreeIPA server: Centos 6.7 >> ipa-server-3.0.0-47.el6.centos.2.x86_64 >> bind-9.8.2-0.30.rc1.el6_6.3.x86_64 >> bind-utils-9.8.2-0.37.rc1.el6_7.7.x86_64 >> bind-libs-9.8.2-0.37.rc1.el6_7.7.x86_64 >> rpcbind-0.2.0-11.el6_7.x86_64 >> bind-libs-9.8.2-0.30.rc1.el6_6.3.x86_64 >> rpcbind-0.2.0-11.el6.x86_64 >> bind-dyndb-ldap-2.3-8.el6.x86_64 >> bind-9.8.2-0.37.rc1.el6_7.7.x86_64 >> >> >> SSSD configuration on client: >> [domain/] >> >> debug_level=18 >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ldap_tls_cacert = /etc/ipa/ca.crt >> chpass_provider = ipa >> dyndns_update = True >> ipa_server = _srv_, ds01., ds01. >> dns_discovery_domain = >> >> >> Named FreeIPA logs: >> ------------------- >> Mar 27 17:03:57 ds01. named[6607]: client -IP1-#36331: >> updating zone '/IN': deleting rrset at '> ZONE>' A >> Mar 27 17:03:57 ds01. named[6607]: update_record >> (psearch) failed, dn >> 'idnsName=2,idnsname=.in-addr.arpa.,cn=dns,dc=yyy,dc=xxx' >> change type 0x4. Records can be outdated, run `rndc reload`: not found >> Mar 27 17:03:57 ds01. named[6607]: zone /IN: >> sending notifies (serial 1490615011) >> Mar 27 17:03:57 ds01. named[6607]: client -IP1-#46187: >> updating zone '/IN': deleting rrset at >> '.' AAAA >> Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: >> updating zone '/IN': adding an RR at >> '.' A >> Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: >> updating zone '/IN': adding an RR at >> '.' A >> Mar 27 17:03:57 ds01. named[6607]: zone >> .in-addr.arpa/IN: sending notifies (serial 1490627037) >> Mar 27 17:04:02 ds01. named[6607]: zone /IN: >> sending notifies (serial 1490627038) >> >> SSSD trace log on client during sssd restart: >> ----------------------- >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [ipa_dyndns_update_send] (0x0400): Performing update >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [sdap_id_op_connect_step] (0x4000): reusing cached connection >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_destroy] >> (0x4000): releasing operation connection >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] >> (0x4000): [.] does not look like an IP address >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [resolv_gethostbyname_step] (0x2000): Querying DNS >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record >> of '.' in DNS >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [request_watch_destructor] (0x0400): Deleting request watch >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] >> (0x4000): [.] does not look like an IP address >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [resolv_gethostbyname_step] (0x2000): Querying DNS >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve AAAA >> record of '.' in DNS >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [request_watch_destructor] (0x0400): Deleting request watch >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [resolv_gethostbyname_next] (0x0200): No more address families to retry >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [resolv_gethostbyname_next] (0x0100): No more hosts databases to retry >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [sdap_dyndns_addrs_diff] (0x1000): Address on localhost only: -IP2- >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [sdap_dyndns_dns_addrs_done] (0x0400): Detected IP addresses change, >> will perform an update >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [nsupdate_msg_create_common] (0x0200): Creating update message for >> realm []. >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- >> realm >> update delete .. in A >> send >> update delete .. in AAAA >> send >> update add .. 1200 in A -IP2- >> update add .. 1200 in A -IP1- >> send >> -- End nsupdate message -- >> .. >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [nsupdate_msg_create_common] (0x0200): Creating update message for >> server [ds01.] and realm []. >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- >> server ds01. >> realm >> update delete .. in A >> send >> update delete .. in AAAA >> send >> update add .. 1200 in A -IP2- >> update add .. 1200 in A -IP1- >> send >> -- End nsupdate message -- >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] >> (0x2000): Setting up signal handler up for pid [20631] >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] >> (0x2000): Signal handler set up for pid [20631] >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [write_pipe_handler] >> (0x0400): All data has been sent! >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] >> [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete >> (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_args] >> (0x0200): nsupdate auth type: GSS-TSIG >> setup_system() >> >> Thank you for your help! >> > > I asked question here https://www.redhat.com/archives/freeipa-users/2017-March/msg00360.html -- Martin Ba?ti Software Engineer Red Hat Czech From ronaldw at ronzo.at Wed Apr 19 11:06:53 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Wed, 19 Apr 2017 13:06:53 +0200 Subject: [Freeipa-users] oddjob_mkhomedir troubles Message-ID: <634ea9b0-4f30-9e18-5a70-86a79545505b@ronzo.at> I am trying to automount homeshares (defined in FreeIPA). Now I ran into a problem with oddjob_mkhomedir. By default an AD user would get a homedir that looks like /home/domain/user In this case oddjob_mkhomedir creates the domain-directory but not more. If I configure a client to use /home/user as the default directory (by setting override_homedir in sssd.conf) oddjob_mkhomedir creates the user directory but I still get a permission denied when logging in for the first time. (cd /home/user works) Neither case 1 nor case 2 are satisfying. Any ideas/hints/tricks/workarounds? Regards, Ronald From dan at cazena.com Wed Apr 19 13:11:42 2017 From: dan at cazena.com (Dan Dietterich) Date: Wed, 19 Apr 2017 13:11:42 +0000 Subject: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled In-Reply-To: <3a293c5f-a76f-bdb9-a52a-757badc956bc@redhat.com> References: <3a293c5f-a76f-bdb9-a52a-757badc956bc@redhat.com> Message-ID: My configuration is a single ipa server and both the code path and the bash prompt path are running on the node that is also running the ipa server. I thought that since FreeIPA was installed with --no-dnssec-validation that I should never see this warning. And I confirmed that both dnssec-enabled and dnssec-validation are set to 'no' in the /etc/named.conf. So I'm confused that you say the DNSSEC should always fail. Thanks for your help! From: Martin Ba?ti Date: Wednesday, April 19, 2017 at 3:59 AM To: Dan Dietterich , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled On 13.04.2017 22:50, Dan Dietterich wrote: I am seeing inconsistent results configuring a DNS forward zone. At a bash prompt, as root, after kinit admin, I do: ipa dnsforwardzone-add domain.internal --forwarder= ww.xx.yy.zz --forward-policy=only That works fine and does not warn about DNSSEC. In a Java webapp running as root under a Jetty, I run a shell sub-process and issue the kinit and the same ipa statement. _Sometimes_, I get ipa: WARNING: DNSSEC validation failed: record 'domain.internal. SOA' failed DNSSEC validation on server ww.xx.yy.zz. Please verify your DNSSEC configuration or disable DNSSEC validation on all IPA servers. I modified the /etc/named.conf file to say: dnssec-enable no; dnssec-validation no; and systemctl restart ipa Any clue why the results are different? ipa ?version: VERSION: 4.4.0, API_VERSION: 2.213 Linux ? 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Thanks for any insight! Regards, Dan Hello, checks are done on IPA server side, how many servers do you have? Is possible that CLI connects to different servers. However in this case, DNSSEC check should always fail and report error, so it is weird why it passed. Martin -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Apr 19 13:23:56 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Wed, 19 Apr 2017 15:23:56 +0200 Subject: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled In-Reply-To: References: <3a293c5f-a76f-bdb9-a52a-757badc956bc@redhat.com> Message-ID: <151666ee-cba0-b4f1-a763-9e6bdc34dfdd@redhat.com> IPA servers always check if DNSSEC is working on forwarders, but it is just warning. If you have disabled dnssec in named.conf then it is okay. I'm not sure why sometimes you see this warning and sometimes don't, maybe inconsistent replies from forwarder. domain ".internal" should always fail because it is unregistered TLD Martin On 19.04.2017 15:11, Dan Dietterich wrote: > > My configuration is a single ipa server and both the code path and the > bash prompt path are running on the node that is also running the ipa > server. I thought that since FreeIPA was installed with > --no-dnssec-validation that I should never see this warning. And I > confirmed that both dnssec-enabled and dnssec-validation are set to > 'no' in the /etc/named.conf. > > So I'm confused that you say the DNSSEC should always fail. > > Thanks for your help! > > *From: *Martin Ba?ti > *Date: *Wednesday, April 19, 2017 at 3:59 AM > *To: *Dan Dietterich , "freeipa-users at redhat.com" > > *Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should be > disabled > > On 13.04.2017 22:50, Dan Dietterich wrote: > > I am seeing inconsistent results configuring a DNS forward zone. > > At a bash prompt, as root, after kinit admin, I do: > > ipa dnsforwardzone-add domain.internal --forwarder= ww.xx.yy.zz > --forward-policy=only > > That works fine and does not warn about DNSSEC. > > In a Java webapp running as root under a Jetty, I run a shell > sub-process and issue the kinit and the same ipa statement. > > _/Sometimes/_, I get > > ipa: WARNING: DNSSEC validation failed: record 'domain.internal. > SOA' failed DNSSEC validation on server ww.xx.yy.zz. > > Please verify your DNSSEC configuration or disable DNSSEC > validation on all IPA servers. > > I modified the /etc/named.conf file to say: > > dnssec-enable no; > > dnssec-validation no; > > and systemctl restart ipa > > Any clue why the results are different? > > ipa ?version: VERSION: 4.4.0, API_VERSION: 2.213 > > Linux ? 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC > 2017 x86_64 x86_64 x86_64 GNU/Linux > > Thanks for any insight! > > Regards, > > Dan > > > > > Hello, > > checks are done on IPA server side, how many servers do you have? Is > possible that CLI connects to different servers. > > However in this case, DNSSEC check should always fail and report > error, so it is weird why it passed. > > Martin > > -- > Martin Ba?ti > Software Engineer > Red Hat Czech -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.goudet at lyra-network.com Wed Apr 19 15:14:19 2017 From: david.goudet at lyra-network.com (David Goudet) Date: Wed, 19 Apr 2017 17:14:19 +0200 Subject: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address In-Reply-To: References: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> Message-ID: <72863bdd-8fbe-5afa-d24d-b4e584071664@lyra-network.com> On 04/19/2017 12:31 PM, Martin Ba?ti wrote: > > > On 17.04.2017 19:42, David Goudet wrote: >> Hi, >> >> Nobody has response about my questions? >> >> The main question is: Is it possible to configure SSSD to update DNS >> (option dyndns_update) with only IP address "primary" in ip addr list >> or which is used to FreeIPA server communication (-IP1- used on TCP >> binding)? >> >> Thank you for your help. >> >> Best regards, >> >> On 03/27/2017 09:40 PM, Jakub Hrozek wrote: >> >> On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote: >> >> Hi, >> >> Thanks to dyndns_update=True parameter, SSSD service on client machine updating host DNS entry in FreeIPA. >> Everything is fine on machines which have only one IP adress on network interface. >> I have problem with machines which have more that one IP address on network interface: if machine have two IP address, SSSD update host DNS entry with these two IP address. >> >> To reproduce the problem: >> Host have -IP1- and i add -IP2- >> ip addr add -IP2-/26 dev em1 >> >> ip addr list: >> em1: mtu 1496 qdisc mq state UP qlen 1000 >> link/ether xxxx >> inet -IP1-/26 brd XXXX scope global em1 >> inet -IP2-/26 scope global secondary em1 >> valid_lft forever preferred_lft forever >> >> DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting sssd returns -IP1- & -IP2- >> >> In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used for the updates", what does it means? Is it IP address of the DNS server (used to update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind (-IP1- in my case)? >> >> dyndns_update (boolean) >> Optional. This option tells SSSD to automatically update the DNS server built into FreeIPA v2 with the IP address of this client. >> The update is secured using GSS-TSIG. The IP address of the IPA LDAP connection is used for the updates, if it is not otherwise >> specified by using the ?dyndns_iface? option. >> >> Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on client machine? >> >> IIRC we added this to support multiple interfaces (user can choose >> which one to use) and to update both IPv6 (AAAA) and IPv4 (A) >> records. IPA/SSSD cannot reliably determine which IP address to use, >> it is all or none from interface. With the previous behavior users >> want to use different/more addresses than the one which has been >> detected from LDAP connection and it was not possible previously. >> Do you have set dyndns_iface in sssd.conf? >> >> Martin >> >> Looks like this was a deliberate change: >> https://pagure.io/SSSD/sssd/issue/2558 >> but to be honest, I forgot why exactly we did this. Martin, do you know? >> >> Is it possible to configure SSSD to update DNS with only IP address "primary" in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP binding)? >> >> Only if the IP addresses are of different families (v4/v6), then it's >> possible to restrict one of the families. >> >> >> > > I asked question here > > https://www.redhat.com/archives/freeipa-users/2017-March/msg00360.html > > > Hi, Thank you for your response. In sssd.conf parameter dyndns_iface is not defined, we are in case: Default: Use the IP addresses of the interface which is used for IPA LDAP connection This point (dyndns_iface) is ok, every IPs of this interface and only this interface is updated on IPA host DNS entry. I use only IPv4, so it is not possible to filter on only one IP ("primary") it is "none" or "all" on one interface. In my case i see two solutions: - Split IP "primary" on one interface (bond0 for exemple) and other virtual IPs on one other interface (bond0.1 or bond1 for exemple) - Disable dyndns_update functionality on this machine You confirm, i have no other solutions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at greg-gilbert.com Wed Apr 19 18:47:50 2017 From: greg at greg-gilbert.com (greg at greg-gilbert.com) Date: Wed, 19 Apr 2017 14:47:50 -0400 Subject: [Freeipa-users] What's the proper format for an automember serverhostname rule? Message-ID: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> I'm trying to set up a rule based on server hostname. So for example, 10.100.* would be put into the 'developers' hostgroup. I can't figure out the proper format of the inclusive regex. I've tried: * 10.100.* * 10\.100.* * 10\.100 * .*100.* and a few other permutations, and nothing works. What am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at greg-gilbert.com Wed Apr 19 18:57:42 2017 From: greg at greg-gilbert.com (greg at greg-gilbert.com) Date: Wed, 19 Apr 2017 14:57:42 -0400 Subject: [Freeipa-users] What's the proper format for an automember serverhostname rule? In-Reply-To: <150148194.2498.1492627983834.JavaMail.zimbra@tresgeek.net> References: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> <150148194.2498.1492627983834.JavaMail.zimbra@tresgeek.net> Message-ID: When the instances register themselves with FreeIPA, their hostnames get changed to match their IP; that's a FreeIPA rule, I believe. So in this case, the hostname is 10.100.*. ubuntu at 10:~$ hostname 10.100.15.130 On 2017-04-19 14:53, Jason B. Nance wrote: > Hi Greg, > >> I'm trying to set up a rule based on server hostname. So for example, 10.100.* would be put into the 'developers' hostgroup. I can't figure out the proper format of the inclusive regex. I've tried: > > I believe that your regex needs to match the host name, not the IP address. Unless your host name is 10.100. I don't think that will match. The regex for "anything" is ".*". I think that the pcre syntax is what is used. > Regards, > > j -------------- next part -------------- An HTML attachment was scrubbed... URL: From JCOX15 at harris.com Wed Apr 19 20:19:03 2017 From: JCOX15 at harris.com (Cox, Jason) Date: Wed, 19 Apr 2017 20:19:03 +0000 Subject: [Freeipa-users] cannot add posix group or user Message-ID: <7adff84d44574c0eb6e19b4af7567757@MLBXCH14.cs.myharris.net> Hi all, I had to reinstall my IPA setup, so I'm using 4.4 and am learning the newer domain levels and topology features. I've installed 3 servers. I promoted one of the replicas to master and demoted the original master to replica according to the documentation. I ran into an issue with the original master no longer replicating, so I performed an ipa-server-install -uninstall and removed the host/server from IPA. I re-setup the replica using ipa-client-install and then ipa-replica-install, and had no errors reported in the output. I then went into Web UI and setup replication agreements using the topology graph page between the new replica and the previous replica (the master/new replica agreements being setup by the replica install script). I then attempted to add a posix group account and got an operational error message. This caused ldap to crash on the server I was interfacing with. I performed an 'ipactl restart' on the affected server and attempted again with the same issue. I tried adding a non-posix group and it was successful. I found the dirsrv logs and see the error 'dna-plugin - dna_pre_op: no more values available!!' which lead me to https://www.redhat.com/archives/freeipa-users/2014-February/msg00247.html Performing the ldapserch I see: dnaMaxValue is 1100 dnaNextValue is 1101 dnaThreshold is 500 I also did 'ipa idrange-find', which shows: --------------- 1 range matched --------------- Range name: MYDOMAIN.COM_id_range First Posix ID of the range: 1946000000 Number of IDs in the range: 200000 Range type: local domain range ---------------------------- Number of entries returned 1 ---------------------------- So now my question is what do I need to change to fix the issue? I can do the ldapmodify to adjust the dnaMaxValue, but I don't know what I should be adjusting the idrange to? I'd like to keep the idrange the same and just adjust the dnaMaxValue, so would I need to change dnaMaxValue to 200000? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 19 20:26:51 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Apr 2017 16:26:51 -0400 Subject: [Freeipa-users] cannot add posix group or user In-Reply-To: <7adff84d44574c0eb6e19b4af7567757@MLBXCH14.cs.myharris.net> References: <7adff84d44574c0eb6e19b4af7567757@MLBXCH14.cs.myharris.net> Message-ID: Cox, Jason wrote: > Hi all, > > > > I had to reinstall my IPA setup, so I?m using 4.4 and am learning the > newer domain levels and topology features. > > I?ve installed 3 servers. > > I promoted one of the replicas to master and demoted the original master > to replica according to the documentation. According to what documentation? Note that they are all masters, some may just run different services and only one has a few duties (like CRL generation). > I ran into an issue with the original master no longer replicating, so I > performed an ipa-server-install ?uninstall and removed the host/server > from IPA. This is the where the problem started. > > I re-setup the replica using ipa-client-install and then > ipa-replica-install, and had no errors reported in the output. > > I then went into Web UI and setup replication agreements using the > topology graph page between the new replica and the previous replica > (the master/new replica agreements being setup by the replica install > script). > > > > I then attempted to add a posix group account and got an operational > error message. This caused ldap to crash on the server I was interfacing > with. If you are getting a core it would be very enlightening to get a stack trace from that (you'll need to install the debuginfo package to get any really useful data out of it). > > I performed an ?ipactl restart? on the affected server and attempted > again with the same issue. > > I tried adding a non-posix group and it was successful. > > > > I found the dirsrv logs and see the error ?dna-plugin - dna_pre_op: no > more values available!!? which lead me to > https://www.redhat.com/archives/freeipa-users/2014-February/msg00247.html > > > > Performing the ldapserch I see: > > dnaMaxValue is 1100 > > dnaNextValue is 1101 > > dnaThreshold is 500 Right. A master only gets a range when it needs one. In this case it needed one after the master holding the entire range went away. > I also did ?ipa idrange-find?, which shows: > > > > --------------- > > 1 range matched > > --------------- > > Range name: MYDOMAIN.COM_id_range > > First Posix ID of the range: 1946000000 > > Number of IDs in the range: 200000 > > Range type: local domain range > > ---------------------------- > > Number of entries returned 1 > > ---------------------------- > > > > > > So now my question is what do I need to change to fix the issue? > > I can do the ldapmodify to adjust the dnaMaxValue, but I don?t know what > I should be adjusting the idrange to? > > I?d like to keep the idrange the same and just adjust the dnaMaxValue, > so would I need to change dnaMaxValue to 200000? See https://blog-rcritten.rhcloud.com/?p=50 rob From rcritten at redhat.com Wed Apr 19 20:27:54 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Apr 2017 16:27:54 -0400 Subject: [Freeipa-users] What's the proper format for an automember serverhostname rule? In-Reply-To: References: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> <150148194.2498.1492627983834.JavaMail.zimbra@tresgeek.net> Message-ID: <9c35acb8-e2f3-96f0-61c4-8c19da19a916@redhat.com> greg at greg-gilbert.com wrote: > When the instances register themselves with FreeIPA, their hostnames get > changed to match their IP; that's a FreeIPA rule, I believe. So in this > case, the hostname is 10.100.*. > > ubuntu at 10:~$ hostname > 10.100.15.130 There is something very wrong. ipa-client should be setting a FQDN, not an IP address. /var/log/ipaclient-install.log may hold some clues. rob > > On 2017-04-19 14:53, Jason B. Nance wrote: > >> Hi Greg, >> >> I'm trying to set up a rule based on server hostname. So for >> example, 10.100.* would be put into the 'developers' hostgroup. I >> can't figure out the proper format of the inclusive regex. I've tried: >> >> I believe that your regex needs to match the host name, not the IP >> address. Unless your host name is 10.100. I don't think >> that will match. The regex for "anything" is ".*". I think that the >> pcre syntax is what is used. >> Regards, >> >> j >> > > > > From jason at tresgeek.net Wed Apr 19 18:53:03 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 19 Apr 2017 13:53:03 -0500 (CDT) Subject: [Freeipa-users] What's the proper format for an automember serverhostname rule? In-Reply-To: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> References: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> Message-ID: <150148194.2498.1492627983834.JavaMail.zimbra@tresgeek.net> Hi Greg, > I'm trying to set up a rule based on server hostname. So for example, 10.100.* > would be put into the 'developers' hostgroup. I can't figure out the proper > format of the inclusive regex. I've tried: I believe that your regex needs to match the host name, not the IP address. Unless your host name is 10.100. I don't think that will match. The regex for "anything" is ".*". I think that the pcre syntax is what is used. Regards, j -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at greg-gilbert.com Wed Apr 19 21:25:06 2017 From: greg at greg-gilbert.com (greg at greg-gilbert.com) Date: Wed, 19 Apr 2017 17:25:06 -0400 Subject: [Freeipa-users] What's the proper format for an automember serverhostname rule? In-Reply-To: <9c35acb8-e2f3-96f0-61c4-8c19da19a916@redhat.com> References: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> <150148194.2498.1492627983834.JavaMail.zimbra@tresgeek.net> <9c35acb8-e2f3-96f0-61c4-8c19da19a916@redhat.com> Message-ID: Rob, here's what I see in that log: 2017-04-19T21:18:23Z DEBUG Using servers from command line, disabling DNS discovery 2017-04-19T21:18:23Z DEBUG will use provided server: ipa.services.foo 2017-04-19T21:18:23Z DEBUG will use discovered realm: IPA.SERVICES.FOO 2017-04-19T21:18:23Z DEBUG will use discovered basedn: dc=ipa,dc=services,dc=foo 2017-04-19T21:18:23Z INFO Client hostname: 10.100.15.209 2017-04-19T21:18:23Z DEBUG Hostname source: Provided as option 2017-04-19T21:18:23Z INFO Realm: IPA.SERVICES.FOO ... 2017-04-19T21:18:23Z DEBUG Starting external process 2017-04-19T21:18:23Z DEBUG args=/bin/hostname 10.100.15.209 2017-04-19T21:18:23Z DEBUG Process finished, return code=0 2017-04-19T21:18:23Z DEBUG stdout= 2017-04-19T21:18:23Z DEBUG stderr= 2017-04-19T21:18:23Z DEBUG Backing up system configuration file '/etc/hostname' So whatever that external process is, I guess that's what's resetting the hostname. For reference, here's the line that runs (on cloud-init) to set up FreeIPA: /usr/sbin/ipa-client-install \ --domain=ipa.services.FOO \ --server=ipa.services.FOO \ -U \ --permit \ --ssh-trust-dns \ --principal=enrollment \ --password="PASS" \ --hostname="{{ ansible_eth0.ipv4.address }}" On 2017-04-19 16:27, Rob Crittenden wrote: > greg at greg-gilbert.com wrote: > >> When the instances register themselves with FreeIPA, their hostnames get >> changed to match their IP; that's a FreeIPA rule, I believe. So in this >> case, the hostname is 10.100.*. >> >> ubuntu at 10:~$ hostname >> 10.100.15.130 > > There is something very wrong. ipa-client should be setting a FQDN, not > an IP address. /var/log/ipaclient-install.log may hold some clues. > > rob > > On 2017-04-19 14:53, Jason B. Nance wrote: > > Hi Greg, > > I'm trying to set up a rule based on server hostname. So for > example, 10.100.* would be put into the 'developers' hostgroup. I > can't figure out the proper format of the inclusive regex. I've tried: > > I believe that your regex needs to match the host name, not the IP > address. Unless your host name is 10.100. I don't think > that will match. The regex for "anything" is ".*". I think that the > pcre syntax is what is used. > Regards, > > j -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at greg-gilbert.com Wed Apr 19 21:35:13 2017 From: greg at greg-gilbert.com (greg at greg-gilbert.com) Date: Wed, 19 Apr 2017 17:35:13 -0400 Subject: [Freeipa-users] What's the proper format for an automember serverhostname rule? In-Reply-To: References: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> <150148194.2498.1492627983834.JavaMail.zimbra@tresgeek.net> <9c35acb8-e2f3-96f0-61c4-8c19da19a916@redhat.com> Message-ID: <77ef7f82ea5bfc85836e018d84e28c17@greg-gilbert.com> Follow-up: I guess I can leave off the --hostname part of it and it doesn't change the hostname. On 2017-04-19 17:25, greg at greg-gilbert.com wrote: > Rob, here's what I see in that log: > > 2017-04-19T21:18:23Z DEBUG Using servers from command line, disabling DNS discovery > 2017-04-19T21:18:23Z DEBUG will use provided server: ipa.services.foo > 2017-04-19T21:18:23Z DEBUG will use discovered realm: IPA.SERVICES.FOO > 2017-04-19T21:18:23Z DEBUG will use discovered basedn: dc=ipa,dc=services,dc=foo > 2017-04-19T21:18:23Z INFO Client hostname: 10.100.15.209 > 2017-04-19T21:18:23Z DEBUG Hostname source: Provided as option > 2017-04-19T21:18:23Z INFO Realm: IPA.SERVICES.FOO > ... > 2017-04-19T21:18:23Z DEBUG Starting external process > 2017-04-19T21:18:23Z DEBUG args=/bin/hostname 10.100.15.209 > 2017-04-19T21:18:23Z DEBUG Process finished, return code=0 > 2017-04-19T21:18:23Z DEBUG stdout= > 2017-04-19T21:18:23Z DEBUG stderr= > 2017-04-19T21:18:23Z DEBUG Backing up system configuration file '/etc/hostname' > > So whatever that external process is, I guess that's what's resetting the hostname. > > For reference, here's the line that runs (on cloud-init) to set up FreeIPA: > > /usr/sbin/ipa-client-install \ > --domain=ipa.services.FOO \ > --server=ipa.services.FOO \ > -U \ > --permit \ > --ssh-trust-dns \ > --principal=enrollment \ > --password="PASS" \ > --hostname="{{ ansible_eth0.ipv4.address }}" > > On 2017-04-19 16:27, Rob Crittenden wrote: > greg at greg-gilbert.com wrote: When the instances register themselves with FreeIPA, their hostnames get > changed to match their IP; that's a FreeIPA rule, I believe. So in this > case, the hostname is 10.100.*. > > ubuntu at 10:~$ hostname > 10.100.15.130 > There is something very wrong. ipa-client should be setting a FQDN, not > an IP address. /var/log/ipaclient-install.log may hold some clues. > > rob > > On 2017-04-19 14:53, Jason B. Nance wrote: > > Hi Greg, > > I'm trying to set up a rule based on server hostname. So for > example, 10.100.* would be put into the 'developers' hostgroup. I > can't figure out the proper format of the inclusive regex. I've tried: > > I believe that your regex needs to match the host name, not the IP > address. Unless your host name is 10.100. I don't think > that will match. The regex for "anything" is ".*". I think that the > pcre syntax is what is used. > Regards, > > j -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 19 21:55:02 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Apr 2017 17:55:02 -0400 Subject: [Freeipa-users] What's the proper format for an automember serverhostname rule? In-Reply-To: References: <9535862e83673aaaa48548559b28e598@greg-gilbert.com> <150148194.2498.1492627983834.JavaMail.zimbra@tresgeek.net> <9c35acb8-e2f3-96f0-61c4-8c19da19a916@redhat.com> Message-ID: greg at greg-gilbert.com wrote: > Rob, here's what I see in that log: > > 2017-04-19T21:18:23Z DEBUG Using servers from command line, disabling > DNS discovery > 2017-04-19T21:18:23Z DEBUG will use provided server: ipa.services.foo > 2017-04-19T21:18:23Z DEBUG will use discovered realm: IPA.SERVICES.FOO > 2017-04-19T21:18:23Z DEBUG will use discovered basedn: > dc=ipa,dc=services,dc=foo > 2017-04-19T21:18:23Z INFO Client hostname: 10.100.15.209 > 2017-04-19T21:18:23Z DEBUG Hostname source: Provided as option > 2017-04-19T21:18:23Z INFO Realm: IPA.SERVICES.FOO > ... > 2017-04-19T21:18:23Z DEBUG Starting external process > 2017-04-19T21:18:23Z DEBUG args=/bin/hostname 10.100.15.209 > 2017-04-19T21:18:23Z DEBUG Process finished, return code=0 > 2017-04-19T21:18:23Z DEBUG stdout= > 2017-04-19T21:18:23Z DEBUG stderr= > 2017-04-19T21:18:23Z DEBUG Backing up system configuration file > '/etc/hostname' > > So whatever that external process is, I guess that's what's resetting > the hostname. > > For reference, here's the line that runs (on cloud-init) to set up FreeIPA: > > /usr/sbin/ipa-client-install \ > --domain=ipa.services.FOO \ > --server=ipa.services.FOO \ > -U \ > --permit \ > --ssh-trust-dns \ > --principal=enrollment \ > --password="PASS" \ > --hostname="{{ ansible_eth0.ipv4.address }}" ^^^^^^^^^^^^^^^^^^^^^^^^ Right. Don't do that. rob > > > On 2017-04-19 16:27, Rob Crittenden wrote: > >> greg at greg-gilbert.com wrote: >>> When the instances register themselves with FreeIPA, their hostnames get >>> changed to match their IP; that's a FreeIPA rule, I believe. So in this >>> case, the hostname is 10.100.*. >>> >>> ubuntu at 10:~$ hostname >>> 10.100.15.130 >> >> There is something very wrong. ipa-client should be setting a FQDN, not >> an IP address. /var/log/ipaclient-install.log may hold some clues. >> >> rob >> >>> >>> On 2017-04-19 14:53, Jason B. Nance wrote: >>> >>>> Hi Greg, >>>> >>>> I'm trying to set up a rule based on server hostname. So for >>>> example, 10.100.* would be put into the 'developers' hostgroup. I >>>> can't figure out the proper format of the inclusive regex. I've >>>> tried: >>>> >>>> I believe that your regex needs to match the host name, not the IP >>>> address. Unless your host name is 10.100. I don't think >>>> that will match. The regex for "anything" is ".*". I think that the >>>> pcre syntax is what is used. >>>> Regards, >>>> >>>> j >>>> >>> >>> >>> >>> > From mbasti at redhat.com Thu Apr 20 07:25:15 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Thu, 20 Apr 2017 09:25:15 +0200 Subject: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address In-Reply-To: <72863bdd-8fbe-5afa-d24d-b4e584071664@lyra-network.com> References: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> <72863bdd-8fbe-5afa-d24d-b4e584071664@lyra-network.com> Message-ID: <60733d6e-56c6-69ee-4bad-a9d1b30d7459@redhat.com> On 19.04.2017 17:14, David Goudet wrote: > > On 04/19/2017 12:31 PM, Martin Ba?ti wrote: >> >> >> On 17.04.2017 19:42, David Goudet wrote: >>> Hi, >>> >>> Nobody has response about my questions? >>> >>> The main question is: Is it possible to configure SSSD to update DNS >>> (option dyndns_update) with only IP address "primary" in ip addr >>> list or which is used to FreeIPA server communication (-IP1- used on >>> TCP binding)? >>> >>> Thank you for your help. >>> >>> Best regards, >>> >>> On 03/27/2017 09:40 PM, Jakub Hrozek wrote: >>> >>> On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote: >>> >>> Hi, >>> >>> Thanks to dyndns_update=True parameter, SSSD service on client machine updating host DNS entry in FreeIPA. >>> Everything is fine on machines which have only one IP adress on network interface. >>> I have problem with machines which have more that one IP address on network interface: if machine have two IP address, SSSD update host DNS entry with these two IP address. >>> >>> To reproduce the problem: >>> Host have -IP1- and i add -IP2- >>> ip addr add -IP2-/26 dev em1 >>> >>> ip addr list: >>> em1: mtu 1496 qdisc mq state UP qlen 1000 >>> link/ether xxxx >>> inet -IP1-/26 brd XXXX scope global em1 >>> inet -IP2-/26 scope global secondary em1 >>> valid_lft forever preferred_lft forever >>> >>> DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting sssd returns -IP1- & -IP2- >>> >>> In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used for the updates", what does it means? Is it IP address of the DNS server (used to update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind (-IP1- in my case)? >>> >>> dyndns_update (boolean) >>> Optional. This option tells SSSD to automatically update the DNS server built into FreeIPA v2 with the IP address of this client. >>> The update is secured using GSS-TSIG. The IP address of the IPA LDAP connection is used for the updates, if it is not otherwise >>> specified by using the ?dyndns_iface? option. >>> >>> Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on client machine? >>> >>> IIRC we added this to support multiple interfaces (user can choose >>> which one to use) and to update both IPv6 (AAAA) and IPv4 (A) >>> records. IPA/SSSD cannot reliably determine which IP address to use, >>> it is all or none from interface. With the previous behavior users >>> want to use different/more addresses than the one which has been >>> detected from LDAP connection and it was not possible previously. >>> Do you have set dyndns_iface in sssd.conf? >>> >>> Martin >>> >>> Looks like this was a deliberate change: >>> https://pagure.io/SSSD/sssd/issue/2558 >>> but to be honest, I forgot why exactly we did this. Martin, do you know? >>> >>> Is it possible to configure SSSD to update DNS with only IP address "primary" in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP binding)? >>> >>> Only if the IP addresses are of different families (v4/v6), then it's >>> possible to restrict one of the families. >>> >>> >>> >> >> I asked question here >> >> https://www.redhat.com/archives/freeipa-users/2017-March/msg00360.html >> >> >> > > Hi, > > Thank you for your response. > > In sssd.conf parameter dyndns_iface is not defined, we are in case: > Default: Use the IP addresses of the interface which is used for IPA > LDAP connection > > This point (dyndns_iface) is ok, every IPs of this interface and only > this interface is updated on IPA host DNS entry. > I use only IPv4, so it is not possible to filter on only one IP > ("primary") it is "none" or "all" on one interface. > > In my case i see two solutions: > - Split IP "primary" on one interface (bond0 for exemple) and other > virtual IPs on one other interface (bond0.1 or bond1 for exemple) > - Disable dyndns_update functionality on this machine > > You confirm, i have no other solutions? > > Well, then you have only choices you wrote. Sorry. -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldw at ronzo.at Thu Apr 20 11:33:13 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Thu, 20 Apr 2017 13:33:13 +0200 Subject: [Freeipa-users] oddjob_mkhomedir troubles In-Reply-To: <634ea9b0-4f30-9e18-5a70-86a79545505b@ronzo.at> References: <634ea9b0-4f30-9e18-5a70-86a79545505b@ronzo.at> Message-ID: <981afa72-79a8-6437-bebd-acc4d2e6f278@ronzo.at> On 2017-04-19 13:06, Ronald Wimmer wrote: > [...] > > as the default directory (by setting override_homedir in sssd.conf) > oddjob_mkhomedir creates the user directory but I still get a > permission denied when logging in for the first time. (cd /home/user > works) > The only thing I see in the logs is: Apr 20 13:10:02 testclient systemd: Starting Session 1260 of user myuser at mydomain.at. Apr 20 13:10:02 testclient oddjob-mkhomedir[15879]: error setting permissions on /home/mydomain.at/myuser: Operation not permitted Apr 20 13:10:02 testclient dbus[770]: [system] Activating service name='org.freedesktop.problems' (using servicehelper) Apr 20 13:10:02 testclient dbus-daemon: dbus[770]: [system] Activating service name='org.freedesktop.problems' (using servicehelper) Apr 20 13:10:02 testclient dbus[770]: [system] Successfully activated service 'org.freedesktop.problems' Apr 20 13:10:02 testclient dbus-daemon: dbus[770]: [system] Successfully activated service 'org.freedesktop.problems' This is where PAM put the module: /etc/pam.d/fingerprint-auth:session optional pam_oddjob_mkhomedir.so umask=0077 /etc/pam.d/fingerprint-auth-ac:session optional pam_oddjob_mkhomedir.so umask=0077 /etc/pam.d/password-auth:session optional pam_oddjob_mkhomedir.so umask=0077 /etc/pam.d/password-auth-ac:session optional pam_oddjob_mkhomedir.so umask=0077 /etc/pam.d/smartcard-auth:session optional pam_oddjob_mkhomedir.so umask=0077 /etc/pam.d/smartcard-auth-ac:session optional pam_oddjob_mkhomedir.so umask=0077 /etc/pam.d/system-auth:session optional pam_oddjob_mkhomedir.so umask=0077 /etc/pam.d/system-auth-ac:session optional pam_oddjob_mkhomedir.so umask=0077 Maybe it is not placed in the right line in /etc/pam.d/system-auth: session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Is there a PAM expert around who can tell? Regards, Ronald From marc.boorshtein at tremolosecurity.com Thu Apr 20 12:04:34 2017 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Thu, 20 Apr 2017 08:04:34 -0400 Subject: [Freeipa-users] U2F and ipa for ssh Message-ID: Has anyone looked into using U2F with freeipa? My guess is you would need a customized ssh client to interact with the device but in theory you could just transform the users U2F public key into an ssh key. Marc Boorshtein CTO, Tremolo Security, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From JCOX15 at harris.com Thu Apr 20 13:05:14 2017 From: JCOX15 at harris.com (Cox, Jason) Date: Thu, 20 Apr 2017 13:05:14 +0000 Subject: [Freeipa-users] cannot add posix group or user In-Reply-To: References: <7adff84d44574c0eb6e19b4af7567757@MLBXCH14.cs.myharris.net> Message-ID: > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, April 19, 2017 4:27 PM > To: Cox, Jason (U.S. Person) ; freeipa- > users at redhat.com > Subject: Re: [Freeipa-users] cannot add posix group or user > > Cox, Jason wrote: > > Hi all, > > > > > > > > I had to reinstall my IPA setup, so I?m using 4.4 and am learning the > > newer domain levels and topology features. > > > > I?ve installed 3 servers. > > > > I promoted one of the replicas to master and demoted the original > > master to replica according to the documentation. > > According to what documentation? > > Note that they are all masters, some may just run different services and only > one has a few duties (like CRL generation). > Here: https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master And here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/server-roles.html#server-roles-promote-to-ca Yes, I was referring to CRL master And yes, I failed to continue reading https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/ to find what I needed to know concerning the id ranges. Sorry about that. > > I ran into an issue with the original master no longer replicating, so > > I performed an ipa-server-install ?uninstall and removed the > > host/server from IPA. > > This is the where the problem started. > > > > > I re-setup the replica using ipa-client-install and then > > ipa-replica-install, and had no errors reported in the output. > > > > I then went into Web UI and setup replication agreements using the > > topology graph page between the new replica and the previous replica > > (the master/new replica agreements being setup by the replica install > > script). > > > > > > > > I then attempted to add a posix group account and got an operational > > error message. This caused ldap to crash on the server I was > > interfacing with. > > If you are getting a core it would be very enlightening to get a stack trace > from that (you'll need to install the debuginfo package to get any really > useful data out of it). > I haven't had to get a core file from a systemd service before, so I did it the wrong way, but this is what I managed to get: >From journalctl: *** Error in `/usr/sbin/ns-slapd': free(): invalid pointer: 0x00007fbcd82f5fb0 *** Apr 19 17:13:56 server1 ns-slapd[1892]: ======= Backtrace: ========= Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libc.so.6(+0x7c503)[0x7fbd4522c503] Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libldap_r-2.4.so.2(ldap_mods_free+0x81)[0x7fbd46ba1a11] Apr 19 17:13:56 server1 ns-slapd[1892]: /usr/lib64/dirsrv/libslapd.so.0(do_modify+0x7e0)[0x7fbd479f96a0] Apr 19 17:13:56 server1 ns-slapd[1892]: /usr/sbin/ns-slapd(+0x1b9e0)[0x7fbd47ee29e0] Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libnspr4.so(+0x289bb)[0x7fbd45bd89bb] Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libpthread.so.0(+0x7dc5)[0x7fbd45578dc5] Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libc.so.6(clone+0x6d)[0x7fbd452a773d] >From an eventual core and gdb (and not from the same crash as the journalctl output): (gdb) bt #0 __GI___libc_free (mem=0x41) at malloc.c:2929 #1 0x00007f87f6fca24c in ber_memvfree_x (vec=0x7f876c00a900, ctx=0x0) at memory.c:180 #2 0x00007f87f71f2a11 in ldap_mods_free (mods=0x7f876c001fb0, freemods=1) at free.c:94 #3 0x00007f87f804a6a0 in do_modify (pb=pb at entry=0x7f87b4ff0a90) at ldap/servers/slapd/modify.c:390 #4 0x00007f87f85339e0 in connection_dispatch_operation (pb=0x7f87b4ff0a90, op=0x7f87f931bf80, conn=0x7f87d82d0768) at ldap/servers/slapd/connection.c:627 #5 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #6 0x00007f87f62299bb in _pt_root () from /lib64/libnspr4.so #7 0x00007f87f5bc9dc5 in start_thread (arg=0x7f87b4ff1700) at pthread_create.c:308 #8 0x00007f87f58f873d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 (gdb) bt full #0 __GI___libc_free (mem=0x41) at malloc.c:2929 ar_ptr = p = hook = 0x0 #1 0x00007f87f6fca24c in ber_memvfree_x (vec=0x7f876c00a900, ctx=0x0) at memory.c:180 i = #2 0x00007f87f71f2a11 in ldap_mods_free (mods=0x7f876c001fb0, freemods=1) at free.c:94 i = #3 0x00007f87f804a6a0 in do_modify (pb=pb at entry=0x7f87b4ff0a90) at ldap/servers/slapd/modify.c:390 operation = 0x7f87f931bf80 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} ber = tag = len = 18446744073709551615 normalized_mods = 0x7f876c001fb0 mod = 0x0 mods = 0x7f876c00c200 last = 0x7f876c000e23 "" type = 0x0 old_pw = 0x0 rawdn = 0x7f876c000920 "cn=svcaccount,cn=groups,cn=accounts,dc=MYDOMAIN" minssf_exclude_rootdse = ignored_some_mods = has_password_mod = pw_change = 0 err = #4 0x00007f87f85339e0 in connection_dispatch_operation (pb=0x7f87b4ff0a90, op=0x7f87f931bf80, conn=0x7f87d82d0768) at ldap/servers/slapd/connection.c:627 minssf = 0 minssf_exclude_rootdse = ---Type to continue, or q to quit--- enable_nagle = 1 pop_cork = 0 #5 connection_threadmain () at ldap/servers/slapd/connection.c:1759 is_timedout = 0 curtime = local_pb = {pb_backend = 0x7f87f8e1a070, pb_conn = 0x7f87d82d0768, pb_op = 0x7f87f931bf80, pb_plugin = 0x7f87f8c85c50, pb_opreturn = -1, pb_object = 0x0, pb_destroy_fn = 0x0, pb_requestor_isroot = 0, pb_config_fname = 0x0, pb_config_lineno = 0, pb_config_argc = 0, pb_config_argv = 0x0, plugin_tracking = 0, pb_target_entry = 0x0, pb_existing_dn_entry = 0x7f876c00e880, pb_existing_uniqueid_entry = 0x0, pb_parent_entry = 0x0, pb_newparent_entry = 0x0, pb_pre_op_entry = 0x0, pb_post_op_entry = 0x0, pb_seq_type = 0, pb_seq_attrname = 0x0, pb_seq_val = 0x0, pb_dbverify_dbdir = 0x0, pb_ldif_file = 0x0, pb_removedupvals = 0, pb_db2index_attrs = 0x0, pb_ldif2db_noattrindexes = 0, pb_ldif_printkey = 0, pb_instance_name = 0x0, pb_task = 0x0, pb_task_flags = 0, pb_mr_filter_match_fn = 0x0, pb_mr_filter_index_fn = 0x0, pb_mr_filter_reset_fn = 0x0, pb_mr_index_fn = 0x0, pb_mr_oid = 0x0, pb_mr_type = 0x0, pb_mr_value = 0x0, pb_mr_values = 0x0, pb_mr_keys = 0x0, pb_mr_filter_reusable = 0, pb_mr_query_operator = 0, pb_mr_usage = 0, pb_pwd_storage_scheme_user_passwd = 0x0, pb_pwd_storage_scheme_db_passwd = 0x0, pb_managedsait = 0, pb_internal_op_result = 0, pb_plugin_internal_search_op_entries = 0x0, pb_plugin_internal_search_op_referrals = 0x0, pb_plugin_identity = 0x0, pb_plugin_config_area = 0x0, pb_parent_txn = 0x0, pb_txn = 0x0, pb_txn_ruv_mods_fn = 0x7f87ea323470 , pb_dbsize = 0, pb_ldif_files = 0x0, pb_ldif_include = 0x0, pb_ldif_exclude = 0x0, pb_ldif_dump_replica = 0, pb_ldif_dump_uniqueid = 0, pb_ldif_generate_uniqueid = 0, pb_ldif_namespaceid = 0x0, pb_ldif_encrypt = 0, pb_operation_notes = 0, pb_slapd_argc = 0, pb_slapd_argv = 0x0, pb_slapd_configdir = 0x0, pb_ctrls_arg = 0x0, pb_dse_dont_add_write = 0, pb_dse_add_merge = 0, pb_dse_dont_check_dups = 0, pb_dse_is_primary_file = 0, pb_schema_flags = 0, pb_result_code = 0, pb_result_text = 0x0, pb_result_matched = 0x0, pb_nentries = 0, urls = 0x0, pb_import_entry = 0x0, pb_import_state = 0, pb_destroy_content = 0, pb_dse_reapply_mods = 0, pb_urp_naming_collision_dn = 0x0, pb_urp_tombstone_uniqueid = 0x0, pb_server_running = 0, pb_backend_count = 1, pb_pwpolicy_ctrl = 0, pb_vattr_context = 0x0, pb_substrlens = 0x0, pb_plugin_enabled = 0, pb_search_ctrls = 0x0, pb_mr_index_sv_fn = 0x0, pb_syntax_filter_normalized = 0, pb_syntax_filter_data = 0x0, pb_paged_results_index = 0, pb_paged_results_cookie = 0, pwdpolicy = 0x0, op_stack_elem = 0x7f87f8e24d30, pb_aci_target_check = 0, pb_pw_entry = 0x0} pb = 0x7f87b4ff0a90 conn = 0x7f87d82d0768 op = 0x7f87f931bf80 tag = 102 need_wakeup = 0 thread_turbo_flag = ret = more_data = 0 ---Type to continue, or q to quit--- replication_connection = 0 doshutdown = 0 maxthreads = 5 enable_nunc_stans = 0 bypasspollcnt = #6 0x00007f87f62299bb in _pt_root () from /lib64/libnspr4.so No symbol table info available. #7 0x00007f87f5bc9dc5 in start_thread (arg=0x7f87b4ff1700) at pthread_create.c:308 __res = pd = 0x7f87b4ff1700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140220833928960, -5233892399363934943, 0, 140220833929664, 140220833928960, 1, 5211249063945286945, 5211388174174106913}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #8 0x00007f87f58f873d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. > > > > I performed an ?ipactl restart? on the affected server and attempted > > again with the same issue. > > > > I tried adding a non-posix group and it was successful. > > > > > > > > I found the dirsrv logs and see the error ?dna-plugin - dna_pre_op: no > > more values available!!? which lead me to > > https://www.redhat.com/archives/freeipa-users/2014- > February/msg00247.h > > tml > > > > > > > > Performing the ldapserch I see: > > > > dnaMaxValue is 1100 > > > > dnaNextValue is 1101 > > > > dnaThreshold is 500 > > Right. A master only gets a range when it needs one. In this case it needed > one after the master holding the entire range went away. > > > I also did ?ipa idrange-find?, which shows: > > > > > > > > --------------- > > > > 1 range matched > > > > --------------- > > > > Range name: MYDOMAIN.COM_id_range > > > > First Posix ID of the range: 1946000000 > > > > Number of IDs in the range: 200000 > > > > Range type: local domain range > > > > ---------------------------- > > > > Number of entries returned 1 > > > > ---------------------------- > > > > > > > > > > > > So now my question is what do I need to change to fix the issue? > > > > I can do the ldapmodify to adjust the dnaMaxValue, but I don?t know > > what I should be adjusting the idrange to? > > > > I?d like to keep the idrange the same and just adjust the dnaMaxValue, > > so would I need to change dnaMaxValue to 200000? > > See https://blog-rcritten.rhcloud.com/?p=50 > > rob Thank you. Setting the id ranges manually fixed my problem. From rcritten at redhat.com Thu Apr 20 13:50:39 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Apr 2017 09:50:39 -0400 Subject: [Freeipa-users] cannot add posix group or user In-Reply-To: References: <7adff84d44574c0eb6e19b4af7567757@MLBXCH14.cs.myharris.net> Message-ID: <0d9bddd9-7b8e-bffa-c807-6d8c12613707@redhat.com> Cox, Jason wrote: > >> Thank you. > Setting the id ranges manually fixed my problem. Great, glad you're up and running again. I forwarded the stack trace to the 389-ds developers, thanks for that. rob From tbordaz at redhat.com Thu Apr 20 14:34:44 2017 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Apr 2017 16:34:44 +0200 Subject: [Freeipa-users] cannot add posix group or user In-Reply-To: References: <7adff84d44574c0eb6e19b4af7567757@MLBXCH14.cs.myharris.net> Message-ID: <58F8C704.4010701@redhat.com> On 04/20/2017 03:05 PM, Cox, Jason wrote: > >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Wednesday, April 19, 2017 4:27 PM >> To: Cox, Jason (U.S. Person) ; freeipa- >> users at redhat.com >> Subject: Re: [Freeipa-users] cannot add posix group or user >> >> Cox, Jason wrote: >>> Hi all, >>> >>> >>> >>> I had to reinstall my IPA setup, so I?m using 4.4 and am learning the >>> newer domain levels and topology features. >>> >>> I?ve installed 3 servers. >>> >>> I promoted one of the replicas to master and demoted the original >>> master to replica according to the documentation. >> According to what documentation? >> >> Note that they are all masters, some may just run different services and only >> one has a few duties (like CRL generation). >> > Here: https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > And here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/server-roles.html#server-roles-promote-to-ca > > Yes, I was referring to CRL master > > And yes, I failed to continue reading https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/ to find what I needed to know concerning the id ranges. Sorry about that. > > >>> I ran into an issue with the original master no longer replicating, so >>> I performed an ipa-server-install ?uninstall and removed the >>> host/server from IPA. >> This is the where the problem started. >> >>> I re-setup the replica using ipa-client-install and then >>> ipa-replica-install, and had no errors reported in the output. >>> >>> I then went into Web UI and setup replication agreements using the >>> topology graph page between the new replica and the previous replica >>> (the master/new replica agreements being setup by the replica install >>> script). >>> >>> >>> >>> I then attempted to add a posix group account and got an operational >>> error message. This caused ldap to crash on the server I was >>> interfacing with. >> If you are getting a core it would be very enlightening to get a stack trace >> from that (you'll need to install the debuginfo package to get any really >> useful data out of it). >> > I haven't had to get a core file from a systemd service before, so I did it the wrong way, but this is what I managed to get: > > >From journalctl: > *** Error in `/usr/sbin/ns-slapd': free(): invalid pointer: 0x00007fbcd82f5fb0 *** > Apr 19 17:13:56 server1 ns-slapd[1892]: ======= Backtrace: ========= > Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libc.so.6(+0x7c503)[0x7fbd4522c503] > Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libldap_r-2.4.so.2(ldap_mods_free+0x81)[0x7fbd46ba1a11] > Apr 19 17:13:56 server1 ns-slapd[1892]: /usr/lib64/dirsrv/libslapd.so.0(do_modify+0x7e0)[0x7fbd479f96a0] > Apr 19 17:13:56 server1 ns-slapd[1892]: /usr/sbin/ns-slapd(+0x1b9e0)[0x7fbd47ee29e0] > Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libnspr4.so(+0x289bb)[0x7fbd45bd89bb] > Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libpthread.so.0(+0x7dc5)[0x7fbd45578dc5] > Apr 19 17:13:56 server1 ns-slapd[1892]: /lib64/libc.so.6(clone+0x6d)[0x7fbd452a773d] > > > >From an eventual core and gdb (and not from the same crash as the journalctl output): > (gdb) bt > #0 __GI___libc_free (mem=0x41) at malloc.c:2929 > #1 0x00007f87f6fca24c in ber_memvfree_x (vec=0x7f876c00a900, ctx=0x0) at memory.c:180 > #2 0x00007f87f71f2a11 in ldap_mods_free (mods=0x7f876c001fb0, freemods=1) at free.c:94 > #3 0x00007f87f804a6a0 in do_modify (pb=pb at entry=0x7f87b4ff0a90) at ldap/servers/slapd/modify.c:390 > #4 0x00007f87f85339e0 in connection_dispatch_operation (pb=0x7f87b4ff0a90, op=0x7f87f931bf80, conn=0x7f87d82d0768) at ldap/servers/slapd/connection.c:627 > #5 connection_threadmain () at ldap/servers/slapd/connection.c:1759 > #6 0x00007f87f62299bb in _pt_root () from /lib64/libnspr4.so > #7 0x00007f87f5bc9dc5 in start_thread (arg=0x7f87b4ff1700) at pthread_create.c:308 > #8 0x00007f87f58f873d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Hi, This is looking like the heap corruption and this backstack is unfortunately not enough to identify if it is a known/fixed one or not. This part of code (do_modify) was not recently changed regarding heap corruption and I would rather expect this thread to be the victim than responsible of it. What 389-ds version are you running ? We fixed recently a bug that could be the root cause (of course not 100% sure). Did you update 389-ds to the most recent one ? Do you manage to reproduce this crash ? For heap corruption, you may use valgrind but it could be too impacting for production performance. regards thierry > > (gdb) bt full > #0 __GI___libc_free (mem=0x41) at malloc.c:2929 > ar_ptr = > p = > hook = 0x0 > #1 0x00007f87f6fca24c in ber_memvfree_x (vec=0x7f876c00a900, ctx=0x0) at memory.c:180 > i = > #2 0x00007f87f71f2a11 in ldap_mods_free (mods=0x7f876c001fb0, freemods=1) at free.c:94 > i = > #3 0x00007f87f804a6a0 in do_modify (pb=pb at entry=0x7f87b4ff0a90) at ldap/servers/slapd/modify.c:390 > operation = 0x7f87f931bf80 > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} > ber = > tag = > len = 18446744073709551615 > normalized_mods = 0x7f876c001fb0 > mod = 0x0 > mods = 0x7f876c00c200 > last = 0x7f876c000e23 "" > type = 0x0 > old_pw = 0x0 > rawdn = 0x7f876c000920 "cn=svcaccount,cn=groups,cn=accounts,dc=MYDOMAIN" > minssf_exclude_rootdse = > ignored_some_mods = > has_password_mod = > pw_change = 0 > err = > #4 0x00007f87f85339e0 in connection_dispatch_operation (pb=0x7f87b4ff0a90, op=0x7f87f931bf80, conn=0x7f87d82d0768) at ldap/servers/slapd/connection.c:627 > minssf = 0 > minssf_exclude_rootdse = > ---Type to continue, or q to quit--- > enable_nagle = 1 > pop_cork = 0 > #5 connection_threadmain () at ldap/servers/slapd/connection.c:1759 > is_timedout = 0 > curtime = > local_pb = {pb_backend = 0x7f87f8e1a070, pb_conn = 0x7f87d82d0768, pb_op = 0x7f87f931bf80, pb_plugin = 0x7f87f8c85c50, pb_opreturn = -1, pb_object = 0x0, pb_destroy_fn = 0x0, > pb_requestor_isroot = 0, pb_config_fname = 0x0, pb_config_lineno = 0, pb_config_argc = 0, pb_config_argv = 0x0, plugin_tracking = 0, pb_target_entry = 0x0, > pb_existing_dn_entry = 0x7f876c00e880, pb_existing_uniqueid_entry = 0x0, pb_parent_entry = 0x0, pb_newparent_entry = 0x0, pb_pre_op_entry = 0x0, pb_post_op_entry = 0x0, > pb_seq_type = 0, pb_seq_attrname = 0x0, pb_seq_val = 0x0, pb_dbverify_dbdir = 0x0, pb_ldif_file = 0x0, pb_removedupvals = 0, pb_db2index_attrs = 0x0, > pb_ldif2db_noattrindexes = 0, pb_ldif_printkey = 0, pb_instance_name = 0x0, pb_task = 0x0, pb_task_flags = 0, pb_mr_filter_match_fn = 0x0, pb_mr_filter_index_fn = 0x0, > pb_mr_filter_reset_fn = 0x0, pb_mr_index_fn = 0x0, pb_mr_oid = 0x0, pb_mr_type = 0x0, pb_mr_value = 0x0, pb_mr_values = 0x0, pb_mr_keys = 0x0, pb_mr_filter_reusable = 0, > pb_mr_query_operator = 0, pb_mr_usage = 0, pb_pwd_storage_scheme_user_passwd = 0x0, pb_pwd_storage_scheme_db_passwd = 0x0, pb_managedsait = 0, pb_internal_op_result = 0, > pb_plugin_internal_search_op_entries = 0x0, pb_plugin_internal_search_op_referrals = 0x0, pb_plugin_identity = 0x0, pb_plugin_config_area = 0x0, pb_parent_txn = 0x0, > pb_txn = 0x0, pb_txn_ruv_mods_fn = 0x7f87ea323470 , pb_dbsize = 0, pb_ldif_files = 0x0, pb_ldif_include = 0x0, pb_ldif_exclude = 0x0, > pb_ldif_dump_replica = 0, pb_ldif_dump_uniqueid = 0, pb_ldif_generate_uniqueid = 0, pb_ldif_namespaceid = 0x0, pb_ldif_encrypt = 0, pb_operation_notes = 0, pb_slapd_argc = 0, > pb_slapd_argv = 0x0, pb_slapd_configdir = 0x0, pb_ctrls_arg = 0x0, pb_dse_dont_add_write = 0, pb_dse_add_merge = 0, pb_dse_dont_check_dups = 0, pb_dse_is_primary_file = 0, > pb_schema_flags = 0, pb_result_code = 0, pb_result_text = 0x0, pb_result_matched = 0x0, pb_nentries = 0, urls = 0x0, pb_import_entry = 0x0, pb_import_state = 0, > pb_destroy_content = 0, pb_dse_reapply_mods = 0, pb_urp_naming_collision_dn = 0x0, pb_urp_tombstone_uniqueid = 0x0, pb_server_running = 0, pb_backend_count = 1, > pb_pwpolicy_ctrl = 0, pb_vattr_context = 0x0, pb_substrlens = 0x0, pb_plugin_enabled = 0, pb_search_ctrls = 0x0, pb_mr_index_sv_fn = 0x0, pb_syntax_filter_normalized = 0, > pb_syntax_filter_data = 0x0, pb_paged_results_index = 0, pb_paged_results_cookie = 0, pwdpolicy = 0x0, op_stack_elem = 0x7f87f8e24d30, pb_aci_target_check = 0, > pb_pw_entry = 0x0} > pb = 0x7f87b4ff0a90 > conn = 0x7f87d82d0768 > op = 0x7f87f931bf80 > tag = 102 > need_wakeup = 0 > thread_turbo_flag = > ret = > more_data = 0 > ---Type to continue, or q to quit--- > replication_connection = 0 > doshutdown = 0 > maxthreads = 5 > enable_nunc_stans = 0 > bypasspollcnt = > #6 0x00007f87f62299bb in _pt_root () from /lib64/libnspr4.so > No symbol table info available. > #7 0x00007f87f5bc9dc5 in start_thread (arg=0x7f87b4ff1700) at pthread_create.c:308 > __res = > pd = 0x7f87b4ff1700 > now = > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140220833928960, -5233892399363934943, 0, 140220833929664, 140220833928960, 1, 5211249063945286945, 5211388174174106913}, > mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} > not_first_call = > pagesize_m1 = > sp = > freesize = > #8 0x00007f87f58f873d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 > No locals. > > >>> I performed an ?ipactl restart? on the affected server and attempted >>> again with the same issue. >>> >>> I tried adding a non-posix group and it was successful. >>> >>> >>> >>> I found the dirsrv logs and see the error ?dna-plugin - dna_pre_op: no >>> more values available!!? which lead me to >>> https://www.redhat.com/archives/freeipa-users/2014- >> February/msg00247.h >>> tml >>> >>> >>> >>> Performing the ldapserch I see: >>> >>> dnaMaxValue is 1100 >>> >>> dnaNextValue is 1101 >>> >>> dnaThreshold is 500 >> Right. A master only gets a range when it needs one. In this case it needed >> one after the master holding the entire range went away. >> >>> I also did ?ipa idrange-find?, which shows: >>> >>> >>> >>> --------------- >>> >>> 1 range matched >>> >>> --------------- >>> >>> Range name: MYDOMAIN.COM_id_range >>> >>> First Posix ID of the range: 1946000000 >>> >>> Number of IDs in the range: 200000 >>> >>> Range type: local domain range >>> >>> ---------------------------- >>> >>> Number of entries returned 1 >>> >>> ---------------------------- >>> >>> >>> >>> >>> >>> So now my question is what do I need to change to fix the issue? >>> >>> I can do the ldapmodify to adjust the dnaMaxValue, but I don?t know >>> what I should be adjusting the idrange to? >>> >>> I?d like to keep the idrange the same and just adjust the dnaMaxValue, >>> so would I need to change dnaMaxValue to 200000? >> See https://blog-rcritten.rhcloud.com/?p=50 >> >> rob > Thank you. > Setting the id ranges manually fixed my problem. > > > From andrew.krause at breakthroughfuel.com Thu Apr 20 17:47:52 2017 From: andrew.krause at breakthroughfuel.com (Andrew Krause) Date: Thu, 20 Apr 2017 17:47:52 +0000 Subject: [Freeipa-users] Freeipa web UI: An error has occurred (IPA Error 4302: CertificateFormatError) In-Reply-To: References: Message-ID: Sorry for the self bump but no one has any insight on this? > On Apr 17, 2017, at 11:31 AM, Andrew Krause wrote: > > Many hosts in our web ui show a null status for ?enrolled?. When you do a search that includes any of these host objects the web UI posts errors, and if you click on one of the problem hosts the same error stops anything from loading on the host page. > > I?ve been trying to solve this problem on my own for quite some time and have not been successful. It?s impossible to remove the host through the web UI and using CLI commands seem to remove the entry from IPA (host is not found with ipa host-find), but it is still visible in the UI. One thing that may be common with all of these hosts is that they were enrolled with our IPA system back while we were running version 3.0 and likely have had issues for quite some time. Multiple updates have happened since then, and all of our hosts added within the last year are working fine. I suspect there?s an issue with a path somewhere for a certificate database, but I?m unable to pinpoint what is going wrong. > > > I?m currently cloning 2 of my IPA servers into a private dmz to test fixes so I can try things without worry... > > 1. Realized we had many certificates that were expired and not renewing with ?getcert list? on primary IPA server > 2. Tried every document I could find on renewing the certificates but was never completely successful (on version 4.1 which is our current in production) > 3. Upgraded to 4.4 and was actually able to renew all certificates listed on the main IPA server showing current below > 4. After having success with #3 I was able to start the CA service without error and everything on the server seems to be working as expected > 5. Have attempted many variations of removing a problem host and adding it back, but the errors in the web UI persist. > > Output from "getcert list": > > Number of certificates and requests being tracked: 8. > Request ID '20160901214852': > 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=DOMAIN.COM > subject: CN=CA Audit,O=DOMAIN.COM > expires: 2018-08-22 22:13:44 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 '20160901214853': > 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=DOMAIN.COM > subject: CN=OCSP Subsystem,O=DOMAIN.COM > expires: 2018-08-22 21:49:26 UTC > 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 '20160901214854': > 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=DOMAIN.COM > subject: CN=CA Subsystem,O=DOMAIN.COM > expires: 2018-08-22 21:49:18 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 '20160901214855': > 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=DOMAIN.COM > subject: CN=Certificate Authority,O=DOMAIN.COM > expires: 2036-09-01 05:05:00 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 '20160901214856': > 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=DOMAIN.COM > subject: CN=IPA RA,O=DOMAIN.COM > expires: 2018-08-22 22:15:36 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 '20160901214857': > 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=DOMAIN.COM > subject: CN=hostname07.domain.com,O=DOMAIN.COM > expires: 2018-07-31 23:31:17 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 "Server-Cert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20160901214858': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM/pwdfile.txt' > certificate: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=DOMAIN.COM > subject: CN=hostname07.domain.com,O=DOMAIN.COM > expires: 2018-08-22 23:31:28 UTC > principal name: ldap/hostname07.domain.com at DOMAIN.COM > 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 DOMAIN-COM > track: yes > auto-renew: yes > Request ID '20160901214859': > 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=DOMAIN.COM > subject: CN=hostname07.domain.com,O=DOMAIN.COM > expires: 2018-08-22 23:31:19 UTC > principal name: HTTP/hostname07.domain.com at DOMAIN.COM > 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 > > > > > Output for "certutil -L -d /var/lib/pki/pki-tomcat/alias/" > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > Server-Cert cert-pki-ca u,u,u > Certificate Authority - DOMAIN.COM CTu,cu,u > subsystemCert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > caSigningCert cert-pki-ca u,u,u > ocspSigningCert cert-pki-ca u,u,u > > > > > Output for latest selftests.log for pki-tomcatd: > > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: Initializing self test plugins: > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading all self test plugin instances > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: loading self test plugins in startup order > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] CAPresence: CA is present > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SystemCertsVerification: system certs verification success > 0.localhost-startStop-1 - [17/Apr/2017:10:11:53 CDT] [20] [1] SelfTestSubsystem: All CRITICAL self test plugins ran SUCCESSFULLY at startup! > > > > Any assistance would be greatly appreciated. > > Andrew Krause > > -- > 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 Thu Apr 20 18:03:33 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Apr 2017 14:03:33 -0400 Subject: [Freeipa-users] Freeipa web UI: An error has occurred (IPA Error 4302: CertificateFormatError) In-Reply-To: References: Message-ID: <82d4fa2d-73af-b4ec-21ea-f1a931daf624@redhat.com> Andrew Krause wrote: > Sorry for the self bump but no one has any insight on this? > > >> On Apr 17, 2017, at 11:31 AM, Andrew Krause wrote: >> >> Many hosts in our web ui show a null status for ?enrolled?. When you do a search that includes any of these host objects the web UI posts errors, and if you click on one of the problem hosts the same error stops anything from loading on the host page. >> >> I?ve been trying to solve this problem on my own for quite some time and have not been successful. It?s impossible to remove the host through the web UI and using CLI commands seem to remove the entry from IPA (host is not found with ipa host-find), but it is still visible in the UI. One thing that may be common with all of these hosts is that they were enrolled with our IPA system back while we were running version 3.0 and likely have had issues for quite some time. Multiple updates have happened since then, and all of our hosts added within the last year are working fine. I suspect there?s an issue with a path somewhere for a certificate database, but I?m unable to pinpoint what is going wrong. It should not be possible to have different views in the UI and the CLI since they make the same backend calls. What you'd want to do, hopefully on a semi-quiet system, is to do a host-find on the CLI and then list all hosts in the UI and compare the logs in /var/log/httpd/error_log and look at the LDAP queries in /var/log/dirsrv/slapd-REALM/access (this is a buffered log so be patient). They should be doing more or less the exact same set of queries. Very doubtful that this has anything to do with certs. Anything on the client would be completely separate from what is on the server. One thing you may be seeing though is that in 3.0 clients a host certificate was obtained for it. This was dropped with 4.0, but it wouldn't affect any visibility on the server. rob From simon.williams at thehelpfulcat.com Thu Apr 20 21:46:03 2017 From: simon.williams at thehelpfulcat.com (Simon Williams) Date: Thu, 20 Apr 2017 21:46:03 +0000 Subject: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA Message-ID: Yesterday, Chrome on both my Ubuntu and Windows machines updated to version 58.0.3029.81. It appears that this version of Chrome will not trust certificates based on Common Name. Looking at the Chrome documentation and borne out by one of the messages, from Chrome 58, the subjectAltName is required to identify the DNS name of the host that the certificate is issued for. I would be grateful if someone could point me in the direction of how to recreate my SSL certificates so that the subjectAltName is populated. Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Apr 20 23:31:16 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 20 Apr 2017 19:31:16 -0400 Subject: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA In-Reply-To: References: Message-ID: I can confirm that I see this behaviour too. My ipa server install is a pretty stock install with no 3rd party certificates. On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams < simon.williams at thehelpfulcat.com> wrote: > Yesterday, Chrome on both my Ubuntu and Windows machines updated to > version 58.0.3029.81. It appears that this version of Chrome will not > trust certificates based on Common Name. Looking at the Chrome > documentation and borne out by one of the messages, from Chrome 58, > the subjectAltName is required to identify the DNS name of the host that > the certificate is issued for. I would be grateful if someone could point > me in the direction of how to recreate my SSL certificates so that > the subjectAltName is populated. > > Thanks in advance > > -- > 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 ftweedal at redhat.com Fri Apr 21 01:06:30 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 21 Apr 2017 11:06:30 +1000 Subject: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA In-Reply-To: References: Message-ID: <20170421010630.GR21957@dhcp-40-8.bne.redhat.com> On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote: > I can confirm that I see this behaviour too. My ipa server install is a > pretty stock install with no 3rd party certificates. > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams < > simon.williams at thehelpfulcat.com> wrote: > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated to > > version 58.0.3029.81. It appears that this version of Chrome will not > > trust certificates based on Common Name. Looking at the Chrome > > documentation and borne out by one of the messages, from Chrome 58, > > the subjectAltName is required to identify the DNS name of the host that > > the certificate is issued for. I would be grateful if someone could point > > me in the direction of how to recreate my SSL certificates so that > > the subjectAltName is populated. > > > > Thanks in advance > > > > -- > > 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 > > Which version of IPA are you using? The first thing you should do, which I think should be sufficient in most cases, is to tell certmonger to submit a new cert request for each affected certificate, instructing to include the relevant DNSName in the subjectAltName extension in the CSR. To list certmonger tracking requests and look for the HTTPS certificate. For example: $ getcert list Number of certificate and requests being tracked: 11 ... Request ID '20170418012901': 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=IPA.LOCAL 201703211317 subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317 expires: 2019-03-22 03:20:19 UTC dns: f25-2.ipa.local 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 ... Using the Request ID of the HTTPS certificate, resubmit the request but use the ``-D `` option to specify a DNSName to include in the SAN extension: $ getcert resubmit -i -D ``-D `` can be specified multiple times, if necessary. This should request a new certificate that will have the server DNS name in the SAN extension. HTH, Fraser From ftweedal at redhat.com Fri Apr 21 01:26:10 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 21 Apr 2017 11:26:10 +1000 Subject: [Freeipa-users] U2F and ipa for ssh In-Reply-To: References: Message-ID: <20170421012609.GS21957@dhcp-40-8.bne.redhat.com> On Thu, Apr 20, 2017 at 08:04:34AM -0400, Marc Boorshtein wrote: > Has anyone looked into using U2F with freeipa? My guess is you would need > a customized ssh client to interact with the device but in theory you could > just transform the users U2F public key into an ssh key. > > Marc Boorshtein > CTO, Tremolo Security, Inc. Hi Marc, We have had preliminary discussion about U2F. As you suggest, U2F requires client support. U2F does not provide a general signing operation (it only signs a specific kind of message[1]) so some server support is probably required as well. [1] https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-raw-message-formats-v1.1-id-20160915.html#authentication-response-message-success That said, a lot of U2F devices have additional / alternative modes with PKCS #11 interfaces, e.g. PIV, allowing them to be used as generic crypto tokens. Thanks, Fraser From skg at smcs.ac.in Fri Apr 21 04:42:04 2017 From: skg at smcs.ac.in (Sameer Gurung) Date: Fri, 21 Apr 2017 10:12:04 +0530 Subject: [Freeipa-users] Weird problem with DNS updates from dhcp clients Message-ID: Hi all, I have installed freeipa server in a centos macning with about 70 client machines running linux mint. Since I am in a mixed enviroment my DHCP server is running in windows 2008 r2. The setup and joining the ipa domain went off without a hitch. However I now find that when the IP addresses of my client change they do not update the ipa dns server. And the weird thing is if i log in to the client machine and manually put the network on and off using the NetworkManager applet it updates the ipa dns server with the new ip. That is the only way the update happens. I would appreciate any help in this .. I have been struggling to up my network for a while and its driving me insane with regards, *-----------Sameer -----------* -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Saint Mary's College, Shillong, Meghalaya, India-793003, smcs.ac.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Apr 21 06:49:43 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 21 Apr 2017 09:49:43 +0300 Subject: [Freeipa-users] U2F and ipa for ssh In-Reply-To: <20170421012609.GS21957@dhcp-40-8.bne.redhat.com> References: <20170421012609.GS21957@dhcp-40-8.bne.redhat.com> Message-ID: <20170421064943.jqlop62axkurwvwh@redhat.com> On pe, 21 huhti 2017, Fraser Tweedale wrote: >On Thu, Apr 20, 2017 at 08:04:34AM -0400, Marc Boorshtein wrote: >> Has anyone looked into using U2F with freeipa? My guess is you would need >> a customized ssh client to interact with the device but in theory you could >> just transform the users U2F public key into an ssh key. >> >> Marc Boorshtein >> CTO, Tremolo Security, Inc. > >Hi Marc, > >We have had preliminary discussion about U2F. > >As you suggest, U2F requires client support. U2F does not provide a >general signing operation (it only signs a specific kind of >message[1]) so some server support is probably required as well. > >[1] https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-raw-message-formats-v1.1-id-20160915.html#authentication-response-message-success > >That said, a lot of U2F devices have additional / alternative modes >with PKCS #11 interfaces, e.g. PIV, allowing them to be used as >generic crypto tokens. I've looked at Yubikey's U2F pam module and, as with many others, it is a module to check against a local source. We need to spend some time doing actual design to see what can be stored centrally and how mapping to login as other users can be done, but it would be nice to have this integrated, yes. -- / Alexander Bokovoy From tkrizek at redhat.com Fri Apr 21 07:16:37 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 21 Apr 2017 09:16:37 +0200 Subject: [Freeipa-users] Weird problem with DNS updates from dhcp clients In-Reply-To: References: Message-ID: <53c84ca0-d104-6ff8-3b15-dfb75df813e6@redhat.com> On 04/21/2017 06:42 AM, Sameer Gurung wrote: > Hi all, > > I have installed freeipa server in a centos macning with about 70 > client machines running linux mint. Since I am in a mixed enviroment > my DHCP server is running in windows 2008 r2. The setup and joining > the ipa domain went off without a hitch. However I now find that when > the IP addresses of my client change they do not update the ipa dns > server. And the weird thing is if i log in to the client machine and > manually put the network on and off using the NetworkManager applet it > updates the ipa dns server with the new ip. That is the only way the > update happens. Dynamic DNS updates are handled by SSSD. If they're enabled, DNS record is updated when the identity provider comes online, the system reboots or at a specified interval. If you want periodically update the DNS records, configure dyndns_refresh_interval option in /etc/sssd/sssd.conf. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 -------------- 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 b.harries at protonmail.com Fri Apr 21 14:06:03 2017 From: b.harries at protonmail.com (B.harries) Date: Fri, 21 Apr 2017 10:06:03 -0400 Subject: [Freeipa-users] FreeIPA update guidance Message-ID: Hi All, As I am new to the list, I'd like to introduce myself as Bennie. In my fairly small (CentOS based) organization we use FreeIPA and we are honestly really happy with this all in one solution. Lately however we are facing an issue regarding updating FreeIPA and I was hoping I could find some guidance on this mail list =). Current situation We are currently running FreeIPA 4.3.1 on Fedora 23. When we started using FreeIPA, CentOS was lacking quite behind so we choose to go with Fedora. As Fedora 23 is quite out of date now we tried to perform a dist-upgrade, enabling us to continue using FreeIPA on the 4.4 branch. This dist-upgrade however led to an inoperable condition of FreeIPA, mainly the PKI service fails miserably. Second attempt We then tried to install a fresh CentOS server, having FreeIPA version 4.4 and attaching it as a second master to our IPA instance. This however didn't work out as well, probably because the directory structures are not equal. So far, everything failed. I was wondering if anyone here faced similar problems and might be able to point in the right direction? Thanks in advance for a reply! Bennie -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Fri Apr 21 15:54:04 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 21 Apr 2017 11:54:04 -0400 Subject: [Freeipa-users] FreeIPA update guidance In-Reply-To: References: Message-ID: <51934667-cc69-42ff-00c9-c8e6544467bf@damascusgrp.com> I don't know that what we did is the most correct or even best way to manage an upgrade, but here's what I did. We started with two nodes, ipa1 and ipa2. Both running Fedora. I built a new system, ipa3, and installed IPA on it, then made it a replica. I then removed the replication agreements to ipa1 and upgraded it. Then made it a replica again using ipa3 as the master. Finally, I removed ipa2's replication agreement and upgraded it. Again, it was brought back into replication by creating a replication file on ipa3 and copying it to ipa2. Somewhere in there, I'm pretty sure I had to do something with the CA to ensure we still had one, but for the life of me, I can't remember what I did! Good luck! Bret On 04/21/2017 10:06 AM, B.harries wrote: > Hi All, > > As I am new to the list, I'd like to introduce myself as Bennie. In my > fairly small (CentOS based) organization we use FreeIPA and we are > honestly really happy with this all in one solution. Lately however we > are facing an issue regarding updating FreeIPA and I was hoping I > could find some guidance on this mail list =). > > *Current situation* > We are currently running FreeIPA 4.3.1 on Fedora 23. When we started > using FreeIPA, CentOS was lacking quite behind so we choose to go with > Fedora. As Fedora 23 is quite out of date now we tried to perform a > dist-upgrade, enabling us to continue using FreeIPA on the 4.4 branch. > This dist-upgrade however led to an inoperable condition of FreeIPA, > mainly the PKI service fails miserably. > > *Second attempt* > We then tried to install a fresh CentOS server, having FreeIPA version > 4.4 and attaching it as a second master to our IPA instance. This > however didn't work out as well, probably because the directory > structures are not equal. > > So far, everything failed. I was wondering if anyone here faced > similar problems and might be able to point in the right direction? > > Thanks in advance for a reply! > > > Bennie > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.harries at protonmail.com Fri Apr 21 15:55:02 2017 From: b.harries at protonmail.com (B.harries) Date: Fri, 21 Apr 2017 11:55:02 -0400 Subject: [Freeipa-users] FreeIPA update guidance In-Reply-To: <83vapxpynp.fsf@jochen.org> References: <83vapxpynp.fsf@jochen.org> Message-ID: Hi Jochen, Thanks for your quick reply! As I just left the office I don't have the log ATM. The installation however failed after setting up de Tomcat PKI service, where the ipa-replica-install script was waiting for the service to come up. While manually trying to reach the service using Curl, I also never got a response. After running the Tomcat PKI service manually, I got an error stating that the user "cn=,cn=config" doesn't exist in the directory. When manually querying the directory I noticed the same, it did however exist with an additional CN. I will retry the replication excersise next monday and hopefully your tip will help me. Then I can also provide the logs. I will keep you updated! Thanks, Bennie -------- Original Message -------- Subject: Re: [Freeipa-users] FreeIPA update guidance Local Time: April 21, 2017 5:29 PM UTC Time: April 21, 2017 3:29 PM From: jochen at jochen.org To: B.harries freeipa-users\@redhat.com "B.harries" writes: > Second attempt > We then tried to install a fresh CentOS server, having FreeIPA version > 4.4 and attaching it as a second master to our IPA instance. This > however didn't work out as well, I did that to move my installation from Fedora to CentOS - it worked quite well. First adding a replica failed, because python-jwcrypto on CentOS is quite old. I've installed the package from Fedora (python-jwcrypto-0.3.2-1.fc23.noarch.rpm) and all went well. After I decomissioned the Fedora system I've downgraded the package again. That's what I found: https://www.redhat.com/archives/freeipa-users/2016-December/msg00024.html (Re: [Freeipa-users] Add 4.4 replica to 4.3 server fails) Can you provide logs/messages what didn't work? Jochen -- This space is intentionally left blank. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Fri Apr 21 15:29:14 2017 From: jochen at jochen.org (Jochen Hein) Date: Fri, 21 Apr 2017 17:29:14 +0200 Subject: [Freeipa-users] FreeIPA update guidance In-Reply-To: (B. harries's message of "Fri, 21 Apr 2017 10:06:03 -0400") References: Message-ID: <83vapxpynp.fsf@jochen.org> "B.harries" writes: > Second attempt > We then tried to install a fresh CentOS server, having FreeIPA version > 4.4 and attaching it as a second master to our IPA instance. This > however didn't work out as well, I did that to move my installation from Fedora to CentOS - it worked quite well. First adding a replica failed, because python-jwcrypto on CentOS is quite old. I've installed the package from Fedora (python-jwcrypto-0.3.2-1.fc23.noarch.rpm) and all went well. After I decomissioned the Fedora system I've downgraded the package again. That's what I found: https://www.redhat.com/archives/freeipa-users/2016-December/msg00024.html (Re: [Freeipa-users] Add 4.4 replica to 4.3 server fails) Can you provide logs/messages what didn't work? Jochen -- This space is intentionally left blank. From dewanggaba at xtremenitro.org Sat Apr 22 08:00:16 2017 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Sat, 22 Apr 2017 15:00:16 +0700 Subject: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s) Message-ID: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! I've successfully create replica, everything works fine but why my signed CA certificate didn't automatically transfer to another replica(s)? Is it normal? Trying to add manually, but the certificate in replica(s) still using self-signed. Here's the output from `ipa-certupdate -v` https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdIGYhyR LivL9gydE= Interesting line was : ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found ipa: DEBUG: Starting external process ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA cert -a ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert : PR_FILE_NOT_FOUND_ERROR: File not found FYI: The replica server previously was a client and promoted to be a replica by hitting this command: `ipa-replica-install --principal admin --admin-password admin_password` Any hints? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQI4BAEBCAAiBQJY+w2NGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcFn2EACjKLkv3XokuWsJwjXSyKV3IP6Gh54Os/bNVkAS5rBb5unRl/BQ FG1eV5/Mgq0kSBbbC5C1qvXwSjeaJMjul0ssJ+fldL4d0S+S+s/nos7BsyjZZaQV VP1c4iRrCUeHt//FdTaN9AslsW+2IUlKQ5qFBX+1cN8Kc4Q9yIBmr4e1p94dJCnu z8Fwe/RZS1e69QOWLdfNYsEhGiwXKVqyWaX139kvpOXOaj41yehC0Zzkli6HxpFu lypSRHFAPYLt9fWS0pglPk3PQFLlGC5bNYLTFdADeVn1siME6eZl09+cUUFp2o79 bF2/7+g98QExJ9LY6IxUrrvgvc42c9dX7SY2GU1niEIyxcwXbxt8gWoY91YjEIGX Ibq5vc6FnsQB2rN3L+nO5WvwimH4wEqnFU1YJ+dDh+A80G25JQuLZ4ZBYsuH7rVE T0TH9KEYD8BR46ca9prhv1WNVt0wDDgfWRLc6afLBdJ2eUrx7uXijauyibevc1mI X2OfKELlejsrcDb6hyoS3z18cOES9oJmfpsrNdxGi2X59HVp1o67R4QprQ9ZrGld Eb4njQRXF45O4ZSWT6tGteltf1KVKfoKaxL41S8DPf3wY1JFy/OmtYjNx5fSLcPL b+TRSimv5q6YWIw5/mqmVlsdife5XnFTGSIBBOkssLx0qnqcpCetuoCnQw== =jRl3 -----END PGP SIGNATURE----- From dewanggaba at xtremenitro.org Sat Apr 22 08:41:03 2017 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Sat, 22 Apr 2017 15:41:03 +0700 Subject: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s) In-Reply-To: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> References: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> Message-ID: <681cdb4a-84d9-5813-bb4d-91519b8057e8@xtremenitro.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! Just update, manually add external CA(s) and signed certificated was successful, but why it's didn't automatically transferred to replica(s) from master. On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote: > Hello! > > I've successfully create replica, everything works fine but why my > signed CA certificate didn't automatically transfer to another > replica(s)? Is it normal? > > Trying to add manually, but the certificate in replica(s) still > using self-signed. Here's the output from `ipa-certupdate -v` > https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdIGYh yR > > LivL9gydE= > > Interesting line was : > > ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: > DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a > ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA : > PR_FILE_NOT_FOUND_ERROR: File not found > > ipa: DEBUG: Starting external process ipa: DEBUG: > args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA cert -a > ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert > : PR_FILE_NOT_FOUND_ERROR: File not found > > FYI: The replica server previously was a client and promoted to be > a replica by hitting this command: `ipa-replica-install > --principal admin --admin-password admin_password` > > Any hints? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQI4BAEBCAAiBQJY+xccGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcJAHEACO4nF7guN05MjmqYFDwDrjhvWgMN2sRn+Nxt/aA+xziIOJJGaA Rr97TbODiTiefBkjVoiYM6dxr6VK5ViPZIbe0IAjafCRACAKggyCRtb2j8+vb7Jd imJN/MC0zSMCdATSs2b95uT7QrUiVHwt/xmKzJ44ezIYON+YOtgndk0QXynXHqjm H6HcQkh4ZcC8antiFdbC+H8z4Iv4Ypnhdr80RtqLqQ6esnZXnWdIg3X0aRb6w1fw KEDHemhfKeu5hMxpi2AQdesO4j+XhvW6TfvKymScbWv1PoEuLAsgQGdoxVmhkjN8 LKixSghHlg8A61DXtA9J2uaPUUKjVMmoKH4CFD0RLQlQJ+f4KfApbNzHZTBnSL8D 64c5WjJdtAY5LUArakwZ/EJt5N5AJEFDIoSWM3if/jpDIVFEAaDzFKIQvyLKyMIn yHxNIcWcSoP/YwzZXMttWx5dNRkermmWEcvPsqovoT9BRlI/e700o3xqQk7V0720 7TniU1uZaBpLkJOxHUoWssaWfVHcWEBnw0UeU7bl4nKnAo7hkQs3/iJXwQiLk4aw 338ZIniIrDSmUmmfqJuhQrFPNK+heCOno5O/99Sa1bs0lTQgRRjMq5Q7mIajEYYI NedyVj0VQ8R42rbgomWJPJP/uU+kirN8CpEc+d/IWNQE2t+5hOX5nme5dw== =anzk -----END PGP SIGNATURE----- From prasun.gera at gmail.com Sun Apr 23 07:32:19 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Sun, 23 Apr 2017 03:32:19 -0400 Subject: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA In-Reply-To: <20170421010630.GR21957@dhcp-40-8.bne.redhat.com> References: <20170421010630.GR21957@dhcp-40-8.bne.redhat.com> Message-ID: Thank you. That worked for the master. How do I fix the replica's cert ? This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using ipa's DNS at all. Did this happen because of that ? On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale wrote: > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote: > > I can confirm that I see this behaviour too. My ipa server install is a > > pretty stock install with no 3rd party certificates. > > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams < > > simon.williams at thehelpfulcat.com> wrote: > > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated to > > > version 58.0.3029.81. It appears that this version of Chrome will not > > > trust certificates based on Common Name. Looking at the Chrome > > > documentation and borne out by one of the messages, from Chrome 58, > > > the subjectAltName is required to identify the DNS name of the host > that > > > the certificate is issued for. I would be grateful if someone could > point > > > me in the direction of how to recreate my SSL certificates so that > > > the subjectAltName is populated. > > > > > > Thanks in advance > > > > > > -- > > > 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 > > > > Which version of IPA are you using? > > The first thing you should do, which I think should be sufficient in > most cases, is to tell certmonger to submit a new cert request for > each affected certificate, instructing to include the relevant > DNSName in the subjectAltName extension in the CSR. > > To list certmonger tracking requests and look for the HTTPS > certificate. For example: > > $ getcert list > Number of certificate and requests being tracked: 11 > ... > Request ID '20170418012901': > 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=IPA.LOCAL 201703211317 > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317 > expires: 2019-03-22 03:20:19 UTC > dns: f25-2.ipa.local > 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 > ... > > Using the Request ID of the HTTPS certificate, resubmit the request > but use the ``-D `` option to specify a DNSName to include > in the SAN extension: > > $ getcert resubmit -i -D > > ``-D `` can be specified multiple times, if necessary. > > This should request a new certificate that will have the server DNS > name in the SAN extension. > > HTH, > Fraser > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Sun Apr 23 10:10:14 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Sun, 23 Apr 2017 06:10:14 -0400 Subject: [Freeipa-users] List SPAM In-Reply-To: <5beedf04-1769-9abf-62d0-14401f6bbb7c@redhat.com> References: <5beedf04-1769-9abf-62d0-14401f6bbb7c@redhat.com> Message-ID: This still continues to be a problem. Was any solution identified for this ? Why are the emails not obfuscated on the public archives ? On Tue, Dec 27, 2016 at 7:32 AM, Martin Basti wrote: > > > On 27.12.2016 13:22, Outback Dingo wrote: > >> Im still getting nude porn spam emails and pics from a user >> >> Kimi Rachel >> >> > It is not a user, it is a SPAM bot mining public archives. We don't have > any control about it we can just un-publish archives (tested, spam stopped > after that) but they contain a lot of information for users. > > JFTR the email is changing. > > > -- > 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 dewanggaba at xtremenitro.org Sun Apr 23 11:20:07 2017 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Sun, 23 Apr 2017 18:20:07 +0700 Subject: [Freeipa-users] List SPAM In-Reply-To: References: <5beedf04-1769-9abf-62d0-14401f6bbb7c@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark as spam, and they gone from my inbox. :) On 04/23/2017 05:10 PM, Prasun Gera wrote: > This still continues to be a problem. Was any solution identified > for this ? Why are the emails not obfuscated on the public archives > ? > > On Tue, Dec 27, 2016 at 7:32 AM, Martin Basti > wrote: > > > > On 27.12.2016 13:22, Outback Dingo wrote: > > Im still getting nude porn spam emails and pics from a user > > Kimi Rachel > > > > It is not a user, it is a SPAM bot mining public archives. We > don't have any control about it we can just un-publish archives > (tested, spam stopped after that) but they contain a lot of > information for users. > > JFTR the email is changing. > > > -- 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 > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQI4BAEBCAAiBQJY/I3kGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcLLgEAChyD/U8wlcTlwjiWgcbyLOcwrFsfvJ1HKUKPi4+fh3VDtX1iQF XwSyxeMch+obLEraKXI01+rpk6cgxg2xWnhxcUOobsVPzFoQVFnYU9+Ngxpgajx9 XRigMU4lxwBf33IO3DOM7iUGdw4DfRaVZ5H3UUv/6JaQmxwyL6rmxVjcbhMFBcnG p6Mw+xzsWlIgmf5Kz8e/Eu3pxZXgrxOddtI5z9e7ApZiRavtdi5SuNIEHPsVNC0j 6P2eNA/zK3E3IpfknWB2wCoR2+gB/1fYzP71iz55exy3Sefnv0CLpjnhRoPsuzVm iiFeBF64KOYWmK0Uw3ftfNEw67bHPcvlnba4Ftj2PsTkwupH9/RpccQ0t9yOl+gi fdmY7s91MdODNXiKR5GG/bT5JPyBE5VtkufZIqJDLliqn1kVkCLqSgOLZyQflhI6 2pZLHufBMiMGKgdEfSx1DdqmPILLqlIhr+kqAn0qtyIDlz1jV5cic9issi4Z/aWi MVECMBkPu5kNnANVKBz2YjbL8LD/Dr15R2WZVH7drzAc4Byo88DRpwESSqS0W4hX ai1nVTxyD8CdW8Ab63rLwmvF8li39V1Xse2hiinntaYa/Ap6/WFNOR7Qyon5yxnG /AFpAgtWgH0rjnNMNnYZO3Ck7hpSgdCCgqOTOKc+3FHqqcg+K7uckqdswg== =G2rj -----END PGP SIGNATURE----- From ftweedal at redhat.com Mon Apr 24 00:50:12 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 24 Apr 2017 10:50:12 +1000 Subject: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA In-Reply-To: References: <20170421010630.GR21957@dhcp-40-8.bne.redhat.com> Message-ID: <20170424005012.GV21957@dhcp-40-8.bne.redhat.com> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote: > Thank you. That worked for the master. How do I fix the replica's cert ? > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using > ipa's DNS at all. Did this happen because of that ? > This is not related to DNS. To fix the replica, log onto the host and perform the same steps with Certmonger there. The tracking Request ID will be different but otherwise the process is the same. Cheers, Fraser > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale > wrote: > > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote: > > > I can confirm that I see this behaviour too. My ipa server install is a > > > pretty stock install with no 3rd party certificates. > > > > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams < > > > simon.williams at thehelpfulcat.com> wrote: > > > > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated to > > > > version 58.0.3029.81. It appears that this version of Chrome will not > > > > trust certificates based on Common Name. Looking at the Chrome > > > > documentation and borne out by one of the messages, from Chrome 58, > > > > the subjectAltName is required to identify the DNS name of the host > > that > > > > the certificate is issued for. I would be grateful if someone could > > point > > > > me in the direction of how to recreate my SSL certificates so that > > > > the subjectAltName is populated. > > > > > > > > Thanks in advance > > > > > > > > -- > > > > 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 > > > > > > Which version of IPA are you using? > > > > The first thing you should do, which I think should be sufficient in > > most cases, is to tell certmonger to submit a new cert request for > > each affected certificate, instructing to include the relevant > > DNSName in the subjectAltName extension in the CSR. > > > > To list certmonger tracking requests and look for the HTTPS > > certificate. For example: > > > > $ getcert list > > Number of certificate and requests being tracked: 11 > > ... > > Request ID '20170418012901': > > 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=IPA.LOCAL 201703211317 > > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317 > > expires: 2019-03-22 03:20:19 UTC > > dns: f25-2.ipa.local > > 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 > > ... > > > > Using the Request ID of the HTTPS certificate, resubmit the request > > but use the ``-D `` option to specify a DNSName to include > > in the SAN extension: > > > > $ getcert resubmit -i -D > > > > ``-D `` can be specified multiple times, if necessary. > > > > This should request a new certificate that will have the server DNS > > name in the SAN extension. > > > > HTH, > > Fraser > > From prasun.gera at gmail.com Mon Apr 24 02:08:11 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Sun, 23 Apr 2017 22:08:11 -0400 Subject: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA In-Reply-To: <20170424005012.GV21957@dhcp-40-8.bne.redhat.com> References: <20170421010630.GR21957@dhcp-40-8.bne.redhat.com> <20170424005012.GV21957@dhcp-40-8.bne.redhat.com> Message-ID: I tried that, but the replica's "getcert list" doesn't seem to show any results. "Number of certificates and requests being tracked: 0." Is that expected ? On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale wrote: > On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote: > > Thank you. That worked for the master. How do I fix the replica's cert ? > > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using > > ipa's DNS at all. Did this happen because of that ? > > > This is not related to DNS. > > To fix the replica, log onto the host and perform the same steps > with Certmonger there. The tracking Request ID will be different > but otherwise the process is the same. > > Cheers, > Fraser > > > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale > > wrote: > > > > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote: > > > > I can confirm that I see this behaviour too. My ipa server install > is a > > > > pretty stock install with no 3rd party certificates. > > > > > > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams < > > > > simon.williams at thehelpfulcat.com> wrote: > > > > > > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated to > > > > > version 58.0.3029.81. It appears that this version of Chrome will > not > > > > > trust certificates based on Common Name. Looking at the Chrome > > > > > documentation and borne out by one of the messages, from Chrome 58, > > > > > the subjectAltName is required to identify the DNS name of the host > > > that > > > > > the certificate is issued for. I would be grateful if someone > could > > > point > > > > > me in the direction of how to recreate my SSL certificates so that > > > > > the subjectAltName is populated. > > > > > > > > > > Thanks in advance > > > > > > > > > > -- > > > > > 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 > > > > > > > > Which version of IPA are you using? > > > > > > The first thing you should do, which I think should be sufficient in > > > most cases, is to tell certmonger to submit a new cert request for > > > each affected certificate, instructing to include the relevant > > > DNSName in the subjectAltName extension in the CSR. > > > > > > To list certmonger tracking requests and look for the HTTPS > > > certificate. For example: > > > > > > $ getcert list > > > Number of certificate and requests being tracked: 11 > > > ... > > > Request ID '20170418012901': > > > 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=IPA.LOCAL 201703211317 > > > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317 > > > expires: 2019-03-22 03:20:19 UTC > > > dns: f25-2.ipa.local > > > 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 > > > ... > > > > > > Using the Request ID of the HTTPS certificate, resubmit the request > > > but use the ``-D `` option to specify a DNSName to include > > > in the SAN extension: > > > > > > $ getcert resubmit -i -D > > > > > > ``-D `` can be specified multiple times, if necessary. > > > > > > This should request a new certificate that will have the server DNS > > > name in the SAN extension. > > > > > > HTH, > > > Fraser > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Mon Apr 24 02:24:25 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Sun, 23 Apr 2017 22:24:25 -0400 Subject: [Freeipa-users] List SPAM In-Reply-To: References: <5beedf04-1769-9abf-62d0-14401f6bbb7c@redhat.com> Message-ID: That doesn't work very well. The spam bots use different emails. And gmail marks the entire message thread as spam, not just the spam reply. On Sun, Apr 23, 2017 at 7:20 AM, Dewangga Bachrul Alam < dewanggaba at xtremenitro.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mark as spam, and they gone from my inbox. :) > > On 04/23/2017 05:10 PM, Prasun Gera wrote: > > This still continues to be a problem. Was any solution identified > > for this ? Why are the emails not obfuscated on the public archives > > ? > > > > On Tue, Dec 27, 2016 at 7:32 AM, Martin Basti > > wrote: > > > > > > > > On 27.12.2016 13:22, Outback Dingo wrote: > > > > Im still getting nude porn spam emails and pics from a user > > > > Kimi Rachel > > > > > > > > It is not a user, it is a SPAM bot mining public archives. We > > don't have any control about it we can just un-publish archives > > (tested, spam stopped after that) but they contain a lot of > > information for users. > > > > JFTR the email is changing. > > > > > > -- 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 > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQI4BAEBCAAiBQJY/I3kGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl > f9IgoCjNcLLgEAChyD/U8wlcTlwjiWgcbyLOcwrFsfvJ1HKUKPi4+fh3VDtX1iQF > XwSyxeMch+obLEraKXI01+rpk6cgxg2xWnhxcUOobsVPzFoQVFnYU9+Ngxpgajx9 > XRigMU4lxwBf33IO3DOM7iUGdw4DfRaVZ5H3UUv/6JaQmxwyL6rmxVjcbhMFBcnG > p6Mw+xzsWlIgmf5Kz8e/Eu3pxZXgrxOddtI5z9e7ApZiRavtdi5SuNIEHPsVNC0j > 6P2eNA/zK3E3IpfknWB2wCoR2+gB/1fYzP71iz55exy3Sefnv0CLpjnhRoPsuzVm > iiFeBF64KOYWmK0Uw3ftfNEw67bHPcvlnba4Ftj2PsTkwupH9/RpccQ0t9yOl+gi > fdmY7s91MdODNXiKR5GG/bT5JPyBE5VtkufZIqJDLliqn1kVkCLqSgOLZyQflhI6 > 2pZLHufBMiMGKgdEfSx1DdqmPILLqlIhr+kqAn0qtyIDlz1jV5cic9issi4Z/aWi > MVECMBkPu5kNnANVKBz2YjbL8LD/Dr15R2WZVH7drzAc4Byo88DRpwESSqS0W4hX > ai1nVTxyD8CdW8Ab63rLwmvF8li39V1Xse2hiinntaYa/Ap6/WFNOR7Qyon5yxnG > /AFpAgtWgH0rjnNMNnYZO3Ck7hpSgdCCgqOTOKc+3FHqqcg+K7uckqdswg== > =G2rj > -----END PGP SIGNATURE----- > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From BJB at jndata.dk Mon Apr 24 07:37:18 2017 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Mon, 24 Apr 2017 07:37:18 +0000 Subject: [Freeipa-users] ipa-replica-install failes on setup-ca Message-ID: <89213DDB84447F44A8E8950A5C2185E04CD4A035@SJN01013.jnmain00.corp.jndata.net> We had problems with one idm replica complaining about different ldap database versions and at the same time errors on starting pki-tomcat. I decided to delete the ipa server and reinstall. The ipa server delete went without problems, but the reinstall.... ipa-replica-install --setup-ca --setup-dns --forwarder 10.200.207.11 --forwarder 10.200.206.11 --principal admin --admin-password "secret" This fails on ca install, but without set-up ca the install was succesfull. I tried both with the server enrolled as client and with the server not enrolled - no difference. The installation was successful in a different envirionment but same software versions. server is rhel 7.3, ipa: VERSION: 4.4.0, API_VERSION: 2.213 When ipa-replica-install fails with -setup-ca ipareplica-install.log shows : 2017-04-23T19:44:45Z DEBUG Starting external process 2017-04-23T19:44:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X 2017-04-23T19:44:46Z DEBUG Process finished, return code=1 2017-04-23T19:44:46Z DEBUG stdout=Log file: /var/log/pki/pki-ca-spawn.20170423214445.log Loading deployment configuration from /tmp/tmpBLQe1X. 2017-04-23T19:44:46Z DEBUG stderr=Traceback (most recent call last): File "/usr/sbin/pkispawn", line 817, in main(sys.argv) File "/usr/sbin/pkispawn", line 501, in main create_master_dictionary(parser) File "/usr/sbin/pkispawn", line 641, in create_master_dictionary parser.compose_pki_master_dictionary() File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 614, in compose_pki_master_dictionary instance.load() File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line 595, in load subsystem.load() File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line 129, in load lines = open(self.cs_conf).read().splitlines() IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/ca/conf/CS.cfg' 2017-04-23T19:44:46Z CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X' returned non-zero exit status 1 2017-04-23T19:44:46Z CRITICAL See the installation logs and the following files/directories for more information: 2017-04-23T19:44:46Z CRITICAL /var/log/pki/pki-tomcat 2017-04-23T19:44:46Z 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/cainstance.py", line 586, in __spawn_instance DogtagInstance.spawn_instance(self, cfg_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 181, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 420, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) RuntimeError: CA configuration failed. 2017-04-23T19:44:46Z DEBUG [error] RuntimeError: CA configuration failed. 2017-04-23T19:44:46Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/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(): Nothing in /var/log/pki/pki-tomcat. Further observations: During changing the certificate to thirdparty ssl, I got the following error in /var/log/httpd/error_log : [Mon Apr 24 09:03:14.267871 2017] [:error] [pid 11004] Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved. p11-kit: couldn't open and map file: /etc/pki/ca-trust/source/ipa.p11-kit: Permission denied I changed the permission on /etc/pki/ca-trust/source/ipa.p11-kit from 600 to 644 and added "NSSEnforceValidCerts off" to /etc/httpd/conf.d/nss.conf After that ipa-certupdate succeeded. Are there any way to install the ca without reinstalling the whole ipa-server again? Regards Bjarne Blichfeldt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.dunkel at aixigo.de Mon Apr 24 12:24:34 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Mon, 24 Apr 2017 14:24:34 +0200 Subject: [Freeipa-users] sssd, krb5_child.log: Received error code 1432158221 Message-ID: <8815bf10-0674-7414-3954-c7daeec1dde6@aixigo.de> Hi folks, some colleagues have to enter their password 3 times (or even more) to authenticate. krb5_child.log shows (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [switch_creds] (0x0200): Switch user to [657][100]. (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [become_user] (0x0200): Trying to become user [657][100]. (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [get_and_save_tgt] (0x0020): 1302: [-1765328360][Preauthentication failed] (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [map_krb5_error] (0x0020): 1371: [-1765328360][Preauthentication failed] (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [k5c_send_data] (0x0200): Received error code 1432158221 (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [switch_creds] (0x0200): Switch user to [657][100]. (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [become_user] (0x0200): Trying to become user [657][100]. (Mon Apr 3 10:45:28 2017) [[sssd[krb5_child[5186]]]] [get_and_save_tgt] (0x0020): 1302: [-1765328360][Preauthentication failed] (Mon Apr 3 10:45:28 2017) [[sssd[krb5_child[5186]]]] [map_krb5_error] (0x0020): 1371: [-1765328360][Preauthentication failed] (Mon Apr 3 10:45:28 2017) [[sssd[krb5_child[5186]]]] [k5c_send_data] (0x0200): Received error code 1432158221 (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [switch_creds] (0x0200): Switch user to [657][100]. (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [become_user] (0x0200): Trying to become user [657][100]. (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [get_and_save_tgt] (0x0020): 1302: [-1765328360][Preauthentication failed] (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [map_krb5_error] (0x0020): 1371: [-1765328360][Preauthentication failed] (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [k5c_send_data] (0x0200): Received error code 1432158221 (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [switch_creds] (0x0200): Switch user to [657][100]. (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [become_user] (0x0200): Trying to become user [657][100]. (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [k5c_send_data] (0x0200): Received error code 0 sssd_pam.log: (Mon Apr 3 10:45:20 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Mon Apr 3 10:45:20 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Mon Apr 3 10:45:20 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz (Mon Apr 3 10:45:20 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [8 (Insufficient credentials to access authentication data)][example.com] (Mon Apr 3 10:45:20 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [8]: Insufficient credentials to access authentication data. (Mon Apr 3 10:45:20 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 (Mon Apr 3 10:45:22 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Mon Apr 3 10:45:27 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Mon Apr 3 10:45:27 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Mon Apr 3 10:45:27 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz (Mon Apr 3 10:45:28 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [8 (Insufficient credentials to access authentication data)][example.com] (Mon Apr 3 10:45:28 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [8]: Insufficient credentials to access authentication data. (Mon Apr 3 10:45:28 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 (Mon Apr 3 10:45:30 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Mon Apr 3 10:45:33 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Mon Apr 3 10:45:33 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Mon Apr 3 10:45:33 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz (Mon Apr 3 10:45:33 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [8 (Insufficient credentials to access authentication data)][example.com] (Mon Apr 3 10:45:33 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [8]: Insufficient credentials to access authentication data. (Mon Apr 3 10:45:33 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 (Mon Apr 3 10:45:35 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][example.com] (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sysdb_set_entry_attr] (0x0200): Entry [name=juppschmitz at example.com,cn=users,cn=example.com,cn=sysdb] has set [cache, ts_cache] attrs. (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 73 (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][example.com] (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][example.com] (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 (Mon Apr 3 10:45:39 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! Did they enter just a bad password? What can I do to make authentication more reliable? sssd version is 1.15.0-3, backported from Debian Testing to Jessie. Every helpful hint is highly appreciated Harri From sbose at redhat.com Mon Apr 24 13:48:24 2017 From: sbose at redhat.com (Sumit Bose) Date: Mon, 24 Apr 2017 15:48:24 +0200 Subject: [Freeipa-users] sssd, krb5_child.log: Received error code 1432158221 In-Reply-To: <8815bf10-0674-7414-3954-c7daeec1dde6@aixigo.de> References: <8815bf10-0674-7414-3954-c7daeec1dde6@aixigo.de> Message-ID: <20170424134824.GB18989@p.Speedport_W_724V_Typ_A_05011603_00_011> On Mon, Apr 24, 2017 at 02:24:34PM +0200, Harald Dunkel wrote: > Hi folks, > > some colleagues have to enter their password 3 times (or even > more) to authenticate. krb5_child.log shows > > (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [switch_creds] (0x0200): Switch user to [657][100]. > (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [switch_creds] (0x0200): Switch user to [0][0]. > (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [become_user] (0x0200): Trying to become user [657][100]. > (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [get_and_save_tgt] (0x0020): 1302: [-1765328360][Preauthentication failed] > (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [map_krb5_error] (0x0020): 1371: [-1765328360][Preauthentication failed] > (Mon Apr 3 10:45:20 2017) [[sssd[krb5_child[5116]]]] [k5c_send_data] (0x0200): Received error code 1432158221 > (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [switch_creds] (0x0200): Switch user to [657][100]. > (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [switch_creds] (0x0200): Switch user to [0][0]. > (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Mon Apr 3 10:45:27 2017) [[sssd[krb5_child[5186]]]] [become_user] (0x0200): Trying to become user [657][100]. > (Mon Apr 3 10:45:28 2017) [[sssd[krb5_child[5186]]]] [get_and_save_tgt] (0x0020): 1302: [-1765328360][Preauthentication failed] > (Mon Apr 3 10:45:28 2017) [[sssd[krb5_child[5186]]]] [map_krb5_error] (0x0020): 1371: [-1765328360][Preauthentication failed] > (Mon Apr 3 10:45:28 2017) [[sssd[krb5_child[5186]]]] [k5c_send_data] (0x0200): Received error code 1432158221 > (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [switch_creds] (0x0200): Switch user to [657][100]. > (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [switch_creds] (0x0200): Switch user to [0][0]. > (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [become_user] (0x0200): Trying to become user [657][100]. > (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [get_and_save_tgt] (0x0020): 1302: [-1765328360][Preauthentication failed] > (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [map_krb5_error] (0x0020): 1371: [-1765328360][Preauthentication failed] > (Mon Apr 3 10:45:33 2017) [[sssd[krb5_child[5243]]]] [k5c_send_data] (0x0200): Received error code 1432158221 > (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [switch_creds] (0x0200): Switch user to [657][100]. > (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [switch_creds] (0x0200): Switch user to [0][0]. > (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [become_user] (0x0200): Trying to become user [657][100]. > (Mon Apr 3 10:45:39 2017) [[sssd[krb5_child[5304]]]] [k5c_send_data] (0x0200): Received error code 0 Please re-run with a higher log level. E.g. it would be good to know if all requests where send to the same KDC or different ones? If the requests were send to different KDCs it might be a time skew issue, although I would expect a different error code here. Do you have KDC logs for those requests? bye, Sumit > > sssd_pam.log: > > (Mon Apr 3 10:45:20 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. > (Mon Apr 3 10:45:20 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. > (Mon Apr 3 10:45:20 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz > (Mon Apr 3 10:45:20 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [8 (Insufficient credentials to access authentication data)][example.com] > (Mon Apr 3 10:45:20 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [8]: Insufficient credentials to access authentication data. > (Mon Apr 3 10:45:20 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 > (Mon Apr 3 10:45:22 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! > (Mon Apr 3 10:45:27 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. > (Mon Apr 3 10:45:27 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. > (Mon Apr 3 10:45:27 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz > (Mon Apr 3 10:45:28 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [8 (Insufficient credentials to access authentication data)][example.com] > (Mon Apr 3 10:45:28 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [8]: Insufficient credentials to access authentication data. > (Mon Apr 3 10:45:28 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 > (Mon Apr 3 10:45:30 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! > (Mon Apr 3 10:45:33 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. > (Mon Apr 3 10:45:33 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. > (Mon Apr 3 10:45:33 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz > (Mon Apr 3 10:45:33 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [8 (Insufficient credentials to access authentication data)][example.com] > (Mon Apr 3 10:45:33 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [8]: Insufficient credentials to access authentication data. > (Mon Apr 3 10:45:33 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 > (Mon Apr 3 10:45:35 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][example.com] > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sysdb_set_entry_attr] (0x0200): Entry [name=juppschmitz at example.com,cn=users,cn=example.com,cn=sysdb] has set [cache, ts_cache] attrs. > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 73 > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][example.com] > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'juppschmitz' matched without domain, user is juppschmitz > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][example.com] > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26 > (Mon Apr 3 10:45:39 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected! > > > Did they enter just a bad password? What can I do to make authentication > more reliable? > > sssd version is 1.15.0-3, backported from Debian Testing > to Jessie. > > Every helpful hint is highly appreciated > Harri > > -- > 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 b.harries at protonmail.com Mon Apr 24 14:18:20 2017 From: b.harries at protonmail.com (B.harries) Date: Mon, 24 Apr 2017 10:18:20 -0400 Subject: [Freeipa-users] FreeIPA update guidance In-Reply-To: References: <83vapxpynp.fsf@jochen.org> Message-ID: <3Ahy9Khk2tF8ky0AXYQr7UlRh7iG-j2bSjFkME_jv2TQ2u8Ax3_3BF7oh34pRgJElJPzrcpTVIqAv6oSrlkN1H0TB2Hpp7c5QSUAEnrgfRY=@protonmail.com> Hi All, As you might be interested, today we re-attempted to create a replica. Apparently, exactly the same problem was reported to Red Hat Bugzilla ten days ago: https://bugzilla.redhat.com/show_bug.cgi?id=1432016 Our replica install also fails on the following point: [...] Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/27]: creating certificate server user [2/27]: configuring certificate server instance [3/27]: stopping certificate server instance to update CS.cfg [4/27]: backing up CS.cfg [5/27]: disabling nonces [6/27]: set up CRL publishing [7/27]: enable PKIX certificate path discovery and validation [8/27]: starting certificate server instance < hangs here indefinitely > At this moment we are thus stuck and waiting for the new package to be released. Thanks for the pointers! Bennie -------- Original Message -------- Subject: Re: [Freeipa-users] FreeIPA update guidance Local Time: 21 april 2017 5:55 PM UTC Time: 21 april 2017 15:55 From: b.harries at protonmail.com To: Jochen Hein freeipa-users\@redhat.com Hi Jochen, Thanks for your quick reply! As I just left the office I don't have the log ATM. The installation however failed after setting up de Tomcat PKI service, where the ipa-replica-install script was waiting for the service to come up. While manually trying to reach the service using Curl, I also never got a response. After running the Tomcat PKI service manually, I got an error stating that the user "cn=,cn=config" doesn't exist in the directory. When manually querying the directory I noticed the same, it did however exist with an additional CN. I will retry the replication excersise next monday and hopefully your tip will help me. Then I can also provide the logs. I will keep you updated! Thanks, Bennie -------- Original Message -------- Subject: Re: [Freeipa-users] FreeIPA update guidance Local Time: April 21, 2017 5:29 PM UTC Time: April 21, 2017 3:29 PM From: jochen at jochen.org To: B.harries freeipa-users\@redhat.com "B.harries" writes: > Second attempt > We then tried to install a fresh CentOS server, having FreeIPA version > 4.4 and attaching it as a second master to our IPA instance. This > however didn't work out as well, I did that to move my installation from Fedora to CentOS - it worked quite well. First adding a replica failed, because python-jwcrypto on CentOS is quite old. I've installed the package from Fedora (python-jwcrypto-0.3.2-1.fc23.noarch.rpm) and all went well. After I decomissioned the Fedora system I've downgraded the package again. That's what I found: https://www.redhat.com/archives/freeipa-users/2016-December/msg00024.html (Re: [Freeipa-users] Add 4.4 replica to 4.3 server fails) Can you provide logs/messages what didn't work? Jochen -- This space is intentionally left blank. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at cazena.com Mon Apr 24 18:22:47 2017 From: dan at cazena.com (Dan Dietterich) Date: Mon, 24 Apr 2017 18:22:47 +0000 Subject: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled In-Reply-To: <6B2D8D3A-3148-413E-B403-FA032B4BBC96@cazena.com> References: <3a293c5f-a76f-bdb9-a52a-757badc956bc@redhat.com> <151666ee-cba0-b4f1-a763-9e6bdc34dfdd@redhat.com> <6B2D8D3A-3148-413E-B403-FA032B4BBC96@cazena.com> Message-ID: I still think there is something wrong here. You say that the DNSSEC reply is "just warning", but when I get that warning, a subsequent trust-add fails every time. When I don't get the warning, the trust-add works. Therefore, the warning cannot just be ignored. Why is that? I have tried the following: - Signing the target Active Directory zone ? it does not make a difference - FreeIPA /etc/named.conf ? "validation no" makes the warning go away ONLY when I use the CLI on a root login. - Running the ipa CLI from a salt state or a subprocess of my Java webapp ALWAYS gets the warning regardless. If there really should be a warning, then why don't I see it from the CLI? And can you help me understand what would be significantly different between an interactive login and a "su ?l root" in salt? Thank you for any insight, Dan From: Dan Dietterich Date: Wednesday, April 19, 2017 at 9:24 AM To: Martin Ba?ti , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled From: Martin Ba?ti Date: Wednesday, April 19, 2017 at 9:23 AM To: Dan Dietterich , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled IPA servers always check if DNSSEC is working on forwarders, but it is just warning. If you have disabled dnssec in named.conf then it is okay. I'm not sure why sometimes you see this warning and sometimes don't, maybe inconsistent replies from forwarder. domain ".internal" should always fail because it is unregistered TLD Martin On 19.04.2017 15:11, Dan Dietterich wrote: My configuration is a single ipa server and both the code path and the bash prompt path are running on the node that is also running the ipa server. I thought that since FreeIPA was installed with --no-dnssec-validation that I should never see this warning. And I confirmed that both dnssec-enabled and dnssec-validation are set to 'no' in the /etc/named.conf. So I'm confused that you say the DNSSEC should always fail. Thanks for your help! From: Martin Ba?ti Date: Wednesday, April 19, 2017 at 3:59 AM To: Dan Dietterich , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled On 13.04.2017 22:50, Dan Dietterich wrote: I am seeing inconsistent results configuring a DNS forward zone. At a bash prompt, as root, after kinit admin, I do: ipa dnsforwardzone-add domain.internal --forwarder= ww.xx.yy.zz --forward-policy=only That works fine and does not warn about DNSSEC. In a Java webapp running as root under a Jetty, I run a shell sub-process and issue the kinit and the same ipa statement. _Sometimes_, I get ipa: WARNING: DNSSEC validation failed: record 'domain.internal. SOA' failed DNSSEC validation on server ww.xx.yy.zz. Please verify your DNSSEC configuration or disable DNSSEC validation on all IPA servers. I modified the /etc/named.conf file to say: dnssec-enable no; dnssec-validation no; and systemctl restart ipa Any clue why the results are different? ipa ?version: VERSION: 4.4.0, API_VERSION: 2.213 Linux ? 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Thanks for any insight! Regards, Dan Hello, checks are done on IPA server side, how many servers do you have? Is possible that CLI connects to different servers. However in this case, DNSSEC check should always fail and report error, so it is weird why it passed. Martin -- Martin Ba?ti Software Engineer Red Hat Czech -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Apr 25 07:44:34 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Tue, 25 Apr 2017 09:44:34 +0200 Subject: [Freeipa-users] DNSSEC warning when DNSSEC should be disabled In-Reply-To: References: <3a293c5f-a76f-bdb9-a52a-757badc956bc@redhat.com> <151666ee-cba0-b4f1-a763-9e6bdc34dfdd@redhat.com> <6B2D8D3A-3148-413E-B403-FA032B4BBC96@cazena.com> Message-ID: <0f02b27b-6ab0-a80b-cf07-77f20db2c870@redhat.com> On 24.04.2017 20:22, Dan Dietterich wrote: > > I still think there is something wrong here. > > You say that the DNSSEC reply is "just warning", but when I get that > warning, a subsequent trust-add fails every time. When I don't get the > warning, the trust-add works. > > Therefore, the warning cannot just be ignored. Why is that? > If you have disabled DNSSEC validation then the issue is probably somewhere else in DNS. The check is not 100% reliable, sometimes it may false positively report DNSSEC issues when there is a different DNS issue. Please try to "dig" AD domain and check if records are correct, also check if FreeIPA domain is accessible from AD side. Also in case of failure please check journalctl -u named-pkcs11 log on FreeIPA server, there might be additional information. > I have tried the following: > > -Signing the target Active Directory zone ? it does not make a difference > Then there is a different issue than DNSSEC IMO > -FreeIPA /etc/named.conf ? "validation no" makes the warning go away > ONLY when I use the CLI on a root login. > This check is done on server side, so there is no difference between CLI/webUI or used user > -Running the ipa CLI from a salt state or a subprocess of my Java > webapp ALWAYS gets the warning regardless. > > If there really should be a warning, then why don't I see it from the CLI? > > And can you help me understand what would be significantly different > between an interactive login and a "su ?l root" in salt? > > Thank you for any insight, > > Dan > > *From: *Dan Dietterich > *Date: *Wednesday, April 19, 2017 at 9:24 AM > *To: *Martin Ba?ti , "freeipa-users at redhat.com" > > *Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should be > disabled > > *From: *Martin Ba?ti > *Date: *Wednesday, April 19, 2017 at 9:23 AM > *To: *Dan Dietterich , "freeipa-users at redhat.com" > > *Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should be > disabled > > IPA servers always check if DNSSEC is working on forwarders, but it is > just warning. If you have disabled dnssec in named.conf then it is okay. > > I'm not sure why sometimes you see this warning and sometimes don't, > maybe inconsistent replies from forwarder. > > domain ".internal" should always fail because it is unregistered TLD > > Martin > > On 19.04.2017 15:11, Dan Dietterich wrote: > > My configuration is a single ipa server and both the code path and > the bash prompt path are running on the node that is also running > the ipa server. I thought that since FreeIPA was installed with > --no-dnssec-validation that I should never see this warning. And I > confirmed that both dnssec-enabled and dnssec-validation are set > to 'no' in the /etc/named.conf. > > So I'm confused that you say the DNSSEC should always fail. > > Thanks for your help! > > *From: *Martin Ba?ti > *Date: *Wednesday, April 19, 2017 at 3:59 AM > *To: *Dan Dietterich , > "freeipa-users at redhat.com" > > *Subject: *Re: [Freeipa-users] DNSSEC warning when DNSSEC should > be disabled > > On 13.04.2017 22:50, Dan Dietterich wrote: > > I am seeing inconsistent results configuring a DNS forward zone. > > At a bash prompt, as root, after kinit admin, I do: > > ipa dnsforwardzone-add domain.internal --forwarder= > ww.xx.yy.zz --forward-policy=only > > That works fine and does not warn about DNSSEC. > > In a Java webapp running as root under a Jetty, I run a shell > sub-process and issue the kinit and the same ipa statement. > > _/Sometimes/_, I get > > ipa: WARNING: DNSSEC validation failed: record > 'domain.internal. SOA' failed DNSSEC validation on server > ww.xx.yy.zz. > > Please verify your DNSSEC configuration or disable DNSSEC > validation on all IPA servers. > > I modified the /etc/named.conf file to say: > > dnssec-enable no; > > dnssec-validation no; > > and systemctl restart ipa > > Any clue why the results are different? > > ipa ?version: VERSION: 4.4.0, API_VERSION: 2.213 > > Linux ? 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 > UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > > Thanks for any insight! > > Regards, > > Dan > > > > > > Hello, > > checks are done on IPA server side, how many servers do you have? > Is possible that CLI connects to different servers. > > However in this case, DNSSEC check should always fail and report > error, so it is weird why it passed. > > Martin > > > -- > > Martin Ba?ti > > Software Engineer > > Red Hat Czech > > > > -- > Martin Ba?ti > Software Engineer > Red Hat Czech -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Tue Apr 25 07:52:27 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 25 Apr 2017 09:52:27 +0200 Subject: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s) In-Reply-To: <681cdb4a-84d9-5813-bb4d-91519b8057e8@xtremenitro.org> References: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> <681cdb4a-84d9-5813-bb4d-91519b8057e8@xtremenitro.org> Message-ID: <9fcc4dcb-52e2-83e2-72c3-222f4ac1ab22@redhat.com> Hi, As your email refers to self-signed and signed CA certificate, can you please clarify the exact steps that you followed? It looks like - you first installed FreeIPA with a self-signed CA - you added an external CA (did you use ipa-cacert-manage install on 1 server then ipa-certupdate on all replicas?) - you replaced the httpd/LDAP certificates with a cert signed from the external CA (you probably ran ipa-server-certinstall on one server). In this case it is normal that the httpd/LDAP certificates on the replica were not updated as they are different (each IPA server has his own httpd/LDAP cert which contains the hostname in its subject). You can check this by performing on each server: ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert | grep Subject: Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM" ^^^^^^^^^ If the goal is to replace the httpd/LDAP certificates on the replica, the command ipa-server-certinstall must also be run on the replica with the appropriate certificate. HTH, Flo. On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello! > > Just update, manually add external CA(s) and signed certificated was > successful, but why it's didn't automatically transferred to > replica(s) from master. > > On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote: >> Hello! >> >> I've successfully create replica, everything works fine but why my >> signed CA certificate didn't automatically transfer to another >> replica(s)? Is it normal? >> >> Trying to add manually, but the certificate in replica(s) still >> using self-signed. Here's the output from `ipa-certupdate -v` >> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdIGYh > yR >> >> > LivL9gydE= >> >> Interesting line was : >> >> ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: >> DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a >> ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA : >> PR_FILE_NOT_FOUND_ERROR: File not found >> >> ipa: DEBUG: Starting external process ipa: DEBUG: >> args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA cert -a >> ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> FYI: The replica server previously was a client and promoted to be >> a replica by hitting this command: `ipa-replica-install >> --principal admin --admin-password admin_password` >> >> Any hints? >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQI4BAEBCAAiBQJY+xccGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl > f9IgoCjNcJAHEACO4nF7guN05MjmqYFDwDrjhvWgMN2sRn+Nxt/aA+xziIOJJGaA > Rr97TbODiTiefBkjVoiYM6dxr6VK5ViPZIbe0IAjafCRACAKggyCRtb2j8+vb7Jd > imJN/MC0zSMCdATSs2b95uT7QrUiVHwt/xmKzJ44ezIYON+YOtgndk0QXynXHqjm > H6HcQkh4ZcC8antiFdbC+H8z4Iv4Ypnhdr80RtqLqQ6esnZXnWdIg3X0aRb6w1fw > KEDHemhfKeu5hMxpi2AQdesO4j+XhvW6TfvKymScbWv1PoEuLAsgQGdoxVmhkjN8 > LKixSghHlg8A61DXtA9J2uaPUUKjVMmoKH4CFD0RLQlQJ+f4KfApbNzHZTBnSL8D > 64c5WjJdtAY5LUArakwZ/EJt5N5AJEFDIoSWM3if/jpDIVFEAaDzFKIQvyLKyMIn > yHxNIcWcSoP/YwzZXMttWx5dNRkermmWEcvPsqovoT9BRlI/e700o3xqQk7V0720 > 7TniU1uZaBpLkJOxHUoWssaWfVHcWEBnw0UeU7bl4nKnAo7hkQs3/iJXwQiLk4aw > 338ZIniIrDSmUmmfqJuhQrFPNK+heCOno5O/99Sa1bs0lTQgRRjMq5Q7mIajEYYI > NedyVj0VQ8R42rbgomWJPJP/uU+kirN8CpEc+d/IWNQE2t+5hOX5nme5dw== > =anzk > -----END PGP SIGNATURE----- > From flo at redhat.com Tue Apr 25 08:30:14 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 25 Apr 2017 10:30:14 +0200 Subject: [Freeipa-users] ipa-replica-install failes on setup-ca In-Reply-To: <89213DDB84447F44A8E8950A5C2185E04CD4A035@SJN01013.jnmain00.corp.jndata.net> References: <89213DDB84447F44A8E8950A5C2185E04CD4A035@SJN01013.jnmain00.corp.jndata.net> Message-ID: On 04/24/2017 09:37 AM, Bjarne Blichfeldt wrote: > We had problems with one idm replica complaining about different ldap > database versions and at the same time errors on starting pki-tomcat. I > decided to delete the ipa server and reinstall. > > The ipa server delete went without problems, but the reinstall?. > > > > ipa-replica-install --setup-ca --setup-dns --forwarder 10.200.207.11 > --forwarder 10.200.206.11 --principal admin --admin-password ?secret? > > > > This fails on ca install, but without set-up ca the install was succesfull. > > I tried both with the server enrolled as client and with the server not > enrolled ? no difference. > > The installation was successful in a different envirionment but same > software versions. > > > > > > server is rhel 7.3, ipa: VERSION: 4.4.0, API_VERSION: 2.213 > > > > When ipa-replica-install fails with ?setup-ca ipareplica-install.log > shows : > > 2017-04-23T19:44:45Z DEBUG Starting external process > > 2017-04-23T19:44:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X > > 2017-04-23T19:44:46Z DEBUG Process finished, return code=1 > > 2017-04-23T19:44:46Z DEBUG stdout=Log file: > /var/log/pki/pki-ca-spawn.20170423214445.log > > Loading deployment configuration from /tmp/tmpBLQe1X. > > > > 2017-04-23T19:44:46Z DEBUG stderr=Traceback (most recent call last): > > File "/usr/sbin/pkispawn", line 817, in > > main(sys.argv) > > File "/usr/sbin/pkispawn", line 501, in main > > create_master_dictionary(parser) > > File "/usr/sbin/pkispawn", line 641, in create_master_dictionary > > parser.compose_pki_master_dictionary() > > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", > line 614, in compose_pki_master_dictionary > > instance.load() > > File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line > 595, in load > > subsystem.load() > > File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line > 129, in load > > lines = open(self.cs_conf).read().splitlines() > > IOError: [Errno 2] No such file or directory: > '/var/lib/pki/pki-tomcat/ca/conf/CS.cfg' > > > > 2017-04-23T19:44:46Z CRITICAL Failed to configure CA instance: Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X' returned non-zero exit status 1 > > 2017-04-23T19:44:46Z CRITICAL See the installation logs and the > following files/directories for more information: > > 2017-04-23T19:44:46Z CRITICAL /var/log/pki/pki-tomcat > > 2017-04-23T19:44:46Z 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/cainstance.py", line > 586, in __spawn_instance > > DogtagInstance.spawn_instance(self, cfg_file) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 181, in spawn_instance > > self.handle_setup_error(e) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 420, in handle_setup_error > > raise RuntimeError("%s configuration failed." % self.subsystem) > > RuntimeError: CA configuration failed. > > > > 2017-04-23T19:44:46Z DEBUG [error] RuntimeError: CA configuration failed. > > 2017-04-23T19:44:46Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > > return_value = self.run() > > File "/usr/lib/python2.7/site-packages/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(): > > > > > > Nothing in /var/log/pki/pki-tomcat. > > > > Further observations: > > During changing the certificate to thirdparty ssl, I got the following > error in /var/log/httpd/error_log : > > [Mon Apr 24 09:03:14.267871 2017] [:error] [pid 11004] Unable to verify > certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so > the server can start until the problem can be resolved. > > p11-kit: couldn't open and map file: > /etc/pki/ca-trust/source/ipa.p11-kit: Permission denied > > > > I changed the permission on /etc/pki/ca-trust/source/ipa.p11-kit from > 600 to 644 and added ?NSSEnforceValidCerts off? to > /etc/httpd/conf.d/nss.conf > > After that ipa-certupdate succeeded. > > > > Are there any way to install the ca without reinstalling the whole > ipa-server again? > > > > > > > > Regards > > Bjarne Blichfeldt. > > > > > Hi, 1/ you may find more information about the CA installation failure in /var/log/pki/pki-ca-spawn.$date.log To enable debug logs, you can create the file /etc/ipa/server.conf: $ cat /etc/ipa/server.conf [global] debug = True 2/ the error in httpd/error_log may indicate that your certificate expired, could you check if all the certificates are still valid? $ sudo certutil -L -d /etc/httpd/alias/ -n Server-Cert | grep Not Not Before: Thu Apr 20 15:03:40 2017 Not After : Sun Apr 21 15:03:40 2019 3/ I recall CA install issues when an old /root/cacert.p12 was left on a replica between uninstall and install. Can you try to delete this file and re-try the ipa-replica-install? Flo From dewanggaba at xtremenitro.org Tue Apr 25 08:56:39 2017 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Tue, 25 Apr 2017 15:56:39 +0700 Subject: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s) In-Reply-To: <9fcc4dcb-52e2-83e2-72c3-222f4ac1ab22@redhat.com> References: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> <681cdb4a-84d9-5813-bb4d-91519b8057e8@xtremenitro.org> <9fcc4dcb-52e2-83e2-72c3-222f4ac1ab22@redhat.com> Message-ID: <07a034fb-dc26-8528-cb1b-1b465fc1daee@xtremenitro.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! Master IPA Server: - - I install 1 (one) server as master (self-signed) and add/modify using external CA. - - I am using ipa-cacert-manage install then ipa-certupdate on master Replica IPA Server: - - I install 1 (one) server as client and promoted to ipa-replica: - I run `ipa-client-install` and autodiscovery - Then `ipa-replica-install --principal admin --admin-password ` I've hit ipa-certupdate -v to verbose the logs (attached at first email). Then replica server aren't using external CA(s) like master did. So, I did the same like master, using `ipa-cacert-manage` on replica, and it's work fine. If it's normal, then thanks for clarifying this. On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote: > Hi, > > As your email refers to self-signed and signed CA certificate, can > you please clarify the exact steps that you followed? It looks > like - you first installed FreeIPA with a self-signed CA - you > added an external CA (did you use ipa-cacert-manage install on 1 > server then ipa-certupdate on all replicas?) - you replaced the > httpd/LDAP certificates with a cert signed from the external CA > (you probably ran ipa-server-certinstall on one server). > > In this case it is normal that the httpd/LDAP certificates on the > replica were not updated as they are different (each IPA server has > his own httpd/LDAP cert which contains the hostname in its > subject). You can check this by performing on each server: > ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert | > grep Subject: Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM" > ^^^^^^^^^ > > If the goal is to replace the httpd/LDAP certificates on the > replica, the command ipa-server-certinstall must also be run on the > replica with the appropriate certificate. > > HTH, Flo. > > On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello! > > Just update, manually add external CA(s) and signed certificated > was successful, but why it's didn't automatically transferred to > replica(s) from master. > > On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote: >>>> Hello! >>>> >>>> I've successfully create replica, everything works fine but >>>> why my signed CA certificate didn't automatically transfer to >>>> another replica(s)? Is it normal? >>>> >>>> Trying to add manually, but the certificate in replica(s) >>>> still using self-signed. Here's the output from >>>> `ipa-certupdate -v` >>>> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdI GYh > >>>> yR >>>> >>>> > LivL9gydE= >>>> >>>> Interesting line was : >>>> >>>> ipa: DEBUG: stderr= ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n >>>> IPA CA -a ipa: DEBUG: Process finished, return code=255 ipa: >>>> DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find >>>> cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> ipa: DEBUG: Starting external process ipa: DEBUG: >>>> args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA >>>> cert -a ipa: DEBUG: Process finished, return code=255 ipa: >>>> DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find >>>> cert: External CA cert : PR_FILE_NOT_FOUND_ERROR: File not >>>> found >>>> >>>> FYI: The replica server previously was a client and promoted >>>> to be a replica by hitting this command: >>>> `ipa-replica-install --principal admin --admin-password >>>> admin_password` >>>> >>>> Any hints? >>>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQI4BAEBCAAiBQJY/w9DGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcBkZD/wM9ia9854l7bIy7dHxKxc7WhduFmbW3AwW0Ren+aLLER/lqMhO KPNA+fB9ojeoZagmA7JhpM9jblJ4BUaJjLnyf1vhJmOgIX0MgSfmNCr/f/EtfC9R wZLBImntbGm8yQnsA4f21sdmqnQg9CZN6cg6R8TQ+OuAXdm8jU9Pv3RCLFXzS0mW oxQdOZ9yNOC9chmfGl6Bz2oGFoEMHCsn1AcEoRHyIUU6jrCNhTVgYcHPVEz0PW73 DEY0ZkwNi9hMcGv5+5F8InYEOdOkS9Lp0juW47xRheztD/PRhYYn1m/FtOxmFa3z 3XS36/w6omSdfH2WOjBRwJduB4REmwHb9oGto7vu6FvWhwUHf9zWVjmJ6DH8tbYU XgHLmmaSIfwHWc0iYnSLcbHuOaR+l2nOSOLJNg5FfUoIJy5qO51kV3u+pGGELCdr GexkcXrEHxqk/OO9ioLlTfYIpd9NI6hdLzAsjJEbHuEVZe1B/nrkUOVy/yWOry0N 8muLkJlslMpRwGV4KRFlhcfd49mv9oylKrAxtZ843vz6F1WOKI6vbuS+SJ+wpoer P1njVQyExrlKi3ruPBIOkxQ6fab9OvredesCo13wLqhfXvezsWpL1RkiqBaMzrsk NDX/jqEEsk7gbYuawNazcQZP/NGzQZ6nBnVAkXV7vA8D/EV4y1CbW9YfXA== =07Ri -----END PGP SIGNATURE----- From uncommonkat at gmail.com Tue Apr 25 14:06:32 2017 From: uncommonkat at gmail.com (Kat) Date: Tue, 25 Apr 2017 09:06:32 -0500 Subject: [Freeipa-users] weird conflicts in AWS EC2 install Message-ID: Hi all, Trying to get letsencrypt working for an AWS instance of FreeIPA - and run into an odd conflict I have not dealt with before. When trying to install Let's Encrypt after a clean install of IPA, I am seeing: --> Finished Dependency Resolution Error: Package: python2-certbot-0.12.0-4.el7.noarch (epel) Requires: python-zope-interface Error: Package: 1:python-zope-component-4.1.0-1.el7.noarch (epel) Requires: python-zope-interface You could try using --skip-broken to work around the problem ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: ipa-admintools-4.4.0-14.el7_3.7.noarch has installed conflicts freeipa-admintools: ipa-admintools-4.4.0-14.el7_3.7.noarch ipa-client-4.4.0-14.el7_3.7.x86_64 has installed conflicts freeipa-client: ipa-client-4.4.0-14.el7_3.7.x86_64 ipa-client-common-4.4.0-14.el7_3.7.noarch has installed conflicts freeipa-client-common: ipa-client-common-4.4.0-14.el7_3.7.noarch ipa-common-4.4.0-14.el7_3.7.noarch has installed conflicts freeipa-common: ipa-common-4.4.0-14.el7_3.7.noarch ipa-server-4.4.0-14.el7_3.7.x86_64 has installed conflicts freeipa-server: ipa-server-4.4.0-14.el7_3.7.x86_64 ipa-server-common-4.4.0-14.el7_3.7.noarch has installed conflicts freeipa-server-common: ipa-server-common-4.4.0-14.el7_3.7.noarch Any ideas? Maybe this is something known in the AWS world? Thanks Kat From mbasti at redhat.com Tue Apr 25 14:22:55 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Tue, 25 Apr 2017 16:22:55 +0200 Subject: [Freeipa-users] weird conflicts in AWS EC2 install In-Reply-To: References: Message-ID: <37561406-5e55-bf4a-63e4-962ef702c0a2@redhat.com> Hello, comments inline On 25.04.2017 16:06, Kat wrote: > Hi all, > > Trying to get letsencrypt working for an AWS instance of FreeIPA - and > run into an odd conflict I have not dealt with before. When trying to > install Let's Encrypt after a clean install of IPA, I am seeing: > > --> Finished Dependency Resolution > Error: Package: python2-certbot-0.12.0-4.el7.noarch (epel) > Requires: python-zope-interface > Error: Package: 1:python-zope-component-4.1.0-1.el7.noarch (epel) > Requires: python-zope-interface > You could try using --skip-broken to work around the problem > These packages are not needed for freeipa. So it may be broken dependency of letsencrypt? > ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: > ipa-admintools-4.4.0-14.el7_3.7.noarch has installed conflicts > freeipa-admintools: ipa-admintools-4.4.0-14.el7_3.7.noarch > ipa-client-4.4.0-14.el7_3.7.x86_64 has installed conflicts > freeipa-client: ipa-client-4.4.0-14.el7_3.7.x86_64 > ipa-client-common-4.4.0-14.el7_3.7.noarch has installed conflicts > freeipa-client-common: ipa-client-common-4.4.0-14.el7_3.7.noarch > ipa-common-4.4.0-14.el7_3.7.noarch has installed conflicts > freeipa-common: ipa-common-4.4.0-14.el7_3.7.noarch > ipa-server-4.4.0-14.el7_3.7.x86_64 has installed conflicts > freeipa-server: ipa-server-4.4.0-14.el7_3.7.x86_64 > ipa-server-common-4.4.0-14.el7_3.7.noarch has installed conflicts > freeipa-server-common: ipa-server-common-4.4.0-14.el7_3.7.noarch > > Any ideas? Maybe this is something known in the AWS world? > > Thanks > Kat > Yum check gives false positive errors about IPA packages, this will be fixed in RHEL7.4. You can safely ignore those warnings. -- Martin Ba?ti Software Engineer Red Hat Czech From uncommonkat at gmail.com Tue Apr 25 14:27:07 2017 From: uncommonkat at gmail.com (Kat) Date: Tue, 25 Apr 2017 09:27:07 -0500 Subject: [Freeipa-users] weird conflicts in AWS EC2 install In-Reply-To: <37561406-5e55-bf4a-63e4-962ef702c0a2@redhat.com> References: <37561406-5e55-bf4a-63e4-962ef702c0a2@redhat.com> Message-ID: Yes- this comes after IPA is installed and running (this is actually a client upgraded to a master-replica). Then trying to install Let'sEncrypt gives the error: yum install -y letsencrypt That is when the conflict errors occur. The problem with "ignoring", is that you can't force yum to just do the install anyway unless you download the packages directly and use rpm to install. Is that the suggestion here? Thanks On 4/25/17 9:22 AM, Martin Ba?ti wrote: > Hello, > > comments inline > > > On 25.04.2017 16:06, Kat wrote: >> Hi all, >> >> Trying to get letsencrypt working for an AWS instance of FreeIPA - >> and run into an odd conflict I have not dealt with before. When >> trying to install Let's Encrypt after a clean install of IPA, I am >> seeing: >> >> --> Finished Dependency Resolution >> Error: Package: python2-certbot-0.12.0-4.el7.noarch (epel) >> Requires: python-zope-interface >> Error: Package: 1:python-zope-component-4.1.0-1.el7.noarch (epel) >> Requires: python-zope-interface >> You could try using --skip-broken to work around the problem >> > > These packages are not needed for freeipa. So it may be broken > dependency of letsencrypt? > >> ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: >> ipa-admintools-4.4.0-14.el7_3.7.noarch has installed conflicts >> freeipa-admintools: ipa-admintools-4.4.0-14.el7_3.7.noarch >> ipa-client-4.4.0-14.el7_3.7.x86_64 has installed conflicts >> freeipa-client: ipa-client-4.4.0-14.el7_3.7.x86_64 >> ipa-client-common-4.4.0-14.el7_3.7.noarch has installed conflicts >> freeipa-client-common: ipa-client-common-4.4.0-14.el7_3.7.noarch >> ipa-common-4.4.0-14.el7_3.7.noarch has installed conflicts >> freeipa-common: ipa-common-4.4.0-14.el7_3.7.noarch >> ipa-server-4.4.0-14.el7_3.7.x86_64 has installed conflicts >> freeipa-server: ipa-server-4.4.0-14.el7_3.7.x86_64 >> ipa-server-common-4.4.0-14.el7_3.7.noarch has installed conflicts >> freeipa-server-common: ipa-server-common-4.4.0-14.el7_3.7.noarch >> >> Any ideas? Maybe this is something known in the AWS world? >> >> Thanks >> Kat >> > > Yum check gives false positive errors about IPA packages, this will be > fixed in RHEL7.4. You can safely ignore those warnings. > From mbasti at redhat.com Tue Apr 25 14:30:39 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Tue, 25 Apr 2017 16:30:39 +0200 Subject: [Freeipa-users] weird conflicts in AWS EC2 install In-Reply-To: References: <37561406-5e55-bf4a-63e4-962ef702c0a2@redhat.com> Message-ID: <8c8878eb-1682-b3f2-e02f-99f677bed5af@redhat.com> FreeIPA conflicts shouldn't prevent installing of other packages. For me it looks like "python-zope-interface" is missing. On 25.04.2017 16:27, Kat wrote: > Yes- this comes after IPA is installed and running (this is actually a > client upgraded to a master-replica). Then trying to install > Let'sEncrypt gives the error: > > yum install -y letsencrypt > > That is when the conflict errors occur. The problem with "ignoring", > is that you can't force yum to just do the install anyway unless you > download the packages directly and use rpm to install. Is that the > suggestion here? > > Thanks > > > On 4/25/17 9:22 AM, Martin Ba?ti wrote: >> Hello, >> >> comments inline >> >> >> On 25.04.2017 16:06, Kat wrote: >>> Hi all, >>> >>> Trying to get letsencrypt working for an AWS instance of FreeIPA - >>> and run into an odd conflict I have not dealt with before. When >>> trying to install Let's Encrypt after a clean install of IPA, I am >>> seeing: >>> >>> --> Finished Dependency Resolution >>> Error: Package: python2-certbot-0.12.0-4.el7.noarch (epel) >>> Requires: python-zope-interface >>> Error: Package: 1:python-zope-component-4.1.0-1.el7.noarch (epel) >>> Requires: python-zope-interface >>> You could try using --skip-broken to work around the problem >>> >> >> These packages are not needed for freeipa. So it may be broken >> dependency of letsencrypt? >> >>> ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: >>> ipa-admintools-4.4.0-14.el7_3.7.noarch has installed conflicts >>> freeipa-admintools: ipa-admintools-4.4.0-14.el7_3.7.noarch >>> ipa-client-4.4.0-14.el7_3.7.x86_64 has installed conflicts >>> freeipa-client: ipa-client-4.4.0-14.el7_3.7.x86_64 >>> ipa-client-common-4.4.0-14.el7_3.7.noarch has installed conflicts >>> freeipa-client-common: ipa-client-common-4.4.0-14.el7_3.7.noarch >>> ipa-common-4.4.0-14.el7_3.7.noarch has installed conflicts >>> freeipa-common: ipa-common-4.4.0-14.el7_3.7.noarch >>> ipa-server-4.4.0-14.el7_3.7.x86_64 has installed conflicts >>> freeipa-server: ipa-server-4.4.0-14.el7_3.7.x86_64 >>> ipa-server-common-4.4.0-14.el7_3.7.noarch has installed conflicts >>> freeipa-server-common: ipa-server-common-4.4.0-14.el7_3.7.noarch >>> >>> Any ideas? Maybe this is something known in the AWS world? >>> >>> Thanks >>> Kat >>> >> >> Yum check gives false positive errors about IPA packages, this will >> be fixed in RHEL7.4. You can safely ignore those warnings. >> > -- Martin Ba?ti Software Engineer Red Hat Czech From uncommonkat at gmail.com Tue Apr 25 14:36:08 2017 From: uncommonkat at gmail.com (Kat) Date: Tue, 25 Apr 2017 09:36:08 -0500 Subject: [Freeipa-users] weird conflicts in AWS EC2 install In-Reply-To: <8c8878eb-1682-b3f2-e02f-99f677bed5af@redhat.com> References: <37561406-5e55-bf4a-63e4-962ef702c0a2@redhat.com> <8c8878eb-1682-b3f2-e02f-99f677bed5af@redhat.com> Message-ID: <7aa1101c-72f0-da21-45ae-834ae9c021dc@gmail.com> DOH!! I'm an idiot -- yep - I see what I was misreading. It can't find python-zope-interface (which is required by python-zopy-component) and *THAT* is the real error. The conflicts are just yum/rpm saying - "Hey, there are other problems, but not related". My bad - sorry to have troubled you. Kat On 4/25/17 9:30 AM, Martin Ba?ti wrote: > FreeIPA conflicts shouldn't prevent installing of other packages. For > me it looks like "python-zope-interface" is missing. > > > On 25.04.2017 16:27, Kat wrote: >> Yes- this comes after IPA is installed and running (this is actually >> a client upgraded to a master-replica). Then trying to install >> Let'sEncrypt gives the error: >> >> yum install -y letsencrypt >> >> That is when the conflict errors occur. The problem with "ignoring", >> is that you can't force yum to just do the install anyway unless you >> download the packages directly and use rpm to install. Is that the >> suggestion here? >> >> Thanks >> >> >> On 4/25/17 9:22 AM, Martin Ba?ti wrote: >>> Hello, >>> >>> comments inline >>> >>> >>> On 25.04.2017 16:06, Kat wrote: >>>> Hi all, >>>> >>>> Trying to get letsencrypt working for an AWS instance of FreeIPA - >>>> and run into an odd conflict I have not dealt with before. When >>>> trying to install Let's Encrypt after a clean install of IPA, I am >>>> seeing: >>>> >>>> --> Finished Dependency Resolution >>>> Error: Package: python2-certbot-0.12.0-4.el7.noarch (epel) >>>> Requires: python-zope-interface >>>> Error: Package: 1:python-zope-component-4.1.0-1.el7.noarch (epel) >>>> Requires: python-zope-interface >>>> You could try using --skip-broken to work around the problem >>>> >>> >>> These packages are not needed for freeipa. So it may be broken >>> dependency of letsencrypt? >>> >>>> ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: >>>> ipa-admintools-4.4.0-14.el7_3.7.noarch has installed conflicts >>>> freeipa-admintools: ipa-admintools-4.4.0-14.el7_3.7.noarch >>>> ipa-client-4.4.0-14.el7_3.7.x86_64 has installed conflicts >>>> freeipa-client: ipa-client-4.4.0-14.el7_3.7.x86_64 >>>> ipa-client-common-4.4.0-14.el7_3.7.noarch has installed conflicts >>>> freeipa-client-common: ipa-client-common-4.4.0-14.el7_3.7.noarch >>>> ipa-common-4.4.0-14.el7_3.7.noarch has installed conflicts >>>> freeipa-common: ipa-common-4.4.0-14.el7_3.7.noarch >>>> ipa-server-4.4.0-14.el7_3.7.x86_64 has installed conflicts >>>> freeipa-server: ipa-server-4.4.0-14.el7_3.7.x86_64 >>>> ipa-server-common-4.4.0-14.el7_3.7.noarch has installed conflicts >>>> freeipa-server-common: ipa-server-common-4.4.0-14.el7_3.7.noarch >>>> >>>> Any ideas? Maybe this is something known in the AWS world? >>>> >>>> Thanks >>>> Kat >>>> >>> >>> Yum check gives false positive errors about IPA packages, this will >>> be fixed in RHEL7.4. You can safely ignore those warnings. >>> >> > From huston at astro.princeton.edu Tue Apr 25 14:41:35 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Tue, 25 Apr 2017 10:41:35 -0400 Subject: [Freeipa-users] Default SELinux user changes on addition of replica? Message-ID: In the last of my testing before deployment, I had a replica server setup but things got out of sync somehow. Yesterday I severed the link with the two servers, reimaged the "bad" one, and did some poking around on the "good" one while I was at it (clearing out all of the real user data in anticipation of making another migration run into it). I remember at one point I had found the default selinux user was misconfigured, and I thought it was strange because that's on my checklist for installing a server so I know I'd done it. Oh well, changed it to the proper context again and moved on. Just this morning I made the new (previously bad) server a replica again, and after it finished I happened into the configuration page to find the default selinux user is back to unconfined_u:s0-s0:c0.c1023. Both servers report this the same, as I would expect, but I don't expect or understand why it changed again. I don't know that I'll have time to spin up more instances and go through the testing to see what/when/how it changed, but I wanted to point it out in case someone who does have that time can run with the information. -- 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 Tue Apr 25 15:34:38 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Apr 2017 11:34:38 -0400 Subject: [Freeipa-users] Default SELinux user changes on addition of replica? In-Reply-To: References: Message-ID: Steve Huston wrote: > In the last of my testing before deployment, I had a replica server > setup but things got out of sync somehow. Yesterday I severed the > link with the two servers, reimaged the "bad" one, and did some poking > around on the "good" one while I was at it (clearing out all of the > real user data in anticipation of making another migration run into > it). I remember at one point I had found the default selinux user was > misconfigured, and I thought it was strange because that's on my > checklist for installing a server so I know I'd done it. Oh well, > changed it to the proper context again and moved on. > > Just this morning I made the new (previously bad) server a replica > again, and after it finished I happened into the configuration page to > find the default selinux user is back to unconfined_u:s0-s0:c0.c1023. > Both servers report this the same, as I would expect, but I don't > expect or understand why it changed again. > > I don't know that I'll have time to spin up more instances and go > through the testing to see what/when/how it changed, but I wanted to > point it out in case someone who does have that time can run with the > information. > Seems like an update file could reset that but there isn't one that does this that I can find. I wonder if you fixed it on the "bad" one after replication had broken but before you noticed it was broken, so the value was lost when the "bad" one was dropped. I guess the only way to know for sure would be to try to duplicate it. rob From huston at astro.princeton.edu Tue Apr 25 16:14:39 2017 From: huston at astro.princeton.edu (Steve Huston) Date: Tue, 25 Apr 2017 12:14:39 -0400 Subject: [Freeipa-users] Default SELinux user changes on addition of replica? In-Reply-To: References: Message-ID: On Tue, Apr 25, 2017 at 11:34 AM, Rob Crittenden wrote: > I guess the only way to know for sure would be to try to duplicate it. I'll basically be doing that anyway, since I just found that there's some issue with password migrations too (there wasn't before, it was working, so now I'm trying to figure out why it's not) and I think I slammed the server too hard with changes when they were linked and the replica couldn't keep up. So, I removed everyone again, broke the replication, reinstalled the replica server again, and will try later once I've got this all working. Right now it has the right default user, so I'll know for sure when I create another replica :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 michael.rainey.ctr at nrlssc.navy.mil Tue Apr 25 17:38:11 2017 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Tue, 25 Apr 2017 12:38:11 -0500 Subject: [Freeipa-users] Fedora 25 - SSSD: Smart card login is broken Message-ID: Hello, While using Fedora 25 we noticed smart card login is broken with the latest update to SSSD. A month or so ago a patch was created to fix the same issue. Here are some of the details: Before Update: sssd.x86_64 1.15.2-1.fc25sb1 (was 1.15.2-1.fc25 before patch) After Update: sssd.x86_64 1.15.2-2.fc25 I was able to compared this to a freshly updated system to a system which didn't receive the same update so I am confident lies with the package update. I have also noted the "lock screen when card removed" feature is not working. Your help is greatly appreciated. Thank you, -- *Michael Rainey* -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at greg-gilbert.com Tue Apr 25 18:43:11 2017 From: greg at greg-gilbert.com (greg at greg-gilbert.com) Date: Tue, 25 Apr 2017 14:43:11 -0400 Subject: [Freeipa-users] How do you have users be given a local group? Message-ID: I saw this question come up way back in the archives, so I thought I'd ask to see if there's a better way to do it. Basically I want users who log into my servers that run the FreeIPA client to be given the local usergroup DOCKER. Is there a way to do that? Is it controlled from the FreeIPA server, or is it something (e.g. PolicyKit?) that needs to be run on each client? If it matters, the clients are running Ubuntu 16.04. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Tue Apr 25 18:52:17 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 25 Apr 2017 14:52:17 -0400 Subject: [Freeipa-users] I think I lost my CA... Message-ID: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> I recently had to upgrade all my Fedora IPA servers to C7. It went well, and we've been up and running nicely on 4.4.0 on C7 for the past month or so. Today, someone came and asked me to generate a new certificate for their web server. All was good until I went to the IPA UI and tried to perform Actions->New Certificate, which did nothing. I tried each of our 3 servers in turn. All came back with no popup window and no error, either. I suspect the problem might be that we no longer have a CA server due to the method I used to upgrade the servers. I likely missed a "--setup-ca" in there somewhere, so my rolling update rolled over the CA. What's my best hope of recovery? I never ran this before, so I'm not sure if this shows that I'm missing a CA or not: # ipa ca-find ------------ 1 CA matched ------------ Name: ipa Description IPA CA Authority ID: 3ce3346[...] Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM ---------------------------- Number of entries returned 1 ---------------------------- # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, O=DAMASCUSGRP.COM" ipa: ERROR: Failed to authenticate to CA REST API # klist Ticket cache: KEYRING:persistent:0:0 Default principal: admin at DAMASCUSGRP.COM Valid starting Expires Service principal 04/25/2017 18:48:26 04/26/2017 18:48:21 krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM # What's my best path of recovery? -- *Bret Wortman* The Damascus Group -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Apr 25 19:50:55 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 25 Apr 2017 21:50:55 +0200 Subject: [Freeipa-users] How do you have users be given a local group? In-Reply-To: References: Message-ID: <20170425195055.bzt6mya4z45tv2iv@hendrix> On Tue, Apr 25, 2017 at 02:43:11PM -0400, greg at greg-gilbert.com wrote: > I saw this question come up way back in the archives, so I thought I'd > ask to see if there's a better way to do it. > > Basically I want users who log into my servers that run the FreeIPA > client to be given the local usergroup DOCKER. I think this is what you're looking for: https://sourceware.org/glibc/wiki/Proposals/GroupMerging If you're running a libc version that supports this feature, you'd define the docker group on the IPA side with the same GID, then SSSD would deliver the group to libc and libc would merge the results from the local and the remote groups. > Is there a way to do > that? Is it controlled from the FreeIPA server, or is it something (e.g. > PolicyKit?) that needs to be run on each client? PolicyKit is the piece that enforces a policy decision based on the group membership, the trick here is to merge local and remove groups. > > If it matters, the clients are running Ubuntu 16.04. I'm sorry, I don't know if this feature is present Ubuntu 16.04.. From robert.l.harris at gmail.com Tue Apr 25 20:59:41 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Tue, 25 Apr 2017 20:59:41 +0000 Subject: [Freeipa-users] New server install failing Message-ID: I'm trying to install freeipa-server on an ubuntu 16.04 box, fresh install, but it keeps failing: {0}:/etc/apt>lsb_release -r Release: 16.04 {0}:/etc/apt>dpkg -l | egrep -i 'slapd|ipa' ii python-ipaddress 1.0.16-1 all Backport of Python 3 ipaddress module (Python 2) I added the apt repository: {0}:/etc/apt> sudo add-apt-repository ppa:freeipa/ppa * This worked, it's far up in my history {0}:/etc/apt>apt-get install freeipa-server Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libodbc1 libslp1 Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: freeipa-admintools freeipa-client freeipa-server-dns Suggested packages: libpam-krb5 The following NEW packages will be installed: freeipa-admintools freeipa-client freeipa-server freeipa-server-dns 0 upgraded, 4 newly installed, 0 to remove and 6 not upgraded. Need to get 0 B/853 kB of archives. After this operation, 3669 kB of additional disk space will be used. Do you want to continue? [Y/n] y Selecting previously unselected package freeipa-client. (Reading database ... 161356 files and directories currently installed.) Preparing to unpack .../freeipa-client_4.3.1-0ubuntu1_amd64.deb ... Unpacking freeipa-client (4.3.1-0ubuntu1) ... Selecting previously unselected package freeipa-admintools. Preparing to unpack .../freeipa-admintools_4.3.1-0ubuntu1_all.deb ... Unpacking freeipa-admintools (4.3.1-0ubuntu1) ... Selecting previously unselected package freeipa-server. Preparing to unpack .../freeipa-server_4.3.1-0ubuntu1_amd64.deb ... Unpacking freeipa-server (4.3.1-0ubuntu1) ... Selecting previously unselected package freeipa-server-dns. Preparing to unpack .../freeipa-server-dns_4.3.1-0ubuntu1_all.deb ... Unpacking freeipa-server-dns (4.3.1-0ubuntu1) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for dbus (1.10.6-1ubuntu3.3) ... Setting up freeipa-client (4.3.1-0ubuntu1) ... Setting up freeipa-admintools (4.3.1-0ubuntu1) ... Setting up freeipa-server (4.3.1-0ubuntu1) ... apache2_invoke: Enable module auth_gssapi apache2_invoke: Enable module authz_user apache2_invoke: Enable module deflate apache2_invoke: Enable module expires apache2_invoke: Enable module headers apache2_invoke: Enable module proxy apache2_invoke: Enable module proxy_ajp apache2_invoke: Enable module proxy_http apache2_invoke: Enable module rewrite 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.modified.out'* 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. dpkg: error processing package freeipa-server-dns (--configure): dependency problems - leaving unconfigured Processing triggers for dbus (1.10.6-1ubuntu3.3) ...No apport report written because the error message indicates its a followup error from a previous failure. Errors were encountered while processing: freeipa-server freeipa-server-dns E: Sub-process /usr/bin/dpkg returned an error code (1) If I search around, that slapd-EXAMPLE-COM directoryand file can be created by installing slapd but that requires 389-ds-base which conflicts with slapd. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From BJB at jndata.dk Wed Apr 26 07:27:34 2017 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Wed, 26 Apr 2017 07:27:34 +0000 Subject: [Freeipa-users] ipa-replica-install failes on setup-ca In-Reply-To: References: <89213DDB84447F44A8E8950A5C2185E04CD4A035@SJN01013.jnmain00.corp.jndata.net> Message-ID: <89213DDB84447F44A8E8950A5C2185E04CD4D1A3@SJN01013.jnmain00.corp.jndata.net> Tank you very much for your response. Adding debugging to /etc/ipa/server.conf did not add any additional information, but I discovered that -d flag to ipa-replica-install gives a lot of information. After a lot of weird stuff, problems and son on, I decided to scratch the entire server completely and start all over. Now the replica is working again. Server must have had a brain damage at some point. Venlig hilsen Bjarne Blichfeldt Infrastructure Services Direkte +4563636119 Mobile +4521593270 BJB at jndata.dk JN Data A/S * Havsteensvej 4 * 4000 Roskilde Telefon 63 63 63 63/ Fax 63 63 63 64 www.jndata.dk -----Original Message----- From: Florence Blanc-Renaud [mailto:flo at redhat.com] Sent: 25. april 2017 10:30 To: Bjarne Blichfeldt ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] ipa-replica-install failes on setup-ca On 04/24/2017 09:37 AM, Bjarne Blichfeldt wrote: > We had problems with one idm replica complaining about different ldap :snip Hi, 1/ you may find more information about the CA installation failure in /var/log/pki/pki-ca-spawn.$date.log To enable debug logs, you can create the file /etc/ipa/server.conf: $ cat /etc/ipa/server.conf [global] debug = True 2/ the error in httpd/error_log may indicate that your certificate expired, could you check if all the certificates are still valid? $ sudo certutil -L -d /etc/httpd/alias/ -n Server-Cert | grep Not Not Before: Thu Apr 20 15:03:40 2017 Not After : Sun Apr 21 15:03:40 2019 3/ I recall CA install issues when an old /root/cacert.p12 was left on a replica between uninstall and install. Can you try to delete this file and re-try the ipa-replica-install? Flo From tjaalton at ubuntu.com Wed Apr 26 08:11:57 2017 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 26 Apr 2017 11:11:57 +0300 Subject: [Freeipa-users] New server install failing In-Reply-To: References: Message-ID: On 25.04.2017 23:59, Robert L. Harris wrote: > > I'm trying to install freeipa-server on an ubuntu 16.04 box, fresh > install, but it keeps failing: > > 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.modified.out'* > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information Works just fine on a chroot, so your setup is not a clean one as that EXAMPLE-COM thing would suggest. The upgrader is only run if ipa is set up. -- t From sbose at redhat.com Wed Apr 26 09:37:20 2017 From: sbose at redhat.com (Sumit Bose) Date: Wed, 26 Apr 2017 11:37:20 +0200 Subject: [Freeipa-users] Fedora 25 - SSSD: Smart card login is broken In-Reply-To: References: Message-ID: <20170426093720.GD3829@p.Speedport_W_724V_Typ_A_05011603_00_011> On Tue, Apr 25, 2017 at 12:38:11PM -0500, Michael Rainey (Contractor) wrote: > Hello, > > While using Fedora 25 we noticed smart card login is broken with the latest > update to SSSD. A month or so ago a patch was created to fix the same > issue. Here are some of the details: > > Before Update: > > sssd.x86_64 1.15.2-1.fc25sb1 (was 1.15.2-1.fc25 before patch) > > After Update: > > sssd.x86_64 1.15.2-2.fc25 > > I was able to compared this to a freshly updated system to a system which > didn't receive the same update so I am confident lies with the package > update. ah, sorry, this is my fault, I forgot to create a Fedora bugzilla ticket, there is one for RHEL but not for Fedora. I just created https://bugzilla.redhat.com/show_bug.cgi?id=1445680 to track this for Fedora. In the meantime please find packages with the latest Fedora version plus the patch at https://koji.fedoraproject.org/koji/taskinfo?taskID=19211021. > > I have also noted the "lock screen when card removed" feature is not > working. Did this change with the update as well? How did you configure the feature? bye, Sumit > > Your help is greatly appreciated. > > Thank you, > > -- > *Michael Rainey* > -- > 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 bret.wortman at damascusgrp.com Wed Apr 26 12:35:36 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 26 Apr 2017 08:35:36 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> Message-ID: <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> Good news. One of my servers _does_ have CA installed. So why does "Action -> New Certificate" not do anything on this or any other server? Bret On 04/25/2017 02:52 PM, Bret Wortman wrote: > > I recently had to upgrade all my Fedora IPA servers to C7. It went > well, and we've been up and running nicely on 4.4.0 on C7 for the past > month or so. > > Today, someone came and asked me to generate a new certificate for > their web server. All was good until I went to the IPA UI and tried to > perform Actions->New Certificate, which did nothing. I tried each of > our 3 servers in turn. All came back with no popup window and no > error, either. > > I suspect the problem might be that we no longer have a CA server due > to the method I used to upgrade the servers. I likely missed a > "--setup-ca" in there somewhere, so my rolling update rolled over the CA. > > What's my best hope of recovery? I never ran this before, so I'm not > sure if this shows that I'm missing a CA or not: > > # ipa ca-find > ------------ > 1 CA matched > ------------ > Name: ipa > Description IPA CA > Authority ID: 3ce3346[...] > Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM > Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM > ---------------------------- > Number of entries returned 1 > ---------------------------- > # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, > O=DAMASCUSGRP.COM" > ipa: ERROR: Failed to authenticate to CA REST API > # klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: admin at DAMASCUSGRP.COM > > Valid starting Expires Service principal > 04/25/2017 18:48:26 04/26/2017 18:48:21 > krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM > # > > > What's my best path of recovery? > > -- > *Bret Wortman* > The Damascus Group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Apr 26 12:41:54 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 26 Apr 2017 08:41:54 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> Message-ID: <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> Using the firefox debugger, I get these errors when trying to pop up the New Certificate dialog: Empty string passed to getElementById(). (5) jquery.js:4:1060 TypeError: u is undefined app.js:1:362059 Empty string passed to getElementById(). (5) jquery.js:4:1060 TypeError: t is undefined app.js:1:217432 I'm definitely not a web kind of guy so I'm not sure if this is helpful or not. This is on 4.4.0, API Version 2.213. Bret On 04/26/2017 08:35 AM, Bret Wortman wrote: > > Good news. One of my servers _does_ have CA installed. So why does > "Action -> New Certificate" not do anything on this or any other server? > > > Bret > > > On 04/25/2017 02:52 PM, Bret Wortman wrote: >> >> I recently had to upgrade all my Fedora IPA servers to C7. It went >> well, and we've been up and running nicely on 4.4.0 on C7 for the >> past month or so. >> >> Today, someone came and asked me to generate a new certificate for >> their web server. All was good until I went to the IPA UI and tried >> to perform Actions->New Certificate, which did nothing. I tried each >> of our 3 servers in turn. All came back with no popup window and no >> error, either. >> >> I suspect the problem might be that we no longer have a CA server due >> to the method I used to upgrade the servers. I likely missed a >> "--setup-ca" in there somewhere, so my rolling update rolled over the CA. >> >> What's my best hope of recovery? I never ran this before, so I'm not >> sure if this shows that I'm missing a CA or not: >> >> # ipa ca-find >> ------------ >> 1 CA matched >> ------------ >> Name: ipa >> Description IPA CA >> Authority ID: 3ce3346[...] >> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >> O=DAMASCUSGRP.COM" >> ipa: ERROR: Failed to authenticate to CA REST API >> # klist >> Ticket cache: KEYRING:persistent:0:0 >> Default principal: admin at DAMASCUSGRP.COM >> >> Valid starting Expires Service principal >> 04/25/2017 18:48:26 04/26/2017 18:48:21 >> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >> # >> >> >> What's my best path of recovery? >> >> -- >> *Bret Wortman* >> The Damascus Group >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Apr 26 13:03:54 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 26 Apr 2017 09:03:54 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> Message-ID: <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> Digging still deeper: # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) Looks like this is an HTTP error; so is it possible that my IPA thinks it has a CA but there's no CMS available? On 04/26/2017 08:41 AM, Bret Wortman wrote: > > Using the firefox debugger, I get these errors when trying to pop up > the New Certificate dialog: > > Empty string passed to getElementById(). (5) > jquery.js:4:1060 > TypeError: u is undefined app.js:1:362059 > Empty string passed to getElementById(). (5) > jquery.js:4:1060 > TypeError: t is undefined app.js:1:217432 > > I'm definitely not a web kind of guy so I'm not sure if this is > helpful or not. This is on 4.4.0, API Version 2.213. > > > Bret > > > On 04/26/2017 08:35 AM, Bret Wortman wrote: >> >> Good news. One of my servers _does_ have CA installed. So why does >> "Action -> New Certificate" not do anything on this or any other server? >> >> >> Bret >> >> >> On 04/25/2017 02:52 PM, Bret Wortman wrote: >>> >>> I recently had to upgrade all my Fedora IPA servers to C7. It went >>> well, and we've been up and running nicely on 4.4.0 on C7 for the >>> past month or so. >>> >>> Today, someone came and asked me to generate a new certificate for >>> their web server. All was good until I went to the IPA UI and tried >>> to perform Actions->New Certificate, which did nothing. I tried each >>> of our 3 servers in turn. All came back with no popup window and no >>> error, either. >>> >>> I suspect the problem might be that we no longer have a CA server >>> due to the method I used to upgrade the servers. I likely missed a >>> "--setup-ca" in there somewhere, so my rolling update rolled over >>> the CA. >>> >>> What's my best hope of recovery? I never ran this before, so I'm not >>> sure if this shows that I'm missing a CA or not: >>> >>> # ipa ca-find >>> ------------ >>> 1 CA matched >>> ------------ >>> Name: ipa >>> Description IPA CA >>> Authority ID: 3ce3346[...] >>> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >>> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >>> O=DAMASCUSGRP.COM" >>> ipa: ERROR: Failed to authenticate to CA REST API >>> # klist >>> Ticket cache: KEYRING:persistent:0:0 >>> Default principal: admin at DAMASCUSGRP.COM >>> >>> Valid starting Expires Service principal >>> 04/25/2017 18:48:26 04/26/2017 18:48:21 >>> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >>> # >>> >>> >>> What's my best path of recovery? >>> >>> -- >>> *Bret Wortman* >>> The Damascus Group >>> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Wed Apr 26 13:08:55 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 26 Apr 2017 15:08:55 +0200 Subject: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s) In-Reply-To: <07a034fb-dc26-8528-cb1b-1b465fc1daee@xtremenitro.org> References: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> <681cdb4a-84d9-5813-bb4d-91519b8057e8@xtremenitro.org> <9fcc4dcb-52e2-83e2-72c3-222f4ac1ab22@redhat.com> <07a034fb-dc26-8528-cb1b-1b465fc1daee@xtremenitro.org> Message-ID: On 04/25/2017 10:56 AM, Dewangga Bachrul Alam wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello! > > Master IPA Server: > - - I install 1 (one) server as master (self-signed) and add/modify > using external CA. > - - I am using ipa-cacert-manage install then ipa-certupdate on master > Hi, I think I got you wrong... Do you mean that you installed IPA with an integrated IdM CA which was self-signed, then your intent was to move to integrated IdM CA externally signed? In this case, the right command would be ipa-cacert-manage renew --external-ca, and the procedure is described in "Changing the certificate chain" [1]. The command ipa-cacert-manage install does not replace the integrated IdM CA but adds the certificate as a known CA. Hope this clarifies, Flo [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-cert-chaining.html > Replica IPA Server: > - - I install 1 (one) server as client and promoted to ipa-replica: > - I run `ipa-client-install` and autodiscovery > - Then `ipa-replica-install --principal admin --admin-password > ` > > I've hit ipa-certupdate -v to verbose the logs (attached at first > email). Then replica server aren't using external CA(s) like master did. > > So, I did the same like master, using `ipa-cacert-manage` on replica, > and it's work fine. If it's normal, then thanks for clarifying this. > > On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote: >> Hi, >> >> As your email refers to self-signed and signed CA certificate, can >> you please clarify the exact steps that you followed? It looks >> like - you first installed FreeIPA with a self-signed CA - you >> added an external CA (did you use ipa-cacert-manage install on 1 >> server then ipa-certupdate on all replicas?) - you replaced the >> httpd/LDAP certificates with a cert signed from the external CA >> (you probably ran ipa-server-certinstall on one server). >> >> In this case it is normal that the httpd/LDAP certificates on the >> replica were not updated as they are different (each IPA server has >> his own httpd/LDAP cert which contains the hostname in its >> subject). You can check this by performing on each server: >> ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert | >> grep Subject: Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM" >> ^^^^^^^^^ >> >> If the goal is to replace the httpd/LDAP certificates on the >> replica, the command ipa-server-certinstall must also be run on the >> replica with the appropriate certificate. >> >> HTH, Flo. >> >> On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello! >> >> Just update, manually add external CA(s) and signed certificated >> was successful, but why it's didn't automatically transferred to >> replica(s) from master. >> >> On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote: >>>>> Hello! >>>>> >>>>> I've successfully create replica, everything works fine but >>>>> why my signed CA certificate didn't automatically transfer to >>>>> another replica(s)? Is it normal? >>>>> >>>>> Trying to add manually, but the certificate in replica(s) >>>>> still using self-signed. Here's the output from >>>>> `ipa-certupdate -v` >>>>> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdI > GYh >> >>>>> > yR >>>>> >>>>> >> LivL9gydE= >>>>> >>>>> Interesting line was : >>>>> >>>>> ipa: DEBUG: stderr= ipa: DEBUG: Starting external process >>>>> ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n >>>>> IPA CA -a ipa: DEBUG: Process finished, return code=255 ipa: >>>>> DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find >>>>> cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found >>>>> >>>>> ipa: DEBUG: Starting external process ipa: DEBUG: >>>>> args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA >>>>> cert -a ipa: DEBUG: Process finished, return code=255 ipa: >>>>> DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find >>>>> cert: External CA cert : PR_FILE_NOT_FOUND_ERROR: File not >>>>> found >>>>> >>>>> FYI: The replica server previously was a client and promoted >>>>> to be a replica by hitting this command: >>>>> `ipa-replica-install --principal admin --admin-password >>>>> admin_password` >>>>> >>>>> Any hints? >>>>> >>> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQI4BAEBCAAiBQJY/w9DGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl > f9IgoCjNcBkZD/wM9ia9854l7bIy7dHxKxc7WhduFmbW3AwW0Ren+aLLER/lqMhO > KPNA+fB9ojeoZagmA7JhpM9jblJ4BUaJjLnyf1vhJmOgIX0MgSfmNCr/f/EtfC9R > wZLBImntbGm8yQnsA4f21sdmqnQg9CZN6cg6R8TQ+OuAXdm8jU9Pv3RCLFXzS0mW > oxQdOZ9yNOC9chmfGl6Bz2oGFoEMHCsn1AcEoRHyIUU6jrCNhTVgYcHPVEz0PW73 > DEY0ZkwNi9hMcGv5+5F8InYEOdOkS9Lp0juW47xRheztD/PRhYYn1m/FtOxmFa3z > 3XS36/w6omSdfH2WOjBRwJduB4REmwHb9oGto7vu6FvWhwUHf9zWVjmJ6DH8tbYU > XgHLmmaSIfwHWc0iYnSLcbHuOaR+l2nOSOLJNg5FfUoIJy5qO51kV3u+pGGELCdr > GexkcXrEHxqk/OO9ioLlTfYIpd9NI6hdLzAsjJEbHuEVZe1B/nrkUOVy/yWOry0N > 8muLkJlslMpRwGV4KRFlhcfd49mv9oylKrAxtZ843vz6F1WOKI6vbuS+SJ+wpoer > P1njVQyExrlKi3ruPBIOkxQ6fab9OvredesCo13wLqhfXvezsWpL1RkiqBaMzrsk > NDX/jqEEsk7gbYuawNazcQZP/NGzQZ6nBnVAkXV7vA8D/EV4y1CbW9YfXA== > =07Ri > -----END PGP SIGNATURE----- > From raje at gworks.mobi Wed Apr 26 13:32:08 2017 From: raje at gworks.mobi (rajkumar) Date: Wed, 26 Apr 2017 19:02:08 +0530 Subject: [Freeipa-users] How to customized freeipa certificate form Message-ID: <52e7335d-0e0b-abcd-256c-8cc962d97de6@gworks.mobi> Hello Freeipa Team, I am new to freeipa, I have installed freeipa for generate certificate for our products, I have generated certificates, its works fine, but I need to customized freeipa certificate form for add more fields. Suggest me how can I achieve this? Reference: please find the attachment of certificate form. I need to add more fields to that form. -- Regards, Rajkumar E raje at gworks.mobi 8675496254. -------------- next part -------------- A non-text attachment was scrubbed... Name: certificate_form.png Type: image/png Size: 43061 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 26 14:22:35 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Apr 2017 10:22:35 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> Message-ID: <0afa51e4-49f3-6ecb-63f0-7b20fe028f8f@redhat.com> Bret Wortman wrote: > Digging still deeper: > > # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > > Looks like this is an HTTP error; so is it possible that my IPA thinks > it has a CA but there's no CMS available? Apache proxies requests to the CA so there could be a mismatch I suppose. I'd ensure that the pki processes are running on the box for starters and then dig into the CA debug log for more details. rob > > > On 04/26/2017 08:41 AM, Bret Wortman wrote: >> >> Using the firefox debugger, I get these errors when trying to pop up >> the New Certificate dialog: >> >> Empty string passed to getElementById(). (5) >> jquery.js:4:1060 >> TypeError: u is undefined >> app.js:1:362059 >> Empty string passed to getElementById(). (5) >> jquery.js:4:1060 >> TypeError: t is undefined >> app.js:1:217432 >> >> I'm definitely not a web kind of guy so I'm not sure if this is >> helpful or not. This is on 4.4.0, API Version 2.213. >> >> >> Bret >> >> >> On 04/26/2017 08:35 AM, Bret Wortman wrote: >>> >>> Good news. One of my servers _does_ have CA installed. So why does >>> "Action -> New Certificate" not do anything on this or any other server? >>> >>> >>> Bret >>> >>> >>> On 04/25/2017 02:52 PM, Bret Wortman wrote: >>>> >>>> I recently had to upgrade all my Fedora IPA servers to C7. It went >>>> well, and we've been up and running nicely on 4.4.0 on C7 for the >>>> past month or so. >>>> >>>> Today, someone came and asked me to generate a new certificate for >>>> their web server. All was good until I went to the IPA UI and tried >>>> to perform Actions->New Certificate, which did nothing. I tried each >>>> of our 3 servers in turn. All came back with no popup window and no >>>> error, either. >>>> >>>> I suspect the problem might be that we no longer have a CA server >>>> due to the method I used to upgrade the servers. I likely missed a >>>> "--setup-ca" in there somewhere, so my rolling update rolled over >>>> the CA. >>>> >>>> What's my best hope of recovery? I never ran this before, so I'm not >>>> sure if this shows that I'm missing a CA or not: >>>> >>>> # ipa ca-find >>>> ------------ >>>> 1 CA matched >>>> ------------ >>>> Name: ipa >>>> Description IPA CA >>>> Authority ID: 3ce3346[...] >>>> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >>>> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >>>> O=DAMASCUSGRP.COM" >>>> ipa: ERROR: Failed to authenticate to CA REST API >>>> # klist >>>> Ticket cache: KEYRING:persistent:0:0 >>>> Default principal: admin at DAMASCUSGRP.COM >>>> >>>> Valid starting Expires Service principal >>>> 04/25/2017 18:48:26 04/26/2017 18:48:21 >>>> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >>>> # >>>> >>>> >>>> What's my best path of recovery? >>>> >>>> -- >>>> *Bret Wortman* >>>> The Damascus Group >>>> >>> >>> >>> >> >> >> > > > From bret.wortman at damascusgrp.com Wed Apr 26 14:33:43 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 26 Apr 2017 10:33:43 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> Message-ID: <81f171a5-3bea-ed43-94a0-c20f53b756f0@damascusgrp.com> So I can see my certs using cert-find, but can't get details using cert-show or add new ones using cert-request. # ipa cert-find : ------------------------------ Number of entries returned 385 ------------------------------ # ipa cert-show 895 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # ipa cert-show 1 (which does not exist) ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # ipa cert-status 895 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # Is this an IPV6 thing? Because ipactl shows everything green and certmonger is running. Bret On 04/26/2017 09:03 AM, Bret Wortman wrote: > > Digging still deeper: > > # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > > Looks like this is an HTTP error; so is it possible that my IPA thinks > it has a CA but there's no CMS available? > > > On 04/26/2017 08:41 AM, Bret Wortman wrote: >> >> Using the firefox debugger, I get these errors when trying to pop up >> the New Certificate dialog: >> >> Empty string passed to getElementById(). (5) >> jquery.js:4:1060 >> TypeError: u is undefined app.js:1:362059 >> Empty string passed to getElementById(). (5) >> jquery.js:4:1060 >> TypeError: t is undefined app.js:1:217432 >> >> I'm definitely not a web kind of guy so I'm not sure if this is >> helpful or not. This is on 4.4.0, API Version 2.213. >> >> >> Bret >> >> >> On 04/26/2017 08:35 AM, Bret Wortman wrote: >>> >>> Good news. One of my servers _does_ have CA installed. So why does >>> "Action -> New Certificate" not do anything on this or any other server? >>> >>> >>> Bret >>> >>> >>> On 04/25/2017 02:52 PM, Bret Wortman wrote: >>>> >>>> I recently had to upgrade all my Fedora IPA servers to C7. It went >>>> well, and we've been up and running nicely on 4.4.0 on C7 for the >>>> past month or so. >>>> >>>> Today, someone came and asked me to generate a new certificate for >>>> their web server. All was good until I went to the IPA UI and tried >>>> to perform Actions->New Certificate, which did nothing. I tried >>>> each of our 3 servers in turn. All came back with no popup window >>>> and no error, either. >>>> >>>> I suspect the problem might be that we no longer have a CA server >>>> due to the method I used to upgrade the servers. I likely missed a >>>> "--setup-ca" in there somewhere, so my rolling update rolled over >>>> the CA. >>>> >>>> What's my best hope of recovery? I never ran this before, so I'm >>>> not sure if this shows that I'm missing a CA or not: >>>> >>>> # ipa ca-find >>>> ------------ >>>> 1 CA matched >>>> ------------ >>>> Name: ipa >>>> Description IPA CA >>>> Authority ID: 3ce3346[...] >>>> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >>>> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >>>> O=DAMASCUSGRP.COM" >>>> ipa: ERROR: Failed to authenticate to CA REST API >>>> # klist >>>> Ticket cache: KEYRING:persistent:0:0 >>>> Default principal: admin at DAMASCUSGRP.COM >>>> >>>> Valid starting Expires Service principal >>>> 04/25/2017 18:48:26 04/26/2017 18:48:21 >>>> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >>>> # >>>> >>>> >>>> What's my best path of recovery? >>>> >>>> -- >>>> *Bret Wortman* >>>> The Damascus Group >>>> >>> >>> >>> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Apr 26 14:45:37 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 26 Apr 2017 10:45:37 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <0afa51e4-49f3-6ecb-63f0-7b20fe028f8f@redhat.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> <0afa51e4-49f3-6ecb-63f0-7b20fe028f8f@redhat.com> Message-ID: <38f9ffd8-c68b-31b7-524f-1ce2bdf6b44f@damascusgrp.com> On 04/26/2017 10:22 AM, Rob Crittenden wrote: > Bret Wortman wrote: >> Digging still deeper: >> >> # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> >> Looks like this is an HTTP error; so is it possible that my IPA thinks >> it has a CA but there's no CMS available? > Apache proxies requests to the CA so there could be a mismatch I > suppose. I'd ensure that the pki processes are running on the box for > starters and then dig into the CA debug log for more details. Is that /var/log/pki/pki-tomcat/ca/debug? If so, then nothing happens in it during the above operations. As you noted, apache produces the following when trying to show a valid cert even though there's nothing in what I think is the pki ca debug log. ps aux shows pki processes alive, at least, and in ownership of the 8009 port (verified by lsof). [Wed Apr 26 14:38:48.157961 2017] [:error] [pid 15801] ipa: INFO: [jsonserver_session] admin at DAMASCUSGRP.COM: ping(): SUCCESS [Wed Apr 26 14:38:48.247040 2017] [proxy:error] [pid 15804] (111)Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed [Wed Apr 26 14:38:48.247072 2017] [proxy:error] [pid 15804] AH00959: ap_proxy_connect_)backend disabling worker for (localhost) for 60s [Wed Apr 26 14:38:48.247078 2017] [proxy_ajp:error] [pid 15804] [client 192.168.208.54:56618] AH00896: failed to make connection to backend: localhost [Wed Apr 26 14:38:48.247531 2017] [:error] [pid 15800] ipa: ERROR: ra.get_certificate(): Unable to communicate with CMS (503) [Wed Apr 26 14:38:48.247765 2017] [:error] [pid 15800] ipa: INFO: [jsonserver_session] admin at DAMASCUSGRP.COM: cert_show/1(u'895', version=u'2.213'): CertificateOperationError > > rob >> >> On 04/26/2017 08:41 AM, Bret Wortman wrote: >>> Using the firefox debugger, I get these errors when trying to pop up >>> the New Certificate dialog: >>> >>> Empty string passed to getElementById(). (5) >>> jquery.js:4:1060 >>> TypeError: u is undefined >>> app.js:1:362059 >>> Empty string passed to getElementById(). (5) >>> jquery.js:4:1060 >>> TypeError: t is undefined >>> app.js:1:217432 >>> >>> I'm definitely not a web kind of guy so I'm not sure if this is >>> helpful or not. This is on 4.4.0, API Version 2.213. >>> >>> >>> Bret >>> >>> >>> On 04/26/2017 08:35 AM, Bret Wortman wrote: >>>> Good news. One of my servers _does_ have CA installed. So why does >>>> "Action -> New Certificate" not do anything on this or any other server? >>>> >>>> >>>> Bret >>>> >>>> >>>> On 04/25/2017 02:52 PM, Bret Wortman wrote: >>>>> I recently had to upgrade all my Fedora IPA servers to C7. It went >>>>> well, and we've been up and running nicely on 4.4.0 on C7 for the >>>>> past month or so. >>>>> >>>>> Today, someone came and asked me to generate a new certificate for >>>>> their web server. All was good until I went to the IPA UI and tried >>>>> to perform Actions->New Certificate, which did nothing. I tried each >>>>> of our 3 servers in turn. All came back with no popup window and no >>>>> error, either. >>>>> >>>>> I suspect the problem might be that we no longer have a CA server >>>>> due to the method I used to upgrade the servers. I likely missed a >>>>> "--setup-ca" in there somewhere, so my rolling update rolled over >>>>> the CA. >>>>> >>>>> What's my best hope of recovery? I never ran this before, so I'm not >>>>> sure if this shows that I'm missing a CA or not: >>>>> >>>>> # ipa ca-find >>>>> ------------ >>>>> 1 CA matched >>>>> ------------ >>>>> Name: ipa >>>>> Description IPA CA >>>>> Authority ID: 3ce3346[...] >>>>> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >>>>> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >>>>> O=DAMASCUSGRP.COM" >>>>> ipa: ERROR: Failed to authenticate to CA REST API >>>>> # klist >>>>> Ticket cache: KEYRING:persistent:0:0 >>>>> Default principal: admin at DAMASCUSGRP.COM >>>>> >>>>> Valid starting Expires Service principal >>>>> 04/25/2017 18:48:26 04/26/2017 18:48:21 >>>>> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >>>>> # >>>>> >>>>> >>>>> What's my best path of recovery? >>>>> >>>>> -- >>>>> *Bret Wortman* >>>>> The Damascus Group >>>>> >>>> >>>> >>> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Wed Apr 26 14:51:34 2017 From: uncommonkat at gmail.com (Kat) Date: Wed, 26 Apr 2017 09:51:34 -0500 Subject: [Freeipa-users] Signed cert/CA and updating certs? Message-ID: <8b9eb899-2f67-0a24-8605-705e4ba31a1e@gmail.com> Hi again, Well, Let's Encrypt is working nicely with the httpd cert - but I am wondering if there is a way to use Let's Encrypt or another signed cert to replace the CA to be able to sign all the certs with it, or is the only way to sign our certs with the built in CA? I guess, thinking about it more, if I am signing certs based on LE's Cert, that might be a bad thing from their standpoint... Just thinking out loud and looking for some input. Kat From arequipeno at gmail.com Wed Apr 26 14:58:11 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Wed, 26 Apr 2017 09:58:11 -0500 Subject: [Freeipa-users] Apache group authentication stopped working Message-ID: <4bf9fa17-0903-20ee-9e90-444826ff5612@gmail.com> Apologies if this is a duplicate. Not sure if posting via Gmane works these days ... Did something change re Apache LDAP group authentication. The following configuration directive was working for me until recently. Require ldap-group cn=sprinklers,cn=groups,cn=accounts,dc=penurio,dc=us Today, this is causing authentication failures, even though the users are still in the "sprinklers" user group. "Require valid-user" still works, so it definitely seems to be something to do with the group. -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From kmontgomery at cbuscollaboratory.com Wed Apr 26 15:33:40 2017 From: kmontgomery at cbuscollaboratory.com (Kendal Montgomery) Date: Wed, 26 Apr 2017 15:33:40 +0000 Subject: [Freeipa-users] IPA PKI Questions Message-ID: <78422B04-3FCA-4C1C-883C-A9D08AD62849@cbuscollaboratory.com> Hi all, I?ve been struggling the last few days with rebuilding part of my FreeIPA infrastructure, which has lead me to some questions about how some of the IPA infrastructure works. To give a bit of background, I have two IPA servers (my initially installed IPA server, and a replica) both of which have DNS, NTP, and CA roles. I?m running CentOS 7.3, FreeIPA 4.4 currently (upgraded from original CentOS 7 installations which I believe was FreeIPA 4.1? initiall). I have several remote sites that each have two IPA server replicas that have replication topology segments for domain and ca suffixes back to the two on-prem IPA servers. This has been working quite well for over a year now, through the upgrades, etc. Occasionally I get an issue with getting some conflicting records in LDAP, which I?ve cleared up by following some of the documentation out there. It seems when this happens however, I end up getting into a situation where replication stops working, and I end up needing to ?refresh? the installations. I have done this once so far, and am in the process again currently, by deleting each remote IPA server (ipa server-del), then re-installing each server to get a clean copy of the databases for everything. Last time I had no issues doing this. This time around, I?m running into some issues with the CA setup. I seem to be able to run ipa-replica-install just fine without the --setup-ca option. I may be running into some issues identified in an earlier post this week, so I?ll ask about this issue separately if I continue to have problems. In working through these issues, I realized I don?t really know enough about how the interaction between the IPA clients and IPA server is working, with regard to the PKI infrastructure. I have some questions on what server roles I need at each site and how the PKI infrastructure works within the IPA environment, and how the clients communicate to it: 1) How do the IPA clients discover servers with the CA role and use them? 2) Is all this interaction done through APIs on the IPA server ? in other words, are these requests fielded by the IPA server and proxied somehow to known servers with the CA role? 3) Do the clients need ?direct? access to a server with the CA role to request and obtain certificates and renewals? (i.e. do I need each IPA server to have the CA role)? 4) Is it sufficient to just have one server with CA role at each site? Or even just one at the main on-prem site? Kendal Montgomery DevOps Engineer / Lab Manager [cid:image001.png at 01D2BE80.F3B914D0] Empowering collective insights -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10201 bytes Desc: image001.png URL: From arequipeno at gmail.com Wed Apr 26 14:37:14 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Wed, 26 Apr 2017 09:37:14 -0500 Subject: [Freeipa-users] Apache group authentication stopped working Message-ID: Did something change re Apache LDAP group authentication. The following configuration directive was working for me until recently. Require ldap-group cn=sprinklers,cn=groups,cn=accounts,dc=penurio,dc=us Today, this is causing authentication failures, even though the users are still in the "sprinklers" user group. "Require valid-user" still works, so it definitely seems to be something to do with the group. -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From robert.l.harris at gmail.com Wed Apr 26 18:07:57 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Wed, 26 Apr 2017 18:07:57 +0000 Subject: [Freeipa-users] "Purge" scripts? Message-ID: So twice now I've tried installing freeipa on an Ubuntu 16.04 system. Both times I've gotten an error and followed the instructions to "fix it" and they didn't work so I removed files ( with purge ), cleaned up everything I could find related to freeipa, sssd and kerb but trying to run it again gives either a different error or the same error with a different process output indicating it's not 100% clean. Is there a known list of paths, packages or files to make sure are un-installed or wiped out to make the system 100% clean? Preferably for Ubuntu. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From cherdt at umn.edu Wed Apr 26 19:01:48 2017 From: cherdt at umn.edu (Chris Herdt) Date: Wed, 26 Apr 2017 14:01:48 -0500 Subject: [Freeipa-users] creating an LDAP bind user Message-ID: I am setting up LDAP authentication with a remote service. On https://www.freeipa.org/page/HowTo/LDAP it says the following: "Do not use the Directory Manager account to authenticate remote services to the IPA LDAP server. Use a system account, created like this:" I followed the steps there to create an entry under sysaccounts, and confirmed it is there using ldapsearch: ldapsearch -D 'cn=Directory Manager' -W -H ldap://ipa01.example.com -x uid=remoteu # remoteu, sysaccounts, etc, example.com dn: uid=remoteu,cn=sysaccounts,cn=etc,dc=example,dc=com objectClass: account objectClass: simplesecurityobject objectClass: top uid: remoteu userPassword:: [hash value] This new user is unable to run LDAP searches though: ldapsearch -D 'cn=remoteu' -W -H ldap://ipa01.example.com -x uid=remoteu Enter LDAP Password: ldap_bind: Invalid credentials (49) The new user is also unable to authenticate the remote service. (The Directory Manager user is able to authenticate the remote service, although as pointed out above, that's not a good idea.) The How-To LDAP page also notes: "IPA 4.0 is going to change the default stance on data from nearly everything is readable to nothing is readable, by default. You will eventually need to add some Access Control Instructions (ACI's) to grant read access to the parts of the LDAP tree you will need." I'm not sure if that's part of the issue or not. I'm using IPA version 4.4.0. Thanks in advance for any suggestions. From andrew.krause at breakthroughfuel.com Wed Apr 26 20:06:12 2017 From: andrew.krause at breakthroughfuel.com (Andrew Krause) Date: Wed, 26 Apr 2017 20:06:12 +0000 Subject: [Freeipa-users] Freeipa web UI: An error has occurred (IPA Error 4302: CertificateFormatError) In-Reply-To: <82d4fa2d-73af-b4ec-21ea-f1a931daf624@redhat.com> References: <82d4fa2d-73af-b4ec-21ea-f1a931daf624@redhat.com> Message-ID: <69D84CD5-3A3F-4418-B8A5-28B45105747A@breakthroughfuel.com> I had to let this sit for a few days, but now that I try again I can remove and re-add the host (using CLI). The web UI still presents an error though IPA Error 4302: CertificateFormatError Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old unsupported format. This is an error I ran into when working with renewing certs while referring to the wrong path for the certificate database (path changed with versions and I was unaware). Why this is happening in the web UI though still eludes me. The test host I removed via CLI and then added with the ipa-client-install command still does not show ?Enrolled? status when I do a search for it in the UI, and the error above is displayed when this host shows up in results, or when I click on the link to the host page. Is it possible that Apache is misconfigured? I?m including my dirsrv and apache access log excerpts from when I try to load the host page. I do see some errors. Apache: [Wed Apr 26 14:37:15.047280 2017] [:error] [pid 7300] Bad remote server certificate: -8179 [Wed Apr 26 14:37:15.047303 2017] [:error] [pid 7300] SSL Library Error: -8179 Certificate is signed by an unknown issuer [Wed Apr 26 14:37:15.047364 2017] [:error] [pid 7300] Re-negotiation handshake failed: Not accepted by client!? [Wed Apr 26 14:37:15.047698 2017] [:error] [pid 7295] ipa: INFO: [xmlserver] host/clienthost.domain2.com at DOMAIN.COM: cert_request(u'MIIEJDCCAwwCAQAwUzErMCkGA1UEChMiQlJFQUtUSFJPVUdIVEVDSE5PTE9HWVNFUlZJQ0VTLkNPTTEkMCIGA1UEAxMbYmx1cGh4cGFwcDAxLmJsdWUtc2hpZnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6cADpaacHWc+aYKkftzRqvhu08fTA0F3z3h5OZGBE7KJYctlA8mnIAB3fxRIr+oh1lVJVV0loQ4rjJrpbB4cyynUiH2Cj+qx6NkLBODpQDkLUV8Cw2CXSREDHqAmghIruCYOKOluwG5EdplYhuDm5ErO/bH0KKgWY/IDA5CCmADUNCWNiJT5CzVLj9aK/IZQp0kKznLCjeSGu7Hndr8PJdKbwsev1p7L3Uld2wAg4BydBTNxew0m9bz6GrT4L8aBofbYcZJF+bm4yrxM4bCvwu+8H37KQlNkpcd8hKASks55yk6UTcttBUA/26TrSM2MmR23JkqGtv2KBANLgiIO9wIDAQABoIIBijB5BgkqhkiG9w0BCRQxbB5qAEkAUABBACAATQBhAGMAaABpAG4AZQAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAC0AIABiAGwAdQBwAGgAeABwAGEAcABwADAAMQAuAGIAbAB1AGUALQBzAGgAaQBmAHQALgBjAG8AbTCCAQsGCSqGSIb3DQEJDjGB/TCB+jCBxwYDVR0RAQEABIG8MIG5oFMGCisGAQQBgjcUAgOgRQxDaG9zdC9ibHVwaHhwYXBwMDEuYmx1ZS1zaGlmdC5jb21AQlJFQUtUSFJPVUdIVEVDSE5PTE9HWVNFUlZJQ0VTLkNPTaBiBgYrBgEFAgKgWDBWoCQbIkJSRUFLVEhST1VHSFRFQ0hOT0xPR1lTRVJWSUNFUy5DT02hLjAsoAMCAQGhJTAjGwRob3N0GxtibHVwaHhwYXBwMDEuYmx1ZS1zaGlmdC5jb20wDAYDVR0TAQH/BAIwADAgBgNVHQ4BAQAEFgQU8kkbDSyFKalBBieiA0ItRXdIo+8wDQYJKoZIhvcNAQELBQADggEBAJFAdz17m0Ptomeg3m9Gct29HK3uwxdYYDfUbHOJlZuH66renQNcYKyG+qZJxB3FS3wRuEoMw//HbFEtV9sud3ttejalPOz/eplFn2Cq3QHdG3OF1qmagy3Io8dHm38B9S5bSf3tGg7YWGP/uOIEoRAySvP9BLgIYbisGhM6tSP/JAkTX1d7IMCHXyjiWB/ZqpFURojsarQeD+gdyI0XCQ82GnEOBJdzV/uc3/+1mDSStln5CKX1nxbOgS1s198dcsL73BEmxFjjwWbEr1GXvsF48S8csoqN8QqfyCsHpubbXpeFXjby8oHaE8HevYdThfMyPBqtCUjkbsR1JeUdqCc=', principal=u'host/clienthost.domain2.com at DOMAIN.COM', add=True, version=u'2.51'): NetworkError [Wed Apr 26 14:37:15.047856 2017] [:error] [pid 7300] Bad remote server certificate: -8179 [Wed Apr 26 14:37:15.047864 2017] [:error] [pid 7300] SSL Library Error: -8179 Certificate is signed by an unknown issuer [Wed Apr 26 14:37:15.047869 2017] [:error] [pid 7300] SSL Library Error: -8179 Certificate is signed by an unknown issuer [Wed Apr 26 14:37:15.048309 2017] [:error] [pid 7300] Bad remote server certificate: -8179 [Wed Apr 26 14:37:15.048317 2017] [:error] [pid 7300] SSL Library Error: -8179 Certificate is signed by an unknown issuer [Wed Apr 26 14:37:15.235599 2017] [:warn] [pid 9708] NSSProtocol: Unknown protocol 'tlsv1.2' not supported [Wed Apr 26 14:37:15.235637 2017] [:error] [pid 9708] Unknown cipher aes_128_sha_256 [Wed Apr 26 14:37:15.235641 2017] [:error] [pid 9708] Unknown cipher aes_256_sha_256 [Wed Apr 26 14:37:15.235644 2017] [:error] [pid 9708] Unknown cipher ecdhe_ecdsa_aes_128_gcm_sha_256 [Wed Apr 26 14:37:15.235648 2017] [:error] [pid 9708] Unknown cipher ecdhe_ecdsa_aes_256_gcm_sha_384 [Wed Apr 26 14:37:15.235652 2017] [:error] [pid 9708] Unknown cipher ecdhe_rsa_aes_128_gcm_sha_256 [Wed Apr 26 14:37:15.235655 2017] [:error] [pid 9708] Unknown cipher ecdhe_rsa_aes_256_gcm_sha_384 [Wed Apr 26 14:37:15.235658 2017] [:error] [pid 9708] Unknown cipher rsa_aes_128_gcm_sha_256 [Wed Apr 26 14:37:15.235662 2017] [:error] [pid 9708] Unknown cipher rsa_aes_256_gcm_sha_384 Dirsrv: [26/Apr/2017:14:51:54.142433251 -0500] conn=17 op=5296 SRCH base="ou=sessions,ou=Security Domain,o=ipaca" scope=2 filter="(objectClass=securityDomainSessionEntry)" attrs="cn" [26/Apr/2017:14:51:54.142776551 -0500] conn=17 op=5296 RESULT err=32 tag=101 nentries=0 etime=0 [26/Apr/2017:14:51:55.018498792 -0500] conn=8 op=8117 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="description" [26/Apr/2017:14:51:55.018666292 -0500] conn=8 op=8117 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:00.146796240 -0500] conn=8 op=8119 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 filter="(certStatus=INVALID)" attrs="objectClass serialno notBefore notAfter duration extension subjectName issuerName userCertificate version algorithmId signingAlgorithmId publicKeyData" [26/Apr/2017:14:52:00.147035479 -0500] conn=8 op=8119 SORT notBefore [26/Apr/2017:14:52:00.147051543 -0500] conn=8 op=8119 VLV 200:0:20170426145200Z 1:0 (0) [26/Apr/2017:14:52:00.147092417 -0500] conn=8 op=8119 RESULT err=0 tag=101 nentries=0 etime=0 [26/Apr/2017:14:52:00.147826090 -0500] conn=8 op=8120 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 filter="(certStatus=VALID)" attrs="objectClass serialno notBefore notAfter duration extension subjectName issuerName userCertificate version algorithmId signingAlgorithmId publicKeyData" [26/Apr/2017:14:52:00.147982635 -0500] conn=8 op=8120 SORT notAfter [26/Apr/2017:14:52:00.147991868 -0500] conn=8 op=8120 VLV 200:0:20170426145200Z 1:35 (0) [26/Apr/2017:14:52:00.148105485 -0500] conn=8 op=8120 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:00.148933905 -0500] conn=8 op=8121 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 filter="(certStatus=REVOKED)" attrs="objectClass revokedOn serialno revInfo notAfter notBefore duration extension subjectName issuerName userCertificate version algorithmId signingAlgorithmId publicKeyData" [26/Apr/2017:14:52:00.149043409 -0500] conn=8 op=8121 SORT notAfter [26/Apr/2017:14:52:00.149052772 -0500] conn=8 op=8121 VLV 200:0:20170426145200Z 1:4 (0) [26/Apr/2017:14:52:00.149160758 -0500] conn=8 op=8121 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:29.001182676 -0500] conn=19057 op=17 UNBIND [26/Apr/2017:14:52:29.001203771 -0500] conn=19057 op=17 fd=122 closed - U1 [26/Apr/2017:14:52:43.956006475 -0500] conn=19059 fd=122 slot=122 connection from 10.11.10.6 to 10.11.10.3 [26/Apr/2017:14:52:43.956364716 -0500] conn=19059 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domaincontrollerfunctionality defaultnamingcontext lastusn highestcommittedusn aci" [26/Apr/2017:14:52:43.957812723 -0500] conn=19059 op=0 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.961326411 -0500] conn=4 op=33437 SRCH base="dc=domain,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/clienthost.domain2.com at DOMAIN.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/clienthost.domain2.com at DOMAIN.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [26/Apr/2017:14:52:43.961883409 -0500] conn=4 op=33437 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.961970819 -0500] conn=4 op=33438 SRCH base="cn=ipaConfig,cn=etc,dc=domain,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaConfigString ipaKrbAuthzData ipaUserAuthType" [26/Apr/2017:14:52:43.962039666 -0500] conn=4 op=33438 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.962141970 -0500] conn=4 op=33439 SRCH base="cn=DOMAIN.COM,cn=kerberos,dc=domain,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [26/Apr/2017:14:52:43.962369262 -0500] conn=4 op=33439 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.962455322 -0500] conn=4 op=33440 SRCH base="dc=domain,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/DOMAIN.COM at DOMAIN.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/DOMAIN.COM at DOMAIN.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [26/Apr/2017:14:52:43.962718874 -0500] conn=4 op=33440 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.962817682 -0500] conn=4 op=33441 SRCH base="cn=Default Host Password Policy,cn=computers,cn=accounts,dc=domain,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [26/Apr/2017:14:52:43.962896540 -0500] conn=4 op=33441 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.963503712 -0500] conn=4 op=33442 SRCH base="dc=domain,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/clienthost.domain2.com at DOMAIN.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/clienthost.domain2.com at DOMAIN.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [26/Apr/2017:14:52:43.963752103 -0500] conn=4 op=33442 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.963849295 -0500] conn=4 op=33443 SRCH base="cn=DOMAIN.COM,cn=kerberos,dc=domain,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [26/Apr/2017:14:52:43.963953657 -0500] conn=4 op=33443 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.964039852 -0500] conn=4 op=33444 SRCH base="dc=domain,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/DOMAIN.COM at DOMAIN.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/DOMAIN.COM at DOMAIN.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [26/Apr/2017:14:52:43.964273302 -0500] conn=4 op=33444 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.964362345 -0500] conn=4 op=33445 SRCH base="cn=Default Host Password Policy,cn=computers,cn=accounts,dc=domain,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [26/Apr/2017:14:52:43.964435619 -0500] conn=4 op=33445 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.964567590 -0500] conn=4 op=33446 SRCH base="fqdn=clienthost.domain2.com,cn=computers,cn=accounts,dc=domain,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory ipaNTHomeDirectoryDrive" [26/Apr/2017:14:52:43.964851835 -0500] conn=4 op=33446 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.964901338 -0500] conn=4 op=33447 SRCH base="cn=clienthost.domain2.com,cn=masters,cn=ipa,cn=etc,dc=domain,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [26/Apr/2017:14:52:43.964982222 -0500] conn=4 op=33447 RESULT err=32 tag=101 nentries=0 etime=0 [26/Apr/2017:14:52:43.965190437 -0500] conn=4 op=33448 MOD dn="fqdn=clienthost.domain2.com,cn=computers,cn=accounts,dc=domain,dc=com" [26/Apr/2017:14:52:43.971416149 -0500] conn=4 op=33448 RESULT err=0 tag=103 nentries=0 etime=0 csn=5900fab3000000040000 [26/Apr/2017:14:52:43.972903894 -0500] conn=4 op=33449 SRCH base="dc=domain,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/DOMAIN.COM at DOMAIN.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/DOMAIN.COM at DOMAIN.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [26/Apr/2017:14:52:43.973145956 -0500] conn=4 op=33449 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.973372685 -0500] conn=4 op=33450 SRCH base="dc=domain,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ipahost.domain.com at DOMAIN.COM)(krbPrincipalName:caseIgnoreIA5Match:=ldap/ipahost.domain.com at DOMAIN.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [26/Apr/2017:14:52:43.973601674 -0500] conn=4 op=33450 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.973695925 -0500] conn=4 op=33451 SRCH base="cn=DOMAIN.COM,cn=kerberos,dc=domain,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [26/Apr/2017:14:52:43.973792556 -0500] conn=4 op=33451 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.973887813 -0500] conn=4 op=33452 SRCH base="dc=domain,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=host/clienthost.domain2.com at DOMAIN.COM))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [26/Apr/2017:14:52:43.974122262 -0500] conn=4 op=33452 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.974232772 -0500] conn=4 op=33453 SRCH base="cn=DOMAIN.COM,cn=kerberos,dc=domain,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [26/Apr/2017:14:52:43.974326465 -0500] conn=4 op=33453 RESULT err=0 tag=101 nentries=1 etime=0 [26/Apr/2017:14:52:43.974905377 -0500] conn=19059 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [26/Apr/2017:14:52:43.980786355 -0500] conn=19059 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [26/Apr/2017:14:52:43.981170143 -0500] conn=19059 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [26/Apr/2017:14:52:43.982397706 -0500] conn=19059 op=2 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [26/Apr/2017:14:52:43.982529305 -0500] conn=19059 op=3 BIND dn="" method=sasl version=3 mech=GSSAPI [26/Apr/2017:14:52:43.983192932 -0500] conn=19059 op=3 RESULT err=0 tag=97 nentries=0 etime=0 dn="fqdn=clienthost.domain2.com,cn=computers,cn=accounts,dc=domain,dc=com" [26/Apr/2017:14:52:43.983449296 -0500] conn=19059 op=4 SRCH base="cn=accounts,dc=domain,dc=com" scope=2 filter="(&(objectClass=ipaHost)(fqdn=clienthost.domain2.com))" attrs="objectClass cn fqdn serverHostName memberOf ipaSshPubKey ipaUniqueID" [26/Apr/2017:14:52:43.984109232 -0500] conn=19059 op=4 RESULT err=0 tag=101 nentries=1 etime=0 notes=P pr_idx=0 pr_cookie=-1 [26/Apr/2017:14:52:43.984622970 -0500] conn=19059 op=5 SRCH base="fqdn=clienthost.domain2.com,cn=computers,cn=accounts,dc=domain,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass cn memberOf ipaUniqueID" [26/Apr/2017:14:52:43.984955433 -0500] conn=19059 op=5 RESULT err=0 tag=101 nentries=1 etime=0 notes=P pr_idx=0 pr_cookie=-1 [26/Apr/2017:14:52:43.985234170 -0500] conn=19059 op=6 SRCH base="cn=sudo,dc=domain,dc=com" scope=2 filter="(&(objectClass=ipasudocmdgrp)(entryusn>=20038636))" attrs="objectClass ipaUniqueID cn member entryusn" [26/Apr/2017:14:52:43.986861159 -0500] conn=19059 op=6 RESULT err=0 tag=101 nentries=0 etime=0 notes=P pr_idx=0 pr_cookie=-1 [26/Apr/2017:14:52:43.987119181 -0500] conn=19059 op=7 SRCH base="cn=sudo,dc=domain,dc=com" scope=2 filter="(&(objectClass=ipasudorule)(ipaEnabledFlag=TRUE)(|(!(memberHost=*))(hostCategory=ALL)(memberHost=fqdn=clienthost.domain2.com,cn=computers,cn=accounts,dc=domain,dc=com))(entryusn>=20038636))" attrs="objectClass cn ipaUniqueID ipaEnabledFlag ipaSudoOpt ipaSudoRunAs ipaSudoRunAsGroup memberAllowCmd memberDenyCmd memberHost memberUser sudoNotAfter sudoNotBefore sudoOrder cmdCategory hostCategory userCategory ipaSudoRunAsUserCategory ipaSudoRunAsGroupCategory ipaSudoRunAsExtUser ipaSudoRunAsExtGroup ipaSudoRunAsExtUserGroup entryusn" [26/Apr/2017:14:52:43.987828298 -0500] conn=19059 op=7 RESULT err=0 tag=101 nentries=0 etime=0 notes=P pr_idx=0 pr_cookie=-1 [26/Apr/2017:14:56:53.754308324 -0500] conn=8 op=8122 MOD dn="cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca" [26/Apr/2017:14:56:53.758231493 -0500] conn=8 op=8122 RESULT err=0 tag=103 nentries=0 etime=0 [26/Apr/2017:14:56:54.141384397 -0500] conn=17 op=5298 SRCH base="ou=sessions,ou=Security Domain,o=ipaca" scope=2 filter="(objectClass=securityDomainSessionEntry)" attrs="cn" [26/Apr/2017:14:56:54.141558862 -0500] conn=17 op=5298 RESULT err=32 tag=101 nentries=0 etime=0 > On Apr 20, 2017, at 1:03 PM, Rob Crittenden wrote: > > Andrew Krause wrote: >> Sorry for the self bump but no one has any insight on this? >> >> >>> On Apr 17, 2017, at 11:31 AM, Andrew Krause wrote: >>> >>> Many hosts in our web ui show a null status for ?enrolled?. When you do a search that includes any of these host objects the web UI posts errors, and if you click on one of the problem hosts the same error stops anything from loading on the host page. >>> >>> I?ve been trying to solve this problem on my own for quite some time and have not been successful. It?s impossible to remove the host through the web UI and using CLI commands seem to remove the entry from IPA (host is not found with ipa host-find), but it is still visible in the UI. One thing that may be common with all of these hosts is that they were enrolled with our IPA system back while we were running version 3.0 and likely have had issues for quite some time. Multiple updates have happened since then, and all of our hosts added within the last year are working fine. I suspect there?s an issue with a path somewhere for a certificate database, but I?m unable to pinpoint what is going wrong. > > It should not be possible to have different views in the UI and the CLI > since they make the same backend calls. What you'd want to do, hopefully > on a semi-quiet system, is to do a host-find on the CLI and then list > all hosts in the UI and compare the logs in /var/log/httpd/error_log and > look at the LDAP queries in /var/log/dirsrv/slapd-REALM/access (this is > a buffered log so be patient). > > They should be doing more or less the exact same set of queries. > > Very doubtful that this has anything to do with certs. Anything on the > client would be completely separate from what is on the server. > > One thing you may be seeing though is that in 3.0 clients a host > certificate was obtained for it. This was dropped with 4.0, but it > wouldn't affect any visibility on the server. > > rob > From jason at tresgeek.net Wed Apr 26 21:11:03 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Wed, 26 Apr 2017 16:11:03 -0500 (CDT) Subject: [Freeipa-users] creating an LDAP bind user In-Reply-To: References: Message-ID: <51169291.2627.1493241063545.JavaMail.zimbra@tresgeek.net> Hi Chris, > # remoteu, sysaccounts, etc, example.com > dn: uid=remoteu,cn=sysaccounts,cn=etc,dc=example,dc=com > objectClass: account > objectClass: simplesecurityobject > objectClass: top > uid: remoteu > userPassword:: [hash value] > > This new user is unable to run LDAP searches though: > ldapsearch -D 'cn=remoteu' -W -H ldap://ipa01.example.com -x uid=remoteu > Enter LDAP Password: > ldap_bind: Invalid credentials (49) Your DN (-D) is incorrect in your ldapsearch call. It needs to match the part after the "dn:" string you provided in your query of the user above (uid=remoteu,cn=sysaccounts,cn=etc,dc=example,dc=com). In some cases you can shorten the DN but only if your suffix/basedn is set correctly for the client making the call. Regards, j From cherdt at umn.edu Wed Apr 26 21:37:20 2017 From: cherdt at umn.edu (Chris Herdt) Date: Wed, 26 Apr 2017 16:37:20 -0500 Subject: [Freeipa-users] creating an LDAP bind user In-Reply-To: <51169291.2627.1493241063545.JavaMail.zimbra@tresgeek.net> References: <51169291.2627.1493241063545.JavaMail.zimbra@tresgeek.net> Message-ID: Thanks Jason, that was exactly the issue! It's working now. On Wed, Apr 26, 2017 at 4:11 PM, Jason B. Nance wrote: > Hi Chris, > >> # remoteu, sysaccounts, etc, example.com >> dn: uid=remoteu,cn=sysaccounts,cn=etc,dc=example,dc=com >> objectClass: account >> objectClass: simplesecurityobject >> objectClass: top >> uid: remoteu >> userPassword:: [hash value] >> >> This new user is unable to run LDAP searches though: >> ldapsearch -D 'cn=remoteu' -W -H ldap://ipa01.example.com -x uid=remoteu >> Enter LDAP Password: >> ldap_bind: Invalid credentials (49) > > Your DN (-D) is incorrect in your ldapsearch call. It needs to match the part after the "dn:" string you provided in your query of the user above (uid=remoteu,cn=sysaccounts,cn=etc,dc=example,dc=com). > > In some cases you can shorten the DN but only if your suffix/basedn is set correctly for the client making the call. > > Regards, > > j -- Chris Herdt UIS Systems Administrator cherdt at umn.edu 612-301-2232 (office) 734-754-3585 (mobile) From rcritten at redhat.com Wed Apr 26 21:58:01 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Apr 2017 17:58:01 -0400 Subject: [Freeipa-users] IPA PKI Questions In-Reply-To: <78422B04-3FCA-4C1C-883C-A9D08AD62849@cbuscollaboratory.com> References: <78422B04-3FCA-4C1C-883C-A9D08AD62849@cbuscollaboratory.com> Message-ID: <1c10249c-e6f8-9680-e328-cf61521b54aa@redhat.com> Kendal Montgomery wrote: > Hi all, > > > > I?ve been struggling the last few days with rebuilding part of my > FreeIPA infrastructure, which has lead me to some questions about how > some of the IPA infrastructure works. To give a bit of background, I > have two IPA servers (my initially installed IPA server, and a replica) > both of which have DNS, NTP, and CA roles. I?m running CentOS 7.3, > FreeIPA 4.4 currently (upgraded from original CentOS 7 installations > which I believe was FreeIPA 4.1? initiall). I have several remote sites > that each have two IPA server replicas that have replication topology > segments for domain and ca suffixes back to the two on-prem IPA > servers. This has been working quite well for over a year now, through > the upgrades, etc. Occasionally I get an issue with getting some > conflicting records in LDAP, which I?ve cleared up by following some of > the documentation out there. It seems when this happens however, I end > up getting into a situation where replication stops working, and I end > up needing to ?refresh? the installations. I have done this once so far, > and am in the process again currently, by deleting each remote IPA > server (ipa server-del), then re-installing each server to get a clean > copy of the databases for everything. Last time I had no issues doing > this. This time around, I?m running into some issues with the CA > setup. I seem to be able to run ipa-replica-install just fine without > the --setup-ca option. I may be running into some issues identified in > an earlier post this week, so I?ll ask about this issue separately if I > continue to have problems. In working through these issues, I realized > I don?t really know enough about how the interaction between the IPA > clients and IPA server is working, with regard to the PKI > infrastructure. I have some questions on what server roles I need at > each site and how the PKI infrastructure works within the IPA > environment, and how the clients communicate to it: > You don't need to uninstall a master in order to fix replication issues. You can re-initialize it from a working master. I'm pretty sure that if you re-init one you need to re-init them all though, to be safe. I cc'd a couple of 389-ds devs to clarify. > > 1) How do the IPA clients discover servers with the CA role and > use them? They don't, they talk to one of the IPA masters and lets that figure it out. An IPA master does this by looking at cn=, cn=masters,cn=ipa,cn=etc,$SUFFIX > 2) Is all this interaction done through APIs on the IPA server ? > in other words, are these requests fielded by the IPA server and proxied > somehow to known servers with the CA role? Right. > 3) Do the clients need ?direct? access to a server with the CA > role to request and obtain certificates and renewals? (i.e. do I need > each IPA server to have the CA role)? Nope. > 4) Is it sufficient to just have one server with CA role at each > site? Or even just one at the main on-prem site? One per site may be sufficient, you want to ensure that you have > 1 CAs and since you have separate sites, having one at each would give you lots of leeway in case of catastrophe. rob From rcritten at redhat.com Wed Apr 26 22:02:06 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Apr 2017 18:02:06 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <81f171a5-3bea-ed43-94a0-c20f53b756f0@damascusgrp.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> <81f171a5-3bea-ed43-94a0-c20f53b756f0@damascusgrp.com> Message-ID: <28c6acf8-a76f-6676-729e-8608b2cc1249@redhat.com> Bret Wortman wrote: > So I can see my certs using cert-find, but can't get details using > cert-show or add new ones using cert-request. > > # ipa cert-find > : > ------------------------------ > Number of entries returned 385 > ------------------------------ > # ipa cert-show 895 > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > # ipa cert-show 1 (which does not exist) > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > # ipa cert-status 895 > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > # > > Is this an IPV6 thing? Because ipactl shows everything green and > certmonger is running. Doubtful. cert-find and cert-show use different APIs in dogtag. cert-find uses the newer RESTful API and cert-show uses the older XML-based API (and is authenticated). I'm guessing that is where the issue lies. What I'd recommend doing is noting the time, restarting the CA, and then plow through the debug log looking for failures. It could be that the CA is only partially up (and I'd check your CA subsystem certs as well). rob > > Bret > > > On 04/26/2017 09:03 AM, Bret Wortman wrote: >> >> Digging still deeper: >> >> # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> >> Looks like this is an HTTP error; so is it possible that my IPA thinks >> it has a CA but there's no CMS available? >> >> >> On 04/26/2017 08:41 AM, Bret Wortman wrote: >>> >>> Using the firefox debugger, I get these errors when trying to pop up >>> the New Certificate dialog: >>> >>> Empty string passed to getElementById(). (5) >>> jquery.js:4:1060 >>> TypeError: u is undefined >>> app.js:1:362059 >>> Empty string passed to getElementById(). (5) >>> jquery.js:4:1060 >>> TypeError: t is undefined >>> app.js:1:217432 >>> >>> I'm definitely not a web kind of guy so I'm not sure if this is >>> helpful or not. This is on 4.4.0, API Version 2.213. >>> >>> >>> Bret >>> >>> >>> On 04/26/2017 08:35 AM, Bret Wortman wrote: >>>> >>>> Good news. One of my servers _does_ have CA installed. So why does >>>> "Action -> New Certificate" not do anything on this or any other server? >>>> >>>> >>>> Bret >>>> >>>> >>>> On 04/25/2017 02:52 PM, Bret Wortman wrote: >>>>> >>>>> I recently had to upgrade all my Fedora IPA servers to C7. It went >>>>> well, and we've been up and running nicely on 4.4.0 on C7 for the >>>>> past month or so. >>>>> >>>>> Today, someone came and asked me to generate a new certificate for >>>>> their web server. All was good until I went to the IPA UI and tried >>>>> to perform Actions->New Certificate, which did nothing. I tried >>>>> each of our 3 servers in turn. All came back with no popup window >>>>> and no error, either. >>>>> >>>>> I suspect the problem might be that we no longer have a CA server >>>>> due to the method I used to upgrade the servers. I likely missed a >>>>> "--setup-ca" in there somewhere, so my rolling update rolled over >>>>> the CA. >>>>> >>>>> What's my best hope of recovery? I never ran this before, so I'm >>>>> not sure if this shows that I'm missing a CA or not: >>>>> >>>>> # ipa ca-find >>>>> ------------ >>>>> 1 CA matched >>>>> ------------ >>>>> Name: ipa >>>>> Description IPA CA >>>>> Authority ID: 3ce3346[...] >>>>> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >>>>> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >>>>> O=DAMASCUSGRP.COM" >>>>> ipa: ERROR: Failed to authenticate to CA REST API >>>>> # klist >>>>> Ticket cache: KEYRING:persistent:0:0 >>>>> Default principal: admin at DAMASCUSGRP.COM >>>>> >>>>> Valid starting Expires Service principal >>>>> 04/25/2017 18:48:26 04/26/2017 18:48:21 >>>>> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >>>>> # >>>>> >>>>> >>>>> What's my best path of recovery? >>>>> >>>>> -- >>>>> *Bret Wortman* >>>>> The Damascus Group >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From chris at node-nine.com Thu Apr 27 00:13:10 2017 From: chris at node-nine.com (Chris Moody) Date: Wed, 26 Apr 2017 17:13:10 -0700 Subject: [Freeipa-users] Help needed - CA Server role not adding Message-ID: Hello. First wanted to thank everyone working hard to bring this awesome bundle of applications to market. This is a great project and I really appreciate the efforts. I need a hand with a new 4.4.3 install that I'm still trying to flesh out fully to support all the services I need. I recently attempted to add the 'CA Server' Role to a node in a replica pair. I ran the 'ipa-ca-install' command on the node in question but in the middle of the operation, it unfortunately bombed out due to memory exhaustion. I have since doubled the RAM in the host, but I can no longer get this system to proceed with the multitude of steps it performs to enable this role. When I type 'ipa server-role-find' it lists the 'CA Server' Role as absent, but whenever I issue the command 'ipa-ca-install' to try and re-instantiate the process of adding the role, it spits back out 'CA is already installed on this host.'. I'm not seeing a 'remove role' or 'force' option via any of the tab-completed command options now available in 4.x nor is the man page of much help. Online documentation as well seems to be in a state of flux between the older 3.x docs and the new 4.x functionality. Any help is appreciated. Thanks, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2424 bytes Desc: S/MIME Cryptographic Signature URL: From ftweedal at redhat.com Thu Apr 27 02:39:59 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 27 Apr 2017 12:39:59 +1000 Subject: [Freeipa-users] Signed cert/CA and updating certs? In-Reply-To: <8b9eb899-2f67-0a24-8605-705e4ba31a1e@gmail.com> References: <8b9eb899-2f67-0a24-8605-705e4ba31a1e@gmail.com> Message-ID: <20170427023959.GH21957@dhcp-40-8.bne.redhat.com> On Wed, Apr 26, 2017 at 09:51:34AM -0500, Kat wrote: > Hi again, > > Well, Let's Encrypt is working nicely with the httpd cert - but I am > wondering if there is a way to use Let's Encrypt or another signed cert to > replace the CA to be able to sign all the certs with it, or is the only way > to sign our certs with the built in CA? I guess, thinking about it more, if > I am signing certs based on LE's Cert, that might be a bad thing from their > standpoint... > > Just thinking out loud and looking for some input. > > Kat > LE issues TLS server certificates and uses the ACME protocol for automated domain validation and certificate issuance. For IPA, there is no way (in general) that we can satisfy the DV challenges, and LE issues certs in a single profile for a narrow use case. So the general answer is: LE is not a suitable CA "backend" for IPA cert issuance. That said, there is some scope for acquisition of certs from LE for IPA-enrolled TLS servers. We can manage it if IPA's DNS is publicly exposed. But we have not implemented this and it is not a priority. HTH. Let me know if you have further questions. Cheers, Fraser From ftweedal at redhat.com Thu Apr 27 02:43:05 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 27 Apr 2017 12:43:05 +1000 Subject: [Freeipa-users] How to customized freeipa certificate form In-Reply-To: <52e7335d-0e0b-abcd-256c-8cc962d97de6@gworks.mobi> References: <52e7335d-0e0b-abcd-256c-8cc962d97de6@gworks.mobi> Message-ID: <20170427024305.GI21957@dhcp-40-8.bne.redhat.com> On Wed, Apr 26, 2017 at 07:02:08PM +0530, rajkumar wrote: > Hello Freeipa Team, > > I am new to freeipa, I have installed freeipa for generate certificate for > our products, I have generated certificates, its works fine, but I need to > customized freeipa certificate form for add more fields. Suggest me how can > I achieve this? > > Reference: please find the attachment of certificate form. I need to add > more fields to that form. > What is your use case? I suspect (but please clarify) that it does not really matter to you what fields we display in the UI, but rather, what is actually in the certificate. Could you please clarify: 1. What you actually need put into the certificate(s) 2. What you want displayed when viewing a cert in the Web UI, that is not currently displayed. Thanks, Fraser From ftweedal at redhat.com Thu Apr 27 06:19:56 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 27 Apr 2017 16:19:56 +1000 Subject: [Freeipa-users] How to customized freeipa certificate form In-Reply-To: <0588d79d-13e7-ff8d-616e-d221b7e1ca9f@gworks.mobi> References: <52e7335d-0e0b-abcd-256c-8cc962d97de6@gworks.mobi> <20170427024305.GI21957@dhcp-40-8.bne.redhat.com> <0588d79d-13e7-ff8d-616e-d221b7e1ca9f@gworks.mobi> Message-ID: <20170427061956.GN21957@dhcp-40-8.bne.redhat.com> On Thu, Apr 27, 2017 at 10:16:15AM +0530, rajkumar wrote: > Hello Fraser, > > Thanks for your quick reply, I need to add hash value field in certificate > details form and write a code to get hash value of create certificated and > viewed to that hash value field. Suggest me How can I do this. and also > suggest latest source of freeipa. > The UI will only show information from within the certificate itself, or immutable metadata about it. Do you mean that you want to see a digest of the certificate? If not, could you be more clear about exactly what data you need to see, and how it is derived from the certificate? If you want to set your own data into the cert when issuing it, could you be more clear about what data exactly, and how you want it to appear in the certificate? Thanks, Fraser > > > On 04/27/2017 08:13 AM, Fraser Tweedale wrote: > > On Wed, Apr 26, 2017 at 07:02:08PM +0530, rajkumar wrote: > > > Hello Freeipa Team, > > > > > > I am new to freeipa, I have installed freeipa for generate certificate for > > > our products, I have generated certificates, its works fine, but I need to > > > customized freeipa certificate form for add more fields. Suggest me how can > > > I achieve this? > > > > > > Reference: please find the attachment of certificate form. I need to add > > > more fields to that form. > > > > > What is your use case? > > > > I suspect (but please clarify) that it does not really matter to you > > what fields we display in the UI, but rather, what is actually in > > the certificate. Could you please clarify: > > > > 1. What you actually need put into the certificate(s) > > > > 2. What you want displayed when viewing a cert in the Web UI, that > > is not currently displayed. > > > > Thanks, > > Fraser > > -- > Regards, > Rajkumar E > raje at gworks.mobi > 8675496254. > From ftweedal at redhat.com Thu Apr 27 06:47:16 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 27 Apr 2017 16:47:16 +1000 Subject: [Freeipa-users] How to customized freeipa certificate form In-Reply-To: <4aedeffc-fe6f-619f-30f2-336609459f9c@gworks.mobi> References: <52e7335d-0e0b-abcd-256c-8cc962d97de6@gworks.mobi> <20170427024305.GI21957@dhcp-40-8.bne.redhat.com> <0588d79d-13e7-ff8d-616e-d221b7e1ca9f@gworks.mobi> <20170427061956.GN21957@dhcp-40-8.bne.redhat.com> <4aedeffc-fe6f-619f-30f2-336609459f9c@gworks.mobi> Message-ID: <20170427064716.GO21957@dhcp-40-8.bne.redhat.com> On Thu, Apr 27, 2017 at 12:02:56PM +0530, rajkumar wrote: > Hello Fraser, > > Ok, I got similar fields, MD5 Fingerprint and Sha1 Fingerprint value in > certificate form in freeipa, But it values are disabled in certificate form > in webui. suggest me how can I enable these values via webui or any other > way. > > *Reference: * https://pagure.io/freeipa/issue/6903 > > Thanks, > Ah, I think I understand now. You just need the existing fields to be populated properly? Yes, it appears to be a bug that these are not filled out. Thank you for reporting the issue in the bug tracker. Could you please indicate what version of FreeIPA you are using? Cheers, Fraser > > On 04/27/2017 11:49 AM, Fraser Tweedale wrote: > > On Thu, Apr 27, 2017 at 10:16:15AM +0530, rajkumar wrote: > > > Hello Fraser, > > > > > > Thanks for your quick reply, I need to add hash value field in certificate > > > details form and write a code to get hash value of create certificated and > > > viewed to that hash value field. Suggest me How can I do this. and also > > > suggest latest source of freeipa. > > > > > The UI will only show information from within the certificate > > itself, or immutable metadata about it. Do you mean that you want > > to see a digest of the certificate? If not, could you be more clear > > about exactly what data you need to see, and how it is derived from > > the certificate? > > > > If you want to set your own data into the cert when issuing it, > > could you be more clear about what data exactly, and how you want it > > to appear in the certificate? > > > > Thanks, > > Fraser > > > > > > > > On 04/27/2017 08:13 AM, Fraser Tweedale wrote: > > > > On Wed, Apr 26, 2017 at 07:02:08PM +0530, rajkumar wrote: > > > > > Hello Freeipa Team, > > > > > > > > > > I am new to freeipa, I have installed freeipa for generate certificate for > > > > > our products, I have generated certificates, its works fine, but I need to > > > > > customized freeipa certificate form for add more fields. Suggest me how can > > > > > I achieve this? > > > > > > > > > > Reference: please find the attachment of certificate form. I need to add > > > > > more fields to that form. > > > > > > > > > What is your use case? > > > > > > > > I suspect (but please clarify) that it does not really matter to you > > > > what fields we display in the UI, but rather, what is actually in > > > > the certificate. Could you please clarify: > > > > > > > > 1. What you actually need put into the certificate(s) > > > > > > > > 2. What you want displayed when viewing a cert in the Web UI, that > > > > is not currently displayed. > > > > > > > > Thanks, > > > > Fraser > > > -- > > > Regards, > > > Rajkumar E > > > raje at gworks.mobi > > > 8675496254. > > > > > -- > Regards, > Rajkumar E > raje at gworks.mobi > 8675496254. > From flo at redhat.com Thu Apr 27 07:42:31 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 27 Apr 2017 09:42:31 +0200 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: <81f171a5-3bea-ed43-94a0-c20f53b756f0@damascusgrp.com> References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> <81f171a5-3bea-ed43-94a0-c20f53b756f0@damascusgrp.com> Message-ID: On 04/26/2017 04:33 PM, Bret Wortman wrote: > So I can see my certs using cert-find, but can't get details using > cert-show or add new ones using cert-request. > > # ipa cert-find > : > ------------------------------ > Number of entries returned 385 > ------------------------------ > # ipa cert-show 895 > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > # ipa cert-show 1 (which does not exist) > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > # ipa cert-status 895 > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > # > > Is this an IPV6 thing? Because ipactl shows everything green and > certmonger is running. > Hi Bret, the issue looks similar to https://pagure.io/freeipa/issue/6575 and https://pagure.io/dogtagpki/issue/2570 which were IPv6 related. Note that IPv6 must be enabled on the machine but IPA does not require an IPv6 address to be configured (except for the loopback). You can check the following: - is PKI listening to port 8009 on IPv6 or IPv4 interface? sudo netstat -tunpl | grep 8009 tcp6 0 0 127.0.0.1:8009 :::* LISTEN 10749/java - /etc/pki/pki-tomcat/server.xml defines a redirection from port 8009 to 8443, and the "address" part is important: In the above example, it will be using localhost which can resolve either to IPv4 or IPv6. - /etc/hosts must define the loopback addresses with 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 HTH, Flo. > Bret > > > On 04/26/2017 09:03 AM, Bret Wortman wrote: >> >> Digging still deeper: >> >> # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> >> Looks like this is an HTTP error; so is it possible that my IPA thinks >> it has a CA but there's no CMS available? >> >> >> On 04/26/2017 08:41 AM, Bret Wortman wrote: >>> >>> Using the firefox debugger, I get these errors when trying to pop up >>> the New Certificate dialog: >>> >>> Empty string passed to getElementById(). (5) >>> jquery.js:4:1060 >>> TypeError: u is undefined >>> app.js:1:362059 >>> Empty string passed to getElementById(). (5) >>> jquery.js:4:1060 >>> TypeError: t is undefined >>> app.js:1:217432 >>> >>> I'm definitely not a web kind of guy so I'm not sure if this is >>> helpful or not. This is on 4.4.0, API Version 2.213. >>> >>> >>> Bret >>> >>> >>> On 04/26/2017 08:35 AM, Bret Wortman wrote: >>>> >>>> Good news. One of my servers _does_ have CA installed. So why does >>>> "Action -> New Certificate" not do anything on this or any other server? >>>> >>>> >>>> Bret >>>> >>>> >>>> On 04/25/2017 02:52 PM, Bret Wortman wrote: >>>>> >>>>> I recently had to upgrade all my Fedora IPA servers to C7. It went >>>>> well, and we've been up and running nicely on 4.4.0 on C7 for the >>>>> past month or so. >>>>> >>>>> Today, someone came and asked me to generate a new certificate for >>>>> their web server. All was good until I went to the IPA UI and tried >>>>> to perform Actions->New Certificate, which did nothing. I tried >>>>> each of our 3 servers in turn. All came back with no popup window >>>>> and no error, either. >>>>> >>>>> I suspect the problem might be that we no longer have a CA server >>>>> due to the method I used to upgrade the servers. I likely missed a >>>>> "--setup-ca" in there somewhere, so my rolling update rolled over >>>>> the CA. >>>>> >>>>> What's my best hope of recovery? I never ran this before, so I'm >>>>> not sure if this shows that I'm missing a CA or not: >>>>> >>>>> # ipa ca-find >>>>> ------------ >>>>> 1 CA matched >>>>> ------------ >>>>> Name: ipa >>>>> Description IPA CA >>>>> Authority ID: 3ce3346[...] >>>>> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >>>>> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >>>>> O=DAMASCUSGRP.COM" >>>>> ipa: ERROR: Failed to authenticate to CA REST API >>>>> # klist >>>>> Ticket cache: KEYRING:persistent:0:0 >>>>> Default principal: admin at DAMASCUSGRP.COM >>>>> >>>>> Valid starting Expires Service principal >>>>> 04/25/2017 18:48:26 04/26/2017 18:48:21 >>>>> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >>>>> # >>>>> >>>>> >>>>> What's my best path of recovery? >>>>> >>>>> -- >>>>> *Bret Wortman* >>>>> The Damascus Group >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From tbordaz at redhat.com Thu Apr 27 09:58:33 2017 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 27 Apr 2017 11:58:33 +0200 Subject: [Freeipa-users] IPA PKI Questions In-Reply-To: <1c10249c-e6f8-9680-e328-cf61521b54aa@redhat.com> References: <78422B04-3FCA-4C1C-883C-A9D08AD62849@cbuscollaboratory.com> <1c10249c-e6f8-9680-e328-cf61521b54aa@redhat.com> Message-ID: <5901C0C9.2010507@redhat.com> On 04/26/2017 11:58 PM, Rob Crittenden wrote: > Kendal Montgomery wrote: >> Hi all, >> >> >> >> I?ve been struggling the last few days with rebuilding part of my >> FreeIPA infrastructure, which has lead me to some questions about how >> some of the IPA infrastructure works. To give a bit of background, I >> have two IPA servers (my initially installed IPA server, and a replica) >> both of which have DNS, NTP, and CA roles. I?m running CentOS 7.3, >> FreeIPA 4.4 currently (upgraded from original CentOS 7 installations >> which I believe was FreeIPA 4.1? initiall). I have several remote sites >> that each have two IPA server replicas that have replication topology >> segments for domain and ca suffixes back to the two on-prem IPA >> servers. This has been working quite well for over a year now, through >> the upgrades, etc. Occasionally I get an issue with getting some >> conflicting records in LDAP, which I?ve cleared up by following some of >> the documentation out there. It seems when this happens however, I end >> up getting into a situation where replication stops working, and I end >> up needing to ?refresh? the installations. I have done this once so far, >> and am in the process again currently, by deleting each remote IPA >> server (ipa server-del), then re-installing each server to get a clean >> copy of the databases for everything. Last time I had no issues doing >> this. This time around, I?m running into some issues with the CA >> setup. I seem to be able to run ipa-replica-install just fine without >> the --setup-ca option. I may be running into some issues identified in >> an earlier post this week, so I?ll ask about this issue separately if I >> continue to have problems. In working through these issues, I realized >> I don?t really know enough about how the interaction between the IPA >> clients and IPA server is working, with regard to the PKI >> infrastructure. I have some questions on what server roles I need at >> each site and how the PKI infrastructure works within the IPA >> environment, and how the clients communicate to it: >> > You don't need to uninstall a master in order to fix replication issues. > You can re-initialize it from a working master. I'm pretty sure that if > you re-init one you need to re-init them all though, to be safe. I cc'd > a couple of 389-ds devs to clarify. Hi Kendal, Regarding re-initialization it is a safety practice to re-init all of them when you need to re-init one. It is sometime not necessary to re-init all servers but checking if it is necessary or not take usually more time that a full reinit. A concern of full reinit is if you have large database (so reinit take longer) or difficulty to find a calm period to do this this task. Reading your description I understand that you had to cleanup some conflicting entries (ldapsearch -D 'cn=directory manager' -W -b "" "(objectclass=nsds5ReplConflict)" dn). The management of those entries will greatly improve but it is a complex task, with many corner cases. The better is to avoid creation of those entries. A recommendation to avoid those entries is, avoid parallel upgrade of IPA servers and do not disconnect IPA servers when doing those upgrade. regards > >> 1) How do the IPA clients discover servers with the CA role and >> use them? > They don't, they talk to one of the IPA masters and lets that figure it out. > > An IPA master does this by looking at cn=, > cn=masters,cn=ipa,cn=etc,$SUFFIX > >> 2) Is all this interaction done through APIs on the IPA server ? >> in other words, are these requests fielded by the IPA server and proxied >> somehow to known servers with the CA role? > Right. > >> 3) Do the clients need ?direct? access to a server with the CA >> role to request and obtain certificates and renewals? (i.e. do I need >> each IPA server to have the CA role)? > Nope. > >> 4) Is it sufficient to just have one server with CA role at each >> site? Or even just one at the main on-prem site? > One per site may be sufficient, you want to ensure that you have > 1 CAs > and since you have separate sites, having one at each would give you > lots of leeway in case of catastrophe. > > rob From kmontgomery at cbuscollaboratory.com Thu Apr 27 13:31:30 2017 From: kmontgomery at cbuscollaboratory.com (Kendal Montgomery) Date: Thu, 27 Apr 2017 13:31:30 +0000 Subject: [Freeipa-users] IPA PKI Questions In-Reply-To: <1c10249c-e6f8-9680-e328-cf61521b54aa@redhat.com> References: <78422B04-3FCA-4C1C-883C-A9D08AD62849@cbuscollaboratory.com> <1c10249c-e6f8-9680-e328-cf61521b54aa@redhat.com> Message-ID: <84734FAB-45A9-4E03-A315-D605C5780C72@cbuscollaboratory.com> Excellent, thanks for the information regarding re-initialization. I had tried this before, but I still ended up having issues in the logs where it says something along the lines of a CSN is no longer available, may need to do a full re-initializaion after I did that. It seems to only happen on some of the servers, but I wanted to make sure everything is clean at the remote sites. I will give this a try again instead of removing and re-adding all of them. Thanks for clearing up those details regarding the servers with CA roles and client interactions, and how to place the CA role servers. That?s very helpful! I think it would be great if that were added to the documentation. Thanks all! Kendal On 4/26/17, 5:58 PM, "Rob Crittenden" wrote: Kendal Montgomery wrote: > Hi all, > > > > I?ve been struggling the last few days with rebuilding part of my > FreeIPA infrastructure, which has lead me to some questions about how > some of the IPA infrastructure works. To give a bit of background, I > have two IPA servers (my initially installed IPA server, and a replica) > both of which have DNS, NTP, and CA roles. I?m running CentOS 7.3, > FreeIPA 4.4 currently (upgraded from original CentOS 7 installations > which I believe was FreeIPA 4.1? initiall). I have several remote sites > that each have two IPA server replicas that have replication topology > segments for domain and ca suffixes back to the two on-prem IPA > servers. This has been working quite well for over a year now, through > the upgrades, etc. Occasionally I get an issue with getting some > conflicting records in LDAP, which I?ve cleared up by following some of > the documentation out there. It seems when this happens however, I end > up getting into a situation where replication stops working, and I end > up needing to ?refresh? the installations. I have done this once so far, > and am in the process again currently, by deleting each remote IPA > server (ipa server-del), then re-installing each server to get a clean > copy of the databases for everything. Last time I had no issues doing > this. This time around, I?m running into some issues with the CA > setup. I seem to be able to run ipa-replica-install just fine without > the --setup-ca option. I may be running into some issues identified in > an earlier post this week, so I?ll ask about this issue separately if I > continue to have problems. In working through these issues, I realized > I don?t really know enough about how the interaction between the IPA > clients and IPA server is working, with regard to the PKI > infrastructure. I have some questions on what server roles I need at > each site and how the PKI infrastructure works within the IPA > environment, and how the clients communicate to it: > You don't need to uninstall a master in order to fix replication issues. You can re-initialize it from a working master. I'm pretty sure that if you re-init one you need to re-init them all though, to be safe. I cc'd a couple of 389-ds devs to clarify. > > 1) How do the IPA clients discover servers with the CA role and > use them? They don't, they talk to one of the IPA masters and lets that figure it out. An IPA master does this by looking at cn=, cn=masters,cn=ipa,cn=etc,$SUFFIX > 2) Is all this interaction done through APIs on the IPA server ? > in other words, are these requests fielded by the IPA server and proxied > somehow to known servers with the CA role? Right. > 3) Do the clients need ?direct? access to a server with the CA > role to request and obtain certificates and renewals? (i.e. do I need > each IPA server to have the CA role)? Nope. > 4) Is it sufficient to just have one server with CA role at each > site? Or even just one at the main on-prem site? One per site may be sufficient, you want to ensure that you have > 1 CAs and since you have separate sites, having one at each would give you lots of leeway in case of catastrophe. rob From kmontgomery at cbuscollaboratory.com Thu Apr 27 13:33:03 2017 From: kmontgomery at cbuscollaboratory.com (Kendal Montgomery) Date: Thu, 27 Apr 2017 13:33:03 +0000 Subject: [Freeipa-users] IPA PKI Questions In-Reply-To: <5901C0C9.2010507@redhat.com> References: <78422B04-3FCA-4C1C-883C-A9D08AD62849@cbuscollaboratory.com> <1c10249c-e6f8-9680-e328-cf61521b54aa@redhat.com> <5901C0C9.2010507@redhat.com> Message-ID: Thank you! I?ll give the re-initialization of all my replicas a try! Kendal On 4/27/17, 5:58 AM, "thierry bordaz" wrote: On 04/26/2017 11:58 PM, Rob Crittenden wrote: > Kendal Montgomery wrote: >> Hi all, >> >> >> >> I?ve been struggling the last few days with rebuilding part of my >> FreeIPA infrastructure, which has lead me to some questions about how >> some of the IPA infrastructure works. To give a bit of background, I >> have two IPA servers (my initially installed IPA server, and a replica) >> both of which have DNS, NTP, and CA roles. I?m running CentOS 7.3, >> FreeIPA 4.4 currently (upgraded from original CentOS 7 installations >> which I believe was FreeIPA 4.1? initiall). I have several remote sites >> that each have two IPA server replicas that have replication topology >> segments for domain and ca suffixes back to the two on-prem IPA >> servers. This has been working quite well for over a year now, through >> the upgrades, etc. Occasionally I get an issue with getting some >> conflicting records in LDAP, which I?ve cleared up by following some of >> the documentation out there. It seems when this happens however, I end >> up getting into a situation where replication stops working, and I end >> up needing to ?refresh? the installations. I have done this once so far, >> and am in the process again currently, by deleting each remote IPA >> server (ipa server-del), then re-installing each server to get a clean >> copy of the databases for everything. Last time I had no issues doing >> this. This time around, I?m running into some issues with the CA >> setup. I seem to be able to run ipa-replica-install just fine without >> the --setup-ca option. I may be running into some issues identified in >> an earlier post this week, so I?ll ask about this issue separately if I >> continue to have problems. In working through these issues, I realized >> I don?t really know enough about how the interaction between the IPA >> clients and IPA server is working, with regard to the PKI >> infrastructure. I have some questions on what server roles I need at >> each site and how the PKI infrastructure works within the IPA >> environment, and how the clients communicate to it: >> > You don't need to uninstall a master in order to fix replication issues. > You can re-initialize it from a working master. I'm pretty sure that if > you re-init one you need to re-init them all though, to be safe. I cc'd > a couple of 389-ds devs to clarify. Hi Kendal, Regarding re-initialization it is a safety practice to re-init all of them when you need to re-init one. It is sometime not necessary to re-init all servers but checking if it is necessary or not take usually more time that a full reinit. A concern of full reinit is if you have large database (so reinit take longer) or difficulty to find a calm period to do this this task. Reading your description I understand that you had to cleanup some conflicting entries (ldapsearch -D 'cn=directory manager' -W -b "" "(objectclass=nsds5ReplConflict)" dn). The management of those entries will greatly improve but it is a complex task, with many corner cases. The better is to avoid creation of those entries. A recommendation to avoid those entries is, avoid parallel upgrade of IPA servers and do not disconnect IPA servers when doing those upgrade. regards > >> 1) How do the IPA clients discover servers with the CA role and >> use them? > They don't, they talk to one of the IPA masters and lets that figure it out. > > An IPA master does this by looking at cn=, > cn=masters,cn=ipa,cn=etc,$SUFFIX > >> 2) Is all this interaction done through APIs on the IPA server ? >> in other words, are these requests fielded by the IPA server and proxied >> somehow to known servers with the CA role? > Right. > >> 3) Do the clients need ?direct? access to a server with the CA >> role to request and obtain certificates and renewals? (i.e. do I need >> each IPA server to have the CA role)? > Nope. > >> 4) Is it sufficient to just have one server with CA role at each >> site? Or even just one at the main on-prem site? > One per site may be sufficient, you want to ensure that you have > 1 CAs > and since you have separate sites, having one at each would give you > lots of leeway in case of catastrophe. > > rob From mbasti at redhat.com Thu Apr 27 15:00:56 2017 From: mbasti at redhat.com (=?UTF-8?Q?Martin_Ba=c5=a1ti?=) Date: Thu, 27 Apr 2017 17:00:56 +0200 Subject: [Freeipa-users] "Purge" scripts? In-Reply-To: References: Message-ID: On 26.04.2017 20:07, Robert L. Harris wrote: > So twice now I've tried installing freeipa on an Ubuntu 16.04 > system. Both times I've gotten an error and followed the instructions > to "fix it" and they didn't work so I removed files ( with purge ), > cleaned up everything I could find related to freeipa, sssd and kerb > but trying to run it again gives either a different error or the same > error with a different process output indicating it's not 100% clean. > > Is there a known list of paths, packages or files to make sure are > un-installed or wiped out to make the system 100% clean? Preferably > for Ubuntu. > > Robert > > > Hello, could you be more specific about the errors? Martin -- Martin Ba?ti Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.l.harris at gmail.com Thu Apr 27 15:03:09 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Thu, 27 Apr 2017 15:03:09 +0000 Subject: [Freeipa-users] "Purge" scripts? In-Reply-To: References: Message-ID: It changes each time it seems. In a minute I'm going to do a completely virgin install under a "script" session for Ubuntu 16.04 and 17.04 with and with the PPAs then upload the scripts to pastebin so they can be looked at. Robert On Thu, Apr 27, 2017 at 9:01 AM Martin Ba?ti wrote: > > > On 26.04.2017 20:07, Robert L. Harris wrote: > > So twice now I've tried installing freeipa on an Ubuntu 16.04 system. > Both times I've gotten an error and followed the instructions to "fix it" > and they didn't work so I removed files ( with purge ), cleaned up > everything I could find related to freeipa, sssd and kerb but trying to run > it again gives either a different error or the same error with a different > process output indicating it's not 100% clean. > > Is there a known list of paths, packages or files to make sure are > un-installed or wiped out to make the system 100% clean? Preferably for > Ubuntu. > > Robert > > > > > Hello, could you be more specific about the errors? > > > Martin > > -- > Martin Ba?ti > Software Engineer > Red Hat Czech > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 27 15:06:37 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Apr 2017 11:06:37 -0400 Subject: [Freeipa-users] "Purge" scripts? In-Reply-To: References: Message-ID: <2a04a71d-eea2-5c2b-6329-4c6d90c07769@redhat.com> Martin Ba?ti wrote: > > > On 26.04.2017 20:07, Robert L. Harris wrote: >> So twice now I've tried installing freeipa on an Ubuntu 16.04 >> system. Both times I've gotten an error and followed the instructions >> to "fix it" and they didn't work so I removed files ( with purge ), >> cleaned up everything I could find related to freeipa, sssd and kerb >> but trying to run it again gives either a different error or the same >> error with a different process output indicating it's not 100% clean. >> >> Is there a known list of paths, packages or files to make sure are >> un-installed or wiped out to make the system 100% clean? Preferably >> for Ubuntu. >> >> Robert >> >> >> > > Hello, could you be more specific about the errors? I think it is a misunderstanding. Removing the packages doesn't undo the configuration. I think he needs to reinstall the packages and run ipa-server-install --uninstall (though the ipa-upgrade post-install command may blow up on reinstall). rob From robert.l.harris at gmail.com Thu Apr 27 15:53:14 2017 From: robert.l.harris at gmail.com (Robert L. Harris) Date: Thu, 27 Apr 2017 15:53:14 +0000 Subject: [Freeipa-users] "Purge" scripts? In-Reply-To: <2a04a71d-eea2-5c2b-6329-4c6d90c07769@redhat.com> References: <2a04a71d-eea2-5c2b-6329-4c6d90c07769@redhat.com> Message-ID: "apt-get remove --purge " or "dpkg -P " should remove all files. One a previous build I tried the --uninstall and got an error. Right now I'm trying the PPA and 17.04 and getting a KRB error. On Thu, Apr 27, 2017 at 9:06 AM Rob Crittenden wrote: > Martin Ba?ti wrote: > > > > > > On 26.04.2017 20:07, Robert L. Harris wrote: > >> So twice now I've tried installing freeipa on an Ubuntu 16.04 > >> system. Both times I've gotten an error and followed the instructions > >> to "fix it" and they didn't work so I removed files ( with purge ), > >> cleaned up everything I could find related to freeipa, sssd and kerb > >> but trying to run it again gives either a different error or the same > >> error with a different process output indicating it's not 100% clean. > >> > >> Is there a known list of paths, packages or files to make sure are > >> un-installed or wiped out to make the system 100% clean? Preferably > >> for Ubuntu. > >> > >> Robert > >> > >> > >> > > > > Hello, could you be more specific about the errors? > > I think it is a misunderstanding. Removing the packages doesn't undo the > configuration. I think he needs to reinstall the packages and run > ipa-server-install --uninstall (though the ipa-upgrade post-install > command may blow up on reinstall). > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 27 16:07:34 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Apr 2017 12:07:34 -0400 Subject: [Freeipa-users] "Purge" scripts? In-Reply-To: References: <2a04a71d-eea2-5c2b-6329-4c6d90c07769@redhat.com> Message-ID: Robert L. Harris wrote: > > "apt-get remove --purge " or "dpkg -P " should remove all > files. One a previous build I tried the --uninstall and got an error. > Right now I'm trying the PPA and 17.04 and getting a KRB error. As I said, configuration is not erased on package removal, on purpose (in Fedora anyway, I've never examined the debian packaging). Without exact error messages and logs it will be very difficult to diagnose the problems you're having. rob > > On Thu, Apr 27, 2017 at 9:06 AM Rob Crittenden > wrote: > > Martin Ba?ti wrote: > > > > > > On 26.04.2017 20:07, Robert L. Harris wrote: > >> So twice now I've tried installing freeipa on an Ubuntu 16.04 > >> system. Both times I've gotten an error and followed the > instructions > >> to "fix it" and they didn't work so I removed files ( with purge ), > >> cleaned up everything I could find related to freeipa, sssd and kerb > >> but trying to run it again gives either a different error or the same > >> error with a different process output indicating it's not 100% clean. > >> > >> Is there a known list of paths, packages or files to make sure are > >> un-installed or wiped out to make the system 100% clean? Preferably > >> for Ubuntu. > >> > >> Robert > >> > >> > >> > > > > Hello, could you be more specific about the errors? > > I think it is a misunderstanding. Removing the packages doesn't undo the > configuration. I think he needs to reinstall the packages and run > ipa-server-install --uninstall (though the ipa-upgrade post-install > command may blow up on reinstall). > > rob > From callum.guy at x-on.co.uk Thu Apr 27 18:55:39 2017 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 27 Apr 2017 18:55:39 +0000 Subject: [Freeipa-users] TLS 1.2 for PKI+SLAPD Message-ID: Hi All, I'm currently looking at hardening my FreeIPA server as part of a PCI assessment. I am hoping to be able to fix PKI (ports 8443) and SLAPD (LDAPS) to use only TLS1.2 - both currently support TLS1.0 and unfortunately that is non-compliant for my environment. Also i'm very much hoping not to break my installation! Does anyone have experience in this area? Best Regards, Callum -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 27 19:16:07 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Apr 2017 15:16:07 -0400 Subject: [Freeipa-users] TLS 1.2 for PKI+SLAPD In-Reply-To: References: Message-ID: <3070399b-86ce-2fbe-af74-ac3e38ba5b2c@redhat.com> Callum Guy wrote: > Hi All, > > I'm currently looking at hardening my FreeIPA server as part of a PCI > assessment. > > I am hoping to be able to fix PKI (ports 8443) and SLAPD (LDAPS) to use > only TLS1.2 - both currently support TLS1.0 and unfortunately that is > non-compliant for my environment. > > Also i'm very much hoping not to break my installation! > > Does anyone have experience in this area? It depends very much on what version you are running but see https://access.redhat.com/articles/2801181 for inspiration. rob From callum.guy at x-on.co.uk Thu Apr 27 19:23:00 2017 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 27 Apr 2017 19:23:00 +0000 Subject: [Freeipa-users] TLS 1.2 for PKI+SLAPD In-Reply-To: <3070399b-86ce-2fbe-af74-ac3e38ba5b2c@redhat.com> References: <3070399b-86ce-2fbe-af74-ac3e38ba5b2c@redhat.com> Message-ID: Thanks so much for the link Rob - i'm on 4.4.0. I'll get back in touch if i run into any issues - i find it difficult to locate these help pages so really do appreciate the advice On Thu, Apr 27, 2017 at 8:16 PM Rob Crittenden wrote: > Callum Guy wrote: > > Hi All, > > > > I'm currently looking at hardening my FreeIPA server as part of a PCI > > assessment. > > > > I am hoping to be able to fix PKI (ports 8443) and SLAPD (LDAPS) to use > > only TLS1.2 - both currently support TLS1.0 and unfortunately that is > > non-compliant for my environment. > > > > Also i'm very much hoping not to break my installation! > > > > Does anyone have experience in this area? > > It depends very much on what version you are running but see > https://access.redhat.com/articles/2801181 for inspiration. > > rob > > -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Thu Apr 27 21:01:51 2017 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 27 Apr 2017 21:01:51 +0000 Subject: [Freeipa-users] TLS 1.2 for PKI+SLAPD In-Reply-To: References: <3070399b-86ce-2fbe-af74-ac3e38ba5b2c@redhat.com> Message-ID: For others reference this is regarding CentOS 7.2 with FreeIPA 4.4.0 Directory server change suggested on the link are for an older version. Minimum TLS support can be altered as follows: */etc/dirsrv/slapd-DOMAIN.COM/dse.ldif* dn: cn=encryption,cn=config allowWeakCipher: off cn: encryption createTimestamp: 20161130110528Z creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=Directory Manager modifyTimestamp: 20161213085006Z nsSSLClientAuth: allowed nsSSLSessionTimeout: 0 nsSSL3Ciphers: default objectClass: top objectClass: nsEncryptionConfig sslVersionMin: TLS1.2 I'm still working on port 8443 (DogTag/PKI/Tomcat) - configuration in /usr/share/pki/server/conf/server.xml seems to roughly match the linked article however its all tokenized as shown below: 203 sslOptions="[TOMCAT_SSL_OPTIONS]" 204 ssl2Ciphers="[TOMCAT_SSL2_CIPHERS]" 205 ssl3Ciphers="[TOMCAT_SSL3_CIPHERS]" 206 tlsCiphers="[TOMCAT_TLS_CIPHERS]" 207 sslVersionRangeStream="[TOMCAT_SSL_VERSION_RANGE_STREAM]" 208 sslVersionRangeDatagram="[TOMCAT_SSL_VERSION_RANGE_DATAGRAM]" 209 sslRangeCiphers="[TOMCAT_SSL_RANGE_CIPHERS]" I'll feed back if i work it out. Thanks, On Thu, Apr 27, 2017 at 8:22 PM Callum Guy wrote: > Thanks so much for the link Rob - i'm on 4.4.0. I'll get back in touch if > i run into any issues - i find it difficult to locate these help pages so > really do appreciate the advice > > On Thu, Apr 27, 2017 at 8:16 PM Rob Crittenden > wrote: > >> Callum Guy wrote: >> > Hi All, >> > >> > I'm currently looking at hardening my FreeIPA server as part of a PCI >> > assessment. >> > >> > I am hoping to be able to fix PKI (ports 8443) and SLAPD (LDAPS) to use >> > only TLS1.2 - both currently support TLS1.0 and unfortunately that is >> > non-compliant for my environment. >> > >> > Also i'm very much hoping not to break my installation! >> > >> > Does anyone have experience in this area? >> >> It depends very much on what version you are running but see >> https://access.redhat.com/articles/2801181 for inspiration. >> >> rob >> >> -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Thu Apr 27 21:50:45 2017 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 27 Apr 2017 21:50:45 +0000 Subject: [Freeipa-users] TLS 1.2 for PKI+SLAPD In-Reply-To: References: <3070399b-86ce-2fbe-af74-ac3e38ba5b2c@redhat.com> Message-ID: Managed to get PKI/Tomcat patched for TLS 1.2. */etc/pki/pki-tomcat/server.xml* *...* * sslVersionRangeStream="tls1_2:tls1_2" * *sslVersionRangeDatagram="tls1_2:tls1_2" * *...* Thanks, resolved. On Thu, Apr 27, 2017 at 10:01 PM Callum Guy wrote: > For others reference this is regarding CentOS 7.2 with FreeIPA 4.4.0 > > Directory server change suggested on the link are for an older version. > Minimum TLS support can be altered as follows: > > */etc/dirsrv/slapd-DOMAIN.COM/dse.ldif* > > dn: cn=encryption,cn=config > > allowWeakCipher: off > > cn: encryption > > createTimestamp: 20161130110528Z > > creatorsName: cn=server,cn=plugins,cn=config > > modifiersName: cn=Directory Manager > > modifyTimestamp: 20161213085006Z > > nsSSLClientAuth: allowed > > nsSSLSessionTimeout: 0 > > nsSSL3Ciphers: default > > objectClass: top > > objectClass: nsEncryptionConfig > sslVersionMin: TLS1.2 > > I'm still working on port 8443 (DogTag/PKI/Tomcat) - configuration in > /usr/share/pki/server/conf/server.xml seems to roughly match the linked > article however its all tokenized as shown below: > > 203 sslOptions="[TOMCAT_SSL_OPTIONS]" > 204 ssl2Ciphers="[TOMCAT_SSL2_CIPHERS]" > 205 ssl3Ciphers="[TOMCAT_SSL3_CIPHERS]" > 206 tlsCiphers="[TOMCAT_TLS_CIPHERS]" > 207 sslVersionRangeStream="[TOMCAT_SSL_VERSION_RANGE_STREAM]" > 208 > sslVersionRangeDatagram="[TOMCAT_SSL_VERSION_RANGE_DATAGRAM]" > 209 sslRangeCiphers="[TOMCAT_SSL_RANGE_CIPHERS]" > > I'll feed back if i work it out. > > Thanks, > > On Thu, Apr 27, 2017 at 8:22 PM Callum Guy wrote: > >> Thanks so much for the link Rob - i'm on 4.4.0. I'll get back in touch if >> i run into any issues - i find it difficult to locate these help pages so >> really do appreciate the advice >> >> On Thu, Apr 27, 2017 at 8:16 PM Rob Crittenden >> wrote: >> >>> Callum Guy wrote: >>> > Hi All, >>> > >>> > I'm currently looking at hardening my FreeIPA server as part of a PCI >>> > assessment. >>> > >>> > I am hoping to be able to fix PKI (ports 8443) and SLAPD (LDAPS) to use >>> > only TLS1.2 - both currently support TLS1.0 and unfortunately that is >>> > non-compliant for my environment. >>> > >>> > Also i'm very much hoping not to break my installation! >>> > >>> > Does anyone have experience in this area? >>> >>> It depends very much on what version you are running but see >>> https://access.redhat.com/articles/2801181 for inspiration. >>> >>> rob >>> >>> -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dewanggaba at xtremenitro.org Fri Apr 28 01:50:27 2017 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Fri, 28 Apr 2017 08:50:27 +0700 Subject: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s) In-Reply-To: References: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> <681cdb4a-84d9-5813-bb4d-91519b8057e8@xtremenitro.org> <9fcc4dcb-52e2-83e2-72c3-222f4ac1ab22@redhat.com> <07a034fb-dc26-8528-cb1b-1b465fc1daee@xtremenitro.org> Message-ID: <9f1dc301-a003-b19c-3e1b-d40026348e54@xtremenitro.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! On 04/26/2017 08:08 PM, Florence Blanc-Renaud wrote: > On 04/25/2017 10:56 AM, Dewangga Bachrul Alam wrote: Hello! > > Master IPA Server: - I install 1 (one) server as master > (self-signed) and add/modify using external CA. - I am using > ipa-cacert-manage install then ipa-certupdate on master > >> Hi, > >> I think I got you wrong... Do you mean that you installed IPA >> with an integrated IdM CA which was self-signed, then your intent >> was to move to integrated IdM CA externally signed? In this case, >> the right command would be ipa-cacert-manage renew --external-ca, >> and the procedure is described in "Changing the certificate >> chain" [1]. Ah thanks for your corrections and information, then what should I do? Should I run ipa-cacert-manage renew --external-ca ? > >> The command ipa-cacert-manage install does not replace the >> integrated IdM CA but adds the certificate as a known CA. > >> Hope this clarifies, Flo > >> [1] >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-ce rt-chaining.html > >> > > Replica IPA Server: - I install 1 (one) server as client and > promoted to ipa-replica: - I run `ipa-client-install` and > autodiscovery - Then `ipa-replica-install --principal admin > --admin-password ` > > I've hit ipa-certupdate -v to verbose the logs (attached at first > email). Then replica server aren't using external CA(s) like master > did. > > So, I did the same like master, using `ipa-cacert-manage` on > replica, and it's work fine. If it's normal, then thanks for > clarifying this. > > On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote: >>>> Hi, >>>> >>>> As your email refers to self-signed and signed CA >>>> certificate, can you please clarify the exact steps that you >>>> followed? It looks like - you first installed FreeIPA with a >>>> self-signed CA - you added an external CA (did you use >>>> ipa-cacert-manage install on 1 server then ipa-certupdate on >>>> all replicas?) - you replaced the httpd/LDAP certificates >>>> with a cert signed from the external CA (you probably ran >>>> ipa-server-certinstall on one server). >>>> >>>> In this case it is normal that the httpd/LDAP certificates on >>>> the replica were not updated as they are different (each IPA >>>> server has his own httpd/LDAP cert which contains the >>>> hostname in its subject). You can check this by performing on >>>> each server: ipaserver$ sudo certutil -d /etc/httpd/alias/ -L >>>> -n Server-Cert | grep Subject: Subject: >>>> "CN=ipaserver.domain.com,O=DOMAIN.COM" ^^^^^^^^^ >>>> >>>> If the goal is to replace the httpd/LDAP certificates on the >>>> replica, the command ipa-server-certinstall must also be run >>>> on the replica with the appropriate certificate. >>>> >>>> HTH, Flo. >>>> >>>> On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello! >>>> >>>> Just update, manually add external CA(s) and signed >>>> certificated was successful, but why it's didn't >>>> automatically transferred to replica(s) from master. >>>> >>>> On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote: >>>>>>> Hello! >>>>>>> >>>>>>> I've successfully create replica, everything works fine >>>>>>> but why my signed CA certificate didn't automatically >>>>>>> transfer to another replica(s)? Is it normal? >>>>>>> >>>>>>> Trying to add manually, but the certificate in >>>>>>> replica(s) still using self-signed. Here's the output >>>>>>> from `ipa-certupdate -v` >>>>>>> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1U NdI > >>>>>>> GYh >>>> >>>>>>> > yR >>>>>>> >>>>>>> >>>> LivL9gydE= >>>>>>> >>>>>>> Interesting line was : >>>>>>> >>>>>>> ipa: DEBUG: stderr= ipa: DEBUG: Starting external >>>>>>> process ipa: DEBUG: args=/usr/bin/certutil -d >>>>>>> /etc/ipa/nssdb -L -n IPA CA -a ipa: DEBUG: Process >>>>>>> finished, return code=255 ipa: DEBUG: stdout= ipa: >>>>>>> DEBUG: stderr=certutil: Could not find cert: IPA CA : >>>>>>> PR_FILE_NOT_FOUND_ERROR: File not found >>>>>>> >>>>>>> ipa: DEBUG: Starting external process ipa: DEBUG: >>>>>>> args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External >>>>>>> CA cert -a ipa: DEBUG: Process finished, return >>>>>>> code=255 ipa: DEBUG: stdout= ipa: DEBUG: >>>>>>> stderr=certutil: Could not find cert: External CA cert >>>>>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>>>>> >>>>>>> FYI: The replica server previously was a client and >>>>>>> promoted to be a replica by hitting this command: >>>>>>> `ipa-replica-install --principal admin >>>>>>> --admin-password admin_password` >>>>>>> >>>>>>> Any hints? >>>>>>> >>>>> >>>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQI4BAEBCAAiBQJZAp/fGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcFhED/0VncBpnHq9jTIjQCel6wpqITpob3CeqtFMKFvx9gl6/7jKzkbO 1sNr8qcvB2Hne9mp41EDXhQw9ZLxNHTqt6JOAzdGFGO3qwsIH+l8V0pNX2knnsSw b2MEhNmftKOl+kDFmEarESA5SyRtVFnPN1AjMIMw2ncQUpDodZyWdkip+E45oo1v oXUFnjCrG2eY0/LK637GG7s6bPjW3w77vzeGgHDafPkWI0qbNrWff/VHpIMbFKs8 udxT61M7KpUSR3dOMAwuWSYXZ/W5YFFHKAPagKQ6vvDK/VmkCLWob0zZ1J9QErUg zbMhXNpNHzfpJj67ds25F4EF/tVc2GiN7Thq/HBZj8YUPDyGdgafyvjT4Na86S1F g/tQsl/2V28SlNaZ6SPfrl2/AN6kAMKI5/GQGiNHVUdCGf4d+j/NERmlLf9fw8xu kgL9YI7fKkHoTYypJkfu+3L4hGkdKo7ylGnojZnjsc1Uw9eulvilAi6U9s7FYUzt xTiVNYP5UGixzDq2nJBgFARDdxd0f+rsUqedAbnnb5fXUdUu1IAvocNRA8U8Bhw+ PYeypIufrzcOFdNZNPmeGc9TEA8Y3/5i6vIHimndDMAWy2LtbtoNwLxW+y5unuMS MNY+oI3ObPgmFslJOFWx+lTTuGbt5xjWxUUY3MUJwCUb7VzijRNXvpzBiw== =plyF -----END PGP SIGNATURE----- From dewanggaba at xtremenitro.org Fri Apr 28 02:05:27 2017 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Fri, 28 Apr 2017 09:05:27 +0700 Subject: [Freeipa-users] Creating another sudo rules full Message-ID: <7d958901-e15c-6cf3-9d9f-af9c50eaa565@xtremenitro.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! Is it possible to create another sudo rules that same with sudo_rule_full or admin privileges, it means that the user can run `sudo su -` without password. I've create the similar rules, but no luck. [root at idm ~]# ipa sudorule-show sudo_rules_rekanalar Rule name: sudo_rules_rekanalar Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: rekanalar Host Groups: rekanalarservers Sudo Option: !authenticate ## Client [user at server02-v2 ~]$ sudo -l [sudo] password for user: But, if I change/add the user to group admins, it's success can invoke `sudo su -` command without password. Any helps is appreciated. Many thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQI4BAEBCAAiBQJZAqNgGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcK5+D/9G06PweGNcJrXuMANcVHysu9Wp97HfExFsGKpoDYU8t2Mip49R OUD/mLUoPGzNpMVJwOF8V1SMJXjyKUwlnBbGTnOxTvHEzkXyQ0HMsBFVzJJ38LX8 TJItYn8DM45hlnKkVKYM3hTiGSUpNGAM4OLYFQK/AWwx+u/2w1pTjmZQCKCHndvP /71u3octwTPPZPj2bbxlm8lhZovqPhB3JHpTGSckhvnS77t3W0L4KzaSF4omycni GbAY8DGTIxXPp33EOJV3JKOpYRrwv5URdgtpNbfWN0l6O8VyJx8A/lamjoQ284gz p8FJbZni1AoQ3/v2ZIbVcS7UJwqRVnhGFIwmmnlMEWz59NcrIxcxiAbsMepcTmOi Sq010zOHz3TmRURW2CIPBHGscax0DErIviWFIO+lMy2W/7LSaPoTge4ilDyl7UBu 3uPrEOU5Kh3Z7ar0VP5Pd4FH5OJp3WBXY8tMxPG7h5KniRTuv9/WszP4+L7EFDWR WdbZYkh1IYJUfsCvlLhYXDULjgacRPXmdQSXQkGD7b1WfmL0Wyy+TnSHKlr4X9LP dqwKYgjVC6FokoTfRoMi/D27lwkV4PKsNA6nufze9kDxgYC/7VrAEeIFCEedWUfv oGIBr94eMQYt8QI2GSikiUqJu0QccqtL+8ymE1lhByr9WmuxN6Ni1IhZ3w== =MUPU -----END PGP SIGNATURE----- From datakid at gmail.com Fri Apr 28 03:10:20 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Fri, 28 Apr 2017 13:10:20 +1000 Subject: [Freeipa-users] List SPAM In-Reply-To: References: <5beedf04-1769-9abf-62d0-14401f6bbb7c@redhat.com> Message-ID: On 24 April 2017 at 12:24, Prasun Gera wrote: > That doesn't work very well. The spam bots use different emails. And gmail > marks the entire message thread as spam, not just the spam reply. > > On Sun, Apr 23, 2017 at 7:20 AM, Dewangga Bachrul Alam < > dewanggaba at xtremenitro.org> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Mark as spam, and they gone from my inbox. :) >> >> If you are using gmail: - block the email address - mark the message as spam (not the thread) - you can then delete the message in question Note that this can still cause issues wrt workplace and SFW images, as Gmail automatically "previews" images. I leave them to deal with at home and have reported the problem to my manager and IT team so they know it's not my fault - as both acknowledge and understand that this forum has been very valuable to us wrt getting things working. 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: From ftweedal at redhat.com Fri Apr 28 06:19:26 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 28 Apr 2017 16:19:26 +1000 Subject: [Freeipa-users] how to setup freeipa project to local environment In-Reply-To: <7a5d9354-cb5f-fc36-ab08-e7b1ef84dcc4@gworks.mobi> References: <7a5d9354-cb5f-fc36-ab08-e7b1ef84dcc4@gworks.mobi> Message-ID: <20170428061926.GX21957@dhcp-40-8.bne.redhat.com> On Fri, Apr 28, 2017 at 10:41:29AM +0530, rajkumar wrote: > Hello freeipa team, > > I have download freeipa4.4.4.tar.gz and I need to setup freeipa project as > a local environment(to customize via IDE like eclipse) for customization. > suggest me how can do that. or any reference link. > > Thanks, > Instructions for building FreeIPA from source (on Red Hat-flavoured distros, at least) are here: http://www.freeipa.org/page/Build If you think your work may be useful to other please engage with upstream development on IRC (#freenode), mailing list (freeipa-devel at redhat.com) and GitHub (freeipa/freeipa). Cheers, Fraser From flo at redhat.com Fri Apr 28 07:16:54 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 28 Apr 2017 09:16:54 +0200 Subject: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s) In-Reply-To: <9f1dc301-a003-b19c-3e1b-d40026348e54@xtremenitro.org> References: <0981f8e8-f255-1749-e63a-0655e890c788@xtremenitro.org> <681cdb4a-84d9-5813-bb4d-91519b8057e8@xtremenitro.org> <9fcc4dcb-52e2-83e2-72c3-222f4ac1ab22@redhat.com> <07a034fb-dc26-8528-cb1b-1b465fc1daee@xtremenitro.org> <9f1dc301-a003-b19c-3e1b-d40026348e54@xtremenitro.org> Message-ID: <5cb6efe5-679a-ef86-2019-7d9489f75775@redhat.com> On 04/28/2017 03:50 AM, Dewangga Bachrul Alam wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello! > > On 04/26/2017 08:08 PM, Florence Blanc-Renaud wrote: >> On 04/25/2017 10:56 AM, Dewangga Bachrul Alam wrote: Hello! >> >> Master IPA Server: - I install 1 (one) server as master >> (self-signed) and add/modify using external CA. - I am using >> ipa-cacert-manage install then ipa-certupdate on master >> >>> Hi, >> >>> I think I got you wrong... Do you mean that you installed IPA >>> with an integrated IdM CA which was self-signed, then your intent >>> was to move to integrated IdM CA externally signed? In this case, >>> the right command would be ipa-cacert-manage renew --external-ca, >>> and the procedure is described in "Changing the certificate >>> chain" [1]. > > Ah thanks for your corrections and information, then what should I do? > Should I run ipa-cacert-manage renew --external-ca ? > Yes, this is the way to go, documented here [1]. This is a 2-step process: when the command is run, it will create a CSR that needs to be signed by an external CA. Then the command must be re-launched with the new certificate delivered by the CA. Also do not forget to run ipa-certupdate on the master and all the replicas/clients. Flo. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext >> >>> The command ipa-cacert-manage install does not replace the >>> integrated IdM CA but adds the certificate as a known CA. >> >>> Hope this clarifies, Flo >> >>> [1] >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu > x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-ce > rt-chaining.html >> >>> >> >> Replica IPA Server: - I install 1 (one) server as client and >> promoted to ipa-replica: - I run `ipa-client-install` and >> autodiscovery - Then `ipa-replica-install --principal admin >> --admin-password ` >> >> I've hit ipa-certupdate -v to verbose the logs (attached at first >> email). Then replica server aren't using external CA(s) like master >> did. >> >> So, I did the same like master, using `ipa-cacert-manage` on >> replica, and it's work fine. If it's normal, then thanks for >> clarifying this. >> >> On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote: >>>>> Hi, >>>>> >>>>> As your email refers to self-signed and signed CA >>>>> certificate, can you please clarify the exact steps that you >>>>> followed? It looks like - you first installed FreeIPA with a >>>>> self-signed CA - you added an external CA (did you use >>>>> ipa-cacert-manage install on 1 server then ipa-certupdate on >>>>> all replicas?) - you replaced the httpd/LDAP certificates >>>>> with a cert signed from the external CA (you probably ran >>>>> ipa-server-certinstall on one server). >>>>> >>>>> In this case it is normal that the httpd/LDAP certificates on >>>>> the replica were not updated as they are different (each IPA >>>>> server has his own httpd/LDAP cert which contains the >>>>> hostname in its subject). You can check this by performing on >>>>> each server: ipaserver$ sudo certutil -d /etc/httpd/alias/ -L >>>>> -n Server-Cert | grep Subject: Subject: >>>>> "CN=ipaserver.domain.com,O=DOMAIN.COM" ^^^^^^^^^ >>>>> >>>>> If the goal is to replace the httpd/LDAP certificates on the >>>>> replica, the command ipa-server-certinstall must also be run >>>>> on the replica with the appropriate certificate. >>>>> >>>>> HTH, Flo. >>>>> >>>>> On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello! >>>>> >>>>> Just update, manually add external CA(s) and signed >>>>> certificated was successful, but why it's didn't >>>>> automatically transferred to replica(s) from master. >>>>> >>>>> On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote: >>>>>>>> Hello! >>>>>>>> >>>>>>>> I've successfully create replica, everything works fine >>>>>>>> but why my signed CA certificate didn't automatically >>>>>>>> transfer to another replica(s)? Is it normal? >>>>>>>> >>>>>>>> Trying to add manually, but the certificate in >>>>>>>> replica(s) still using self-signed. Here's the output >>>>>>>> from `ipa-certupdate -v` >>>>>>>> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1U > NdI >> >>>>>>>> > GYh >>>>> >>>>>>>> >> yR >>>>>>>> >>>>>>>> >>>>> LivL9gydE= >>>>>>>> >>>>>>>> Interesting line was : >>>>>>>> >>>>>>>> ipa: DEBUG: stderr= ipa: DEBUG: Starting external >>>>>>>> process ipa: DEBUG: args=/usr/bin/certutil -d >>>>>>>> /etc/ipa/nssdb -L -n IPA CA -a ipa: DEBUG: Process >>>>>>>> finished, return code=255 ipa: DEBUG: stdout= ipa: >>>>>>>> DEBUG: stderr=certutil: Could not find cert: IPA CA : >>>>>>>> PR_FILE_NOT_FOUND_ERROR: File not found >>>>>>>> >>>>>>>> ipa: DEBUG: Starting external process ipa: DEBUG: >>>>>>>> args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External >>>>>>>> CA cert -a ipa: DEBUG: Process finished, return >>>>>>>> code=255 ipa: DEBUG: stdout= ipa: DEBUG: >>>>>>>> stderr=certutil: Could not find cert: External CA cert >>>>>>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>>>>>> >>>>>>>> FYI: The replica server previously was a client and >>>>>>>> promoted to be a replica by hitting this command: >>>>>>>> `ipa-replica-install --principal admin >>>>>>>> --admin-password admin_password` >>>>>>>> >>>>>>>> Any hints? >>>>>>>> >>>>>> >>>>> >>> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQI4BAEBCAAiBQJZAp/fGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl > f9IgoCjNcFhED/0VncBpnHq9jTIjQCel6wpqITpob3CeqtFMKFvx9gl6/7jKzkbO > 1sNr8qcvB2Hne9mp41EDXhQw9ZLxNHTqt6JOAzdGFGO3qwsIH+l8V0pNX2knnsSw > b2MEhNmftKOl+kDFmEarESA5SyRtVFnPN1AjMIMw2ncQUpDodZyWdkip+E45oo1v > oXUFnjCrG2eY0/LK637GG7s6bPjW3w77vzeGgHDafPkWI0qbNrWff/VHpIMbFKs8 > udxT61M7KpUSR3dOMAwuWSYXZ/W5YFFHKAPagKQ6vvDK/VmkCLWob0zZ1J9QErUg > zbMhXNpNHzfpJj67ds25F4EF/tVc2GiN7Thq/HBZj8YUPDyGdgafyvjT4Na86S1F > g/tQsl/2V28SlNaZ6SPfrl2/AN6kAMKI5/GQGiNHVUdCGf4d+j/NERmlLf9fw8xu > kgL9YI7fKkHoTYypJkfu+3L4hGkdKo7ylGnojZnjsc1Uw9eulvilAi6U9s7FYUzt > xTiVNYP5UGixzDq2nJBgFARDdxd0f+rsUqedAbnnb5fXUdUu1IAvocNRA8U8Bhw+ > PYeypIufrzcOFdNZNPmeGc9TEA8Y3/5i6vIHimndDMAWy2LtbtoNwLxW+y5unuMS > MNY+oI3ObPgmFslJOFWx+lTTuGbt5xjWxUUY3MUJwCUb7VzijRNXvpzBiw== > =plyF > -----END PGP SIGNATURE----- > From t.ruiten at rdmedia.com Fri Apr 28 10:09:18 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Fri, 28 Apr 2017 12:09:18 +0200 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: <20170414131352.lpy5ggt5lsne727j@redhat.com> References: <20170413150952.qyuinpdhij23bqpw@redhat.com> <20170413194406.j5paq2uldrmfpobm@redhat.com> <20170414082327.e72mrc4s7aaauqw7@redhat.com> <20170414120709.efhq6xpgf4746o6l@redhat.com> <20170414131352.lpy5ggt5lsne727j@redhat.com> Message-ID: Hello, I set up a fresh Windows Server 2012R2 instance, configured a new forest named 'clients.rdmedia.com' and I'm getting the same error in the httpd error_log after running 'ipa trust-add clients.rdmedia.com --type=ad --admin=Administrator --password': [Fri Apr 28 12:05:00.420174 2017] [:error] [pid 26417] ipa: ERROR: non-public: RuntimeError: (-1073741811, 'Unexpected information received') [Fri Apr 28 12:05:00.420225 2017] [:error] [pid 26417] Traceback (most recent call last): [Fri Apr 28 12:05:00.420230 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in wsgi_execute [Fri Apr 28 12:05:00.420235 2017] [:error] [pid 26417] result = command(*args, **options) [Fri Apr 28 12:05:00.420239 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Fri Apr 28 12:05:00.420243 2017] [:error] [pid 26417] return self.__do_call(*args, **options) [Fri Apr 28 12:05:00.420247 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Fri Apr 28 12:05:00.420251 2017] [:error] [pid 26417] ret = self.run(*args, **options) [Fri Apr 28 12:05:00.420255 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Fri Apr 28 12:05:00.420258 2017] [:error] [pid 26417] return self.execute(*args, **options) [Fri Apr 28 12:05:00.420262 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 739, in execute [Fri Apr 28 12:05:00.420267 2017] [:error] [pid 26417] result = self.execute_ad(full_join, *keys, **options) [Fri Apr 28 12:05:00.420297 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 989, in execute_ad [Fri Apr 28 12:05:00.420304 2017] [:error] [pid 26417] trust_type [Fri Apr 28 12:05:00.420308 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in join_ad_full_credentials [Fri Apr 28 12:05:00.420312 2017] [:error] [pid 26417] trust_type, trust_external) [Fri Apr 28 12:05:00.420316 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in establish_trust [Fri Apr 28 12:05:00.420320 2017] [:error] [pid 26417] self.update_ftinfo(another_domain) [Fri Apr 28 12:05:00.420324 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in update_ftinfo [Fri Apr 28 12:05:00.420328 2017] [:error] [pid 26417] ftinfo, 0) [Fri Apr 28 12:05:00.420331 2017] [:error] [pid 26417] RuntimeError: (-1073741811, 'Unexpected information received') [Fri Apr 28 12:05:00.420975 2017] [:error] [pid 26417] ipa: INFO: [jsonserver_session] admin at I.RDMEDIA.COM: trust_add/1(u'clients.rdmedia.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', version=u'2.213'): RuntimeError Am I doing something wrong? Logs are ofcourse available privately on request. On 14 April 2017 at 15:13, Alexander Bokovoy wrote: > On pe, 14 huhti 2017, Tiemen Ruiten wrote: > >> Yes, office.rdmedia.com is the Samba AD domain. >> >> [root at fluorine samba]# samba-tool domain trust list >> Type[Forest] Transitive[Yes] Direction[INCOMING] Name[i.rdmedia.com] >> [root at fluorine samba]# samba-tool domain trust show i.rdmedia.com >> LocalDomain Netbios[OFFICE] DNS[office.rdmedia.com] >> SID[S-1-5-21-482924559-3201240232-3198541477] >> TrusteDomain: >> >> NetbiosName: IPA >> DnsName: i.rdmedia.com >> SID: S-1-5-21-3716778977-2487905546-4034507762 >> Type: 0x2 (UPLEVEL) >> Direction: 0x1 (INBOUND) >> Attributes: 0x8 (FOREST_TRANSITIVE) >> PosixOffset: 0x00000000 (0) >> kerb_EncTypes: 0x1c >> (RC4_HMAC_MD5,AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96) >> Namespaces[0] TDO[i.rdmedia.com]: >> > Ok, thanks. I'll look into this part of Samba code later, after Easter. > > > >> >> On 14 April 2017 at 14:07, Alexander Bokovoy wrote: >> >> On pe, 14 huhti 2017, Tiemen Ruiten wrote: >>> >>> Hello Alexander, >>>> >>>> That's strange, when I try to setup a trust with a domain that isn't a >>>> subdomain of FreeIPA, I get the same error. I reran: >>>> >>>> ipa-adtrust-install --netbios-name=IPA >>>> >>>> and then ran: >>>> >>>> ipa trust-add --type=ad office.rdmedia.com --admin Administrator >>>> --password >>>> >>>> office.rdmedia.com is Samba AD? >>> >>> Then please show output of >>> >>> samba-tool domain trust list >>> >>> and for each domain name in the output above show >>> >>> samba-tool domain trust show >>> >>> >>> >>> >>> >>> Last bit of the error_log: >>>> >>>> rpc reply data: >>>> [0000] 00 00 00 00 .... >>>> lsa_lsaRSetForestTrustInformation: struct >>>> lsa_lsaRSetForestTrustInformation >>>> in: struct lsa_lsaRSetForestTrustInformation >>>> handle : * >>>> handle: struct policy_handle >>>> handle_type : 0x00000000 (0) >>>> uuid : >>>> 43cfa5e6-c10a-49a5-9b75-f7284ee44aac >>>> trusted_domain_name : * >>>> trusted_domain_name: struct lsa_StringLarge >>>> length : 0x001a (26) >>>> size : 0x001c (28) >>>> string : * >>>> string : 'i.rdmedia.com' >>>> highest_record_type : LSA_FOREST_TRUST_DOMAIN_INFO (2) >>>> forest_trust_info : * >>>> forest_trust_info: struct lsa_ForestTrustInformation >>>> count : 0x00000004 (4) >>>> entries : * >>>> entries: ARRAY(4) >>>> entries : * >>>> entries: struct lsa_ForestTrustRecord >>>> flags : 0x00000000 >>>> (0) >>>> 0: LSA_TLN_DISABLED_NEW >>>> 0: LSA_TLN_DISABLED_ADMIN >>>> 0: LSA_TLN_DISABLED_CONFLICT >>>> 0: LSA_SID_DISABLED_ADMIN >>>> 0: LSA_SID_DISABLED_CONFLICT >>>> 0: LSA_NB_DISABLED_ADMIN >>>> 0: LSA_NB_DISABLED_CONFLICT >>>> type : >>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>> time : Mon Apr 10 >>>> 08:43:18 2017 CEST >>>> forest_trust_data : union >>>> lsa_ForestTrustData(case 0) >>>> top_level_name: struct >>>> lsa_StringLarge >>>> length : 0x002c >>>> (44) >>>> size : 0x002e >>>> (46) >>>> string : * >>>> string : ' >>>> test.ams.i.rdmedia.com' >>>> entries : * >>>> entries: struct lsa_ForestTrustRecord >>>> flags : 0x00000000 >>>> (0) >>>> 0: LSA_TLN_DISABLED_NEW >>>> 0: LSA_TLN_DISABLED_ADMIN >>>> 0: LSA_TLN_DISABLED_CONFLICT >>>> 0: LSA_SID_DISABLED_ADMIN >>>> 0: LSA_SID_DISABLED_CONFLICT >>>> 0: LSA_NB_DISABLED_ADMIN >>>> 0: LSA_NB_DISABLED_CONFLICT >>>> type : >>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>> time : Mon Apr 10 >>>> 08:43:18 2017 CEST >>>> forest_trust_data : union >>>> lsa_ForestTrustData(case 0) >>>> top_level_name: struct >>>> lsa_StringLarge >>>> length : 0x002c >>>> (44) >>>> size : 0x002e >>>> (46) >>>> string : * >>>> string : ' >>>> prod.ams.i.rdmedia.com' >>>> entries : * >>>> entries: struct lsa_ForestTrustRecord >>>> flags : 0x00000000 >>>> (0) >>>> 0: LSA_TLN_DISABLED_NEW >>>> 0: LSA_TLN_DISABLED_ADMIN >>>> 0: LSA_TLN_DISABLED_CONFLICT >>>> 0: LSA_SID_DISABLED_ADMIN >>>> 0: LSA_SID_DISABLED_CONFLICT >>>> 0: LSA_NB_DISABLED_ADMIN >>>> 0: LSA_NB_DISABLED_CONFLICT >>>> type : >>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>> time : Mon Apr 10 >>>> 08:43:18 2017 CEST >>>> forest_trust_data : union >>>> lsa_ForestTrustData(case 0) >>>> top_level_name: struct >>>> lsa_StringLarge >>>> length : 0x001a >>>> (26) >>>> size : 0x001c >>>> (28) >>>> string : * >>>> string : ' >>>> i.rdmedia.com' >>>> entries : * >>>> entries: struct lsa_ForestTrustRecord >>>> flags : 0x00000000 >>>> (0) >>>> 0: LSA_TLN_DISABLED_NEW >>>> 0: LSA_TLN_DISABLED_ADMIN >>>> 0: LSA_TLN_DISABLED_CONFLICT >>>> 0: LSA_SID_DISABLED_ADMIN >>>> 0: LSA_SID_DISABLED_CONFLICT >>>> 0: LSA_NB_DISABLED_ADMIN >>>> 0: LSA_NB_DISABLED_CONFLICT >>>> type : >>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>> time : Mon Apr 10 >>>> 08:43:18 2017 CEST >>>> forest_trust_data : union >>>> lsa_ForestTrustData(case 0) >>>> top_level_name: struct >>>> lsa_StringLarge >>>> length : 0x002c >>>> (44) >>>> size : 0x002e >>>> (46) >>>> string : * >>>> string : ' >>>> prod.nyc.i.rdmedia.com' >>>> check_only : 0x00 (0) >>>> rpc request data: >>>> [0000] 00 00 00 00 E6 A5 CF 43 0A C1 A5 49 9B 75 F7 28 .......C >>>> ...I.u.( >>>> [0010] 4E E4 4A AC 1A 00 1C 00 00 00 02 00 0E 00 00 00 N.J..... >>>> ........ >>>> [0020] 00 00 00 00 0D 00 00 00 69 00 2E 00 72 00 64 00 ........ >>>> i...r.d. >>>> [0030] 6D 00 65 00 64 00 69 00 61 00 2E 00 63 00 6F 00 m.e.d.i. >>>> a...c.o. >>>> [0040] 6D 00 02 00 04 00 00 00 04 00 02 00 04 00 00 00 m....... >>>> ........ >>>> [0050] 08 00 02 00 0C 00 02 00 10 00 02 00 14 00 02 00 ........ >>>> ........ >>>> [0060] 00 00 00 00 00 00 00 00 00 C7 B7 BC C5 B1 D2 01 ........ >>>> ........ >>>> [0070] 00 00 00 00 2C 00 2E 00 18 00 02 00 17 00 00 00 ....,... >>>> ........ >>>> [0080] 00 00 00 00 16 00 00 00 74 00 65 00 73 00 74 00 ........ >>>> t.e.s.t. >>>> [0090] 2E 00 61 00 6D 00 73 00 2E 00 69 00 2E 00 72 00 ..a.m.s. >>>> ..i...r. >>>> [00A0] 64 00 6D 00 65 00 64 00 69 00 61 00 2E 00 63 00 d.m.e.d. >>>> i.a...c. >>>> [00B0] 6F 00 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 o.m..... >>>> ........ >>>> [00C0] 00 C7 B7 BC C5 B1 D2 01 00 00 00 00 2C 00 2E 00 ........ >>>> ....,... >>>> [00D0] 1C 00 02 00 17 00 00 00 00 00 00 00 16 00 00 00 ........ >>>> ........ >>>> [00E0] 70 00 72 00 6F 00 64 00 2E 00 61 00 6D 00 73 00 p.r.o.d. >>>> ..a.m.s. >>>> [00F0] 2E 00 69 00 2E 00 72 00 64 00 6D 00 65 00 64 00 ..i...r. >>>> d.m.e.d. >>>> [0100] 69 00 61 00 2E 00 63 00 6F 00 6D 00 00 00 00 00 i.a...c. >>>> o.m..... >>>> [0110] 00 00 00 00 00 00 00 00 00 C7 B7 BC C5 B1 D2 01 ........ >>>> ........ >>>> [0120] 00 00 00 00 1A 00 1C 00 20 00 02 00 0E 00 00 00 ........ >>>> ....... >>>> [0130] 00 00 00 00 0D 00 00 00 69 00 2E 00 72 00 64 00 ........ >>>> i...r.d. >>>> [0140] 6D 00 65 00 64 00 69 00 61 00 2E 00 63 00 6F 00 m.e.d.i. >>>> a...c.o. >>>> [0150] 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 m....... >>>> ........ >>>> [0160] 00 C7 B7 BC C5 B1 D2 01 00 00 00 00 2C 00 2E 00 ........ >>>> ....,... >>>> [0170] 24 00 02 00 17 00 00 00 00 00 00 00 16 00 00 00 $....... >>>> ........ >>>> [0180] 70 00 72 00 6F 00 64 00 2E 00 6E 00 79 00 63 00 p.r.o.d. >>>> ..n.y.c. >>>> [0190] 2E 00 69 00 2E 00 72 00 64 00 6D 00 65 00 64 00 ..i...r. >>>> d.m.e.d. >>>> [01A0] 69 00 61 00 2E 00 63 00 6F 00 6D 00 00 i.a...c. >>>> o.m.. >>>> signed SMB2 message >>>> lsa_lsaRSetForestTrustInformation: struct >>>> lsa_lsaRSetForestTrustInformation >>>> out: struct lsa_lsaRSetForestTrustInformation >>>> collision_info : * >>>> collision_info : NULL >>>> result : NT_STATUS_INVALID_PARAMETER >>>> rpc reply data: >>>> [0000] 00 00 00 00 0D 00 00 C0 ........ >>>> [Fri Apr 14 13:05:15.626311 2017] [:error] [pid 22596] ipa: ERROR: >>>> non-public: RuntimeError: (-1073741811, 'Unexpected information >>>> received') >>>> [Fri Apr 14 13:05:15.626384 2017] [:error] [pid 22596] Traceback (most >>>> recent call last): >>>> [Fri Apr 14 13:05:15.626392 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in >>>> wsgi_execute >>>> [Fri Apr 14 13:05:15.626399 2017] [:error] [pid 22596] result = >>>> command(*args, **options) >>>> [Fri Apr 14 13:05:15.626405 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in >>>> __call__ >>>> [Fri Apr 14 13:05:15.626416 2017] [:error] [pid 22596] return >>>> self.__do_call(*args, **options) >>>> [Fri Apr 14 13:05:15.626422 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in >>>> __do_call >>>> [Fri Apr 14 13:05:15.626428 2017] [:error] [pid 22596] ret = >>>> self.run(*args, **options) >>>> [Fri Apr 14 13:05:15.626434 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run >>>> [Fri Apr 14 13:05:15.626439 2017] [:error] [pid 22596] return >>>> self.execute(*args, **options) >>>> [Fri Apr 14 13:05:15.626445 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line >>>> 739, >>>> in >>>> execute >>>> [Fri Apr 14 13:05:15.626451 2017] [:error] [pid 22596] result = >>>> self.execute_ad(full_join, *keys, **options) >>>> [Fri Apr 14 13:05:15.626457 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line >>>> 989, >>>> in >>>> execute_ad >>>> [Fri Apr 14 13:05:15.626463 2017] [:error] [pid 22596] trust_type >>>> [Fri Apr 14 13:05:15.626468 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in >>>> join_ad_full_credentials >>>> [Fri Apr 14 13:05:15.626474 2017] [:error] [pid 22596] trust_type, >>>> trust_external) >>>> [Fri Apr 14 13:05:15.626479 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in >>>> establish_trust >>>> [Fri Apr 14 13:05:15.626485 2017] [:error] [pid 22596] >>>> self.update_ftinfo(another_domain) >>>> [Fri Apr 14 13:05:15.626490 2017] [:error] [pid 22596] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in >>>> update_ftinfo >>>> [Fri Apr 14 13:05:15.626495 2017] [:error] [pid 22596] ftinfo, 0) >>>> [Fri Apr 14 13:05:15.626500 2017] [:error] [pid 22596] RuntimeError: >>>> (-1073741811, 'Unexpected information received') >>>> [Fri Apr 14 13:05:15.627265 2017] [:error] [pid 22596] ipa: INFO: >>>> [jsonserver_session] admin at I.RDMEDIA.COM: >>>> trust_add/1(u'office.rdmedia.c >>>> om', >>>> trust_type=u'ad', realm_admin=u'Administrator', >>>> realm_passwd=u'********', >>>> version=u'2.213'): RuntimeError >>>> >>>> >>>> >>>> On 14 April 2017 at 10:23, Alexander Bokovoy >>>> wrote: >>>> >>>> On to, 13 huhti 2017, Alexander Bokovoy wrote: >>>> >>>>> >>>>> On Thu, 13 Apr 2017, Tiemen Ruiten wrote: >>>>> >>>>>> >>>>>> Excerpt from the httpd error_log on the FreeIPA replica: >>>>>> >>>>>>> >>>>>>> [Thu Apr 13 11:17:44.072996 2017] [:error] [pid 28346] ipa: INFO: >>>>>>> [jsonserver_kerb] admin at I.RDMEDIA.COM: ping(): SUCCESS >>>>>>> [Thu Apr 13 11:17:50.708019 2017] [:error] [pid 28347] ipa: ERROR: >>>>>>> non-public: RuntimeError: (-1073741811, 'Unexpected information >>>>>>> received') >>>>>>> >>>>>>> Please add 'log level = 10' to /usr/share/ipa/smb.conf.empty and >>>>>>> re-try >>>>>>> >>>>>> 'ipa trust-add', then send me resulting error_log privately. >>>>>> >>>>>> To get back to the public mailing list, Tiemen sent me logs and I >>>>>> >>>>> confirm that this is the same as https://bugzilla.redhat.com/sh >>>>> ow_bug.cgi?id=1421869 >>>>> >>>>> We currently have no solution to this problem (AD is subdomain of IPA >>>>> domain). >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Tiemen Ruiten >>>> Systems Engineer >>>> R&D Media >>>> >>>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> > > -- > / Alexander Bokovoy > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Fri Apr 28 12:01:12 2017 From: prasun.gera at gmail.com (Prasun Gera) Date: Fri, 28 Apr 2017 08:01:12 -0400 Subject: [Freeipa-users] List SPAM In-Reply-To: References: <5beedf04-1769-9abf-62d0-14401f6bbb7c@redhat.com> Message-ID: Yes, I am aware of the workarounds, and went through the exact same steps that you mentioned several times. This is clearly not a solution. Can someone from the team comment on why email addresses are published in the first place ? I do not see any advantages and plenty of disadvantages. Spam notwithstanding, I am not a big fan of the email being published at all. On Thu, Apr 27, 2017 at 11:10 PM, Lachlan Musicman wrote: > On 24 April 2017 at 12:24, Prasun Gera wrote: > >> That doesn't work very well. The spam bots use different emails. And >> gmail marks the entire message thread as spam, not just the spam reply. >> >> On Sun, Apr 23, 2017 at 7:20 AM, Dewangga Bachrul Alam < >> dewanggaba at xtremenitro.org> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Mark as spam, and they gone from my inbox. :) >>> >>> > > > If you are using gmail: > > - block the email address > - mark the message as spam (not the thread) > - you can then delete the message in question > > > Note that this can still cause issues wrt workplace and SFW images, as > Gmail automatically "previews" images. > > I leave them to deal with at home and have reported the problem to my > manager and IT team so they know it's not my fault - as both acknowledge > and understand that this forum has been very valuable to us wrt getting > things working. > > L. > > > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > > > > -- > 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 jason at tresgeek.net Fri Apr 28 12:26:23 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Fri, 28 Apr 2017 07:26:23 -0500 (CDT) Subject: [Freeipa-users] Creating another sudo rules full In-Reply-To: <7d958901-e15c-6cf3-9d9f-af9c50eaa565@xtremenitro.org> References: <7d958901-e15c-6cf3-9d9f-af9c50eaa565@xtremenitro.org> Message-ID: <1172995261.523.1493382383607.JavaMail.zimbra@tresgeek.net> Hi Dewangga, > [root at idm ~]# ipa sudorule-show sudo_rules_rekanalar > Rule name: sudo_rules_rekanalar > Enabled: TRUE > Command category: all > RunAs User category: all > RunAs Group category: all > User Groups: rekanalar > Host Groups: rekanalarservers > Sudo Option: !authenticate > > ## Client > [user at server02-v2 ~]$ sudo -l > [sudo] password for user: The rule in your example above only matches users in the group "rekanalar" on servers in the host group "rekanalarservers". Is the user "user" in your example in that group and is the host "server02-v2" in your example in that host group? Regards, j From bret.wortman at damascusgrp.com Fri Apr 28 12:57:48 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 28 Apr 2017 08:57:48 -0400 Subject: [Freeipa-users] I think I lost my CA... In-Reply-To: References: <25b53b08-ede0-7627-4b31-d9cb7de50b38@damascusgrp.com> <2da4022b-408a-846e-1acf-1d1b576987a6@damascusgrp.com> <42070482-0397-f4c7-552d-6215b6140197@damascusgrp.com> <50a036fb-b118-878e-5983-85427aefb8e5@damascusgrp.com> <81f171a5-3bea-ed43-94a0-c20f53b756f0@damascusgrp.com> Message-ID: Flo, I did find that issue and made those corrections to our /etc/hosts file, but the problem persists. Thanks for the idea! Bret On 04/27/2017 03:42 AM, Florence Blanc-Renaud wrote: > On 04/26/2017 04:33 PM, Bret Wortman wrote: >> So I can see my certs using cert-find, but can't get details using >> cert-show or add new ones using cert-request. >> >> # ipa cert-find >> : >> ------------------------------ >> Number of entries returned 385 >> ------------------------------ >> # ipa cert-show 895 >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> # ipa cert-show 1 (which does not exist) >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> # ipa cert-status 895 >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> # >> >> Is this an IPV6 thing? Because ipactl shows everything green and >> certmonger is running. >> > Hi Bret, > > the issue looks similar to https://pagure.io/freeipa/issue/6575 and > https://pagure.io/dogtagpki/issue/2570 which were IPv6 related. Note > that IPv6 must be enabled on the machine but IPA does not require an > IPv6 address to be configured (except for the loopback). > > You can check the following: > - is PKI listening to port 8009 on IPv6 or IPv4 interface? > sudo netstat -tunpl | grep 8009 > tcp6 0 0 127.0.0.1:8009 :::* LISTEN 10749/java > > - /etc/pki/pki-tomcat/server.xml defines a redirection from port 8009 > to 8443, and the "address" part is important: > protocol="AJP/1.3" > redirectPort="8443" > address="localhost" /> > > In the above example, it will be using localhost which can resolve > either to IPv4 or IPv6. > > - /etc/hosts must define the loopback addresses with > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > > HTH, > Flo. >> Bret >> >> >> On 04/26/2017 09:03 AM, Bret Wortman wrote: >>> >>> Digging still deeper: >>> >>> # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM >>> ipa: ERROR: Certificate operation cannot be completed: Unable to >>> communicate with CMS (503) >>> >>> Looks like this is an HTTP error; so is it possible that my IPA thinks >>> it has a CA but there's no CMS available? >>> >>> >>> On 04/26/2017 08:41 AM, Bret Wortman wrote: >>>> >>>> Using the firefox debugger, I get these errors when trying to pop up >>>> the New Certificate dialog: >>>> >>>> Empty string passed to getElementById(). (5) >>>> jquery.js:4:1060 >>>> TypeError: u is undefined >>>> app.js:1:362059 >>>> Empty string passed to getElementById(). (5) >>>> jquery.js:4:1060 >>>> TypeError: t is undefined >>>> app.js:1:217432 >>>> >>>> I'm definitely not a web kind of guy so I'm not sure if this is >>>> helpful or not. This is on 4.4.0, API Version 2.213. >>>> >>>> >>>> Bret >>>> >>>> >>>> On 04/26/2017 08:35 AM, Bret Wortman wrote: >>>>> >>>>> Good news. One of my servers _does_ have CA installed. So why does >>>>> "Action -> New Certificate" not do anything on this or any other >>>>> server? >>>>> >>>>> >>>>> Bret >>>>> >>>>> >>>>> On 04/25/2017 02:52 PM, Bret Wortman wrote: >>>>>> >>>>>> I recently had to upgrade all my Fedora IPA servers to C7. It went >>>>>> well, and we've been up and running nicely on 4.4.0 on C7 for the >>>>>> past month or so. >>>>>> >>>>>> Today, someone came and asked me to generate a new certificate for >>>>>> their web server. All was good until I went to the IPA UI and tried >>>>>> to perform Actions->New Certificate, which did nothing. I tried >>>>>> each of our 3 servers in turn. All came back with no popup window >>>>>> and no error, either. >>>>>> >>>>>> I suspect the problem might be that we no longer have a CA server >>>>>> due to the method I used to upgrade the servers. I likely missed a >>>>>> "--setup-ca" in there somewhere, so my rolling update rolled over >>>>>> the CA. >>>>>> >>>>>> What's my best hope of recovery? I never ran this before, so I'm >>>>>> not sure if this shows that I'm missing a CA or not: >>>>>> >>>>>> # ipa ca-find >>>>>> ------------ >>>>>> 1 CA matched >>>>>> ------------ >>>>>> Name: ipa >>>>>> Description IPA CA >>>>>> Authority ID: 3ce3346[...] >>>>>> Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM >>>>>> Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, >>>>>> O=DAMASCUSGRP.COM" >>>>>> ipa: ERROR: Failed to authenticate to CA REST API >>>>>> # klist >>>>>> Ticket cache: KEYRING:persistent:0:0 >>>>>> Default principal: admin at DAMASCUSGRP.COM >>>>>> >>>>>> Valid starting Expires Service principal >>>>>> 04/25/2017 18:48:26 04/26/2017 18:48:21 >>>>>> krbtgt/DAMASCUSGRP.COM at DAMASCUSGRP.COM >>>>>> # >>>>>> >>>>>> >>>>>> What's my best path of recovery? >>>>>> >>>>>> -- >>>>>> *Bret Wortman* >>>>>> The Damascus Group >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > From dewanggaba at xtremenitro.org Fri Apr 28 14:01:04 2017 From: dewanggaba at xtremenitro.org (Dewangga Bachrul Alam) Date: Fri, 28 Apr 2017 21:01:04 +0700 Subject: [Freeipa-users] Creating another sudo rules full In-Reply-To: <1172995261.523.1493382383607.JavaMail.zimbra@tresgeek.net> References: <7d958901-e15c-6cf3-9d9f-af9c50eaa565@xtremenitro.org> <1172995261.523.1493382383607.JavaMail.zimbra@tresgeek.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! On 04/28/2017 07:26 PM, Jason B. Nance wrote: > Hi Dewangga, > >> [root at idm ~]# ipa sudorule-show sudo_rules_rekanalar Rule name: >> sudo_rules_rekanalar Enabled: TRUE Command category: all RunAs >> User category: all RunAs Group category: all User Groups: >> rekanalar Host Groups: rekanalarservers Sudo Option: >> !authenticate >> >> ## Client [user at server02-v2 ~]$ sudo -l [sudo] password for >> user: > > The rule in your example above only matches users in the group > "rekanalar" on servers in the host group "rekanalarservers". Is > the user "user" in your example in that group and is the host > "server02-v2" in your example in that host group? Yes, usergroup `rekanalar` contain `user`, and `server02-v2` is member of `rekanalarservers` host group. But, if I assign `user` to usergroup `admins`, they can do sudo as root. The goal is, member of usergroup `rekanalar` can do all sudo command in hostgroup `rekanalarservers` only. [root at idm ~]# ipa user-show xxx User login: xxx First name: xxx Last name: [removed] Home directory: /home/xxx Login shell: /bin/bash Principal name: xxx at REALM Principal alias: xxx at REALM Email address: [REMOVED] UID: 1107600016 GID: 1107600016 Job Title: Rekanalar Director SSH public key fingerprint: 51:23:68:4B:BC:17:56:11:50:E1:72:B5:0C:00:B7:B6 xxx (ssh-rsa) Account disabled: False Password: False Member of groups: rekanalar Indirect Member of Sudo rule: sudo_rules_rekanalar Kerberos keys available: False [root at idm ~]# ipa group-show rekanalar Group name: rekanalar GID: 1107600017 Member users: xxx Member of Sudo rule: sudo_rules_rekanalar Am I miss something? > > Regards, > > j > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQI4BAEBCAAiBQJZA0sdGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcND0D/4gJ+MFRuaNX9vfuhZwtXnWGCTfhTZiwWBhp6yniAE1PvCvJ0cT 03kGLzNHTp/EPyysXK/oT8yei09B475UFERxfG2rCdY0AN9aCpOHjxQKgWWFw7LJ 3ntLQNoVEFBqpHoa7fbsBpXiKuonqnt0wV1qCNJKUF8z/62TgdsFUmrO7qjMvUbd FIBCQu2sCZ4Hx4duS8JpHgl9SJSGZkDRJN7XUpnd6bC2+zgUDfkAf74czwbjHQpb yitDmWslG+V3KpZDcbuMFLhNtwOVVavhhEqacqMoMkuEpSHtHk8oF0CvD/YhuiKv WUpzyDzLCx1u7xkRBTSRVRouzOi1WvEZ3JVnWSkFFExOW8SNWjpJhXF5ij4kBRF3 CRuKGys65SJA1HSUtH5eIPvXAYGxP+bJsoy72vyFZcy04+Jql9NRIHIMWZaZLe5Z +qdbhxpBxuCSua1ddMBnGUP/UAmGER0SsxbXq5k6ZjHo9PHwrOlxHZlPyHylbfLr Go1t2phtam410Rv8oMBB+6vO17QWduGZtBpXxSUXP+hvosE72FkLYnn5IOBIrKvC Z0GK1jLFDtMU79JECkjm/wfKywgq9XjcyodG6aMaD2iaVqSWhqfphBHm0nbSnEXz IpDT/WfK0uZkJUaIWYZ3dI7Iv9QCfwwVoWKaKjLkM9ReATti6ks/LYDz8Q== =TP6o -----END PGP SIGNATURE----- From pieter.baele at gmail.com Fri Apr 28 14:15:09 2017 From: pieter.baele at gmail.com (Pieter Baele) Date: Fri, 28 Apr 2017 14:15:09 +0000 Subject: [Freeipa-users] FreeIPA integration within enterprise AD domain - ca sub or root? Message-ID: Hi, We will start setting up IDM/FreeIPA for a specific linux subdomain in our enterprise. The part of setting up a trust is clear: we will be using an external trust - for a selected Active Directory domain But how can we best integrate with the enterprise CA infrastructure (MS Certificate Services)? Is it possible to deploy FreeIPA (dogtag) as rootCA, and to publish requests for public HTTPS certitificates by GlobalSign, or if internal, the MS Certificate Services rootCA? We can still use FreeIPA for all certificates where we need to encrypt end-to-end communication between servers (as example) What about the principle of an offline rootCA in that case? Or is there a specific reason that a subordinate CA is a better idea, signed by the root CA of the MS PKI infrastructure? And if we ask a subordinate CA, is it possible to limit exposure/risks? By setting some extensions? To conclude: own rootCA, or subordinate CA signed by the existing MS Certificate Services PKI???? Sincerely, Pieter Baele -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsullivan2 at bsd.uchicago.edu Fri Apr 28 14:54:44 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Fri, 28 Apr 2017 14:54:44 +0000 Subject: [Freeipa-users] Malformed representation of principal - krb5_child.log Message-ID: <39E73A82-E2AC-4E67-930A-1F62A388DC63@bsd.uchicago.edu> HI, I haven?t posted in a while, I hope everybody is doing well. I have a problem that I am having a difficult time diagnosing. To start, I want to say that we have a pretty large IPA environment. It generally works good. Most of our servers are of the same flavor RHEL6/7, and pull down their sssd/IPA RPMs from a standard repo. We also deploy sssd/ipa-client from SaltStack, so there?s not much variation on configuration. I have a client that is being very finicky, I am getting a message that says "Malformed representation of principal? in my krb5_child.log (when trying to log in). I?m really kind of an ends with the right way to troubleshoot this further. Here?s what I know; 1) I can kinit -k as root 2) I can kinit user at domain, even for the user in the sssd logs 3) I?ve blown away /var/lib/sss, deleted /etc/krb*, reinstalled sssd-common, sssd, & ipa-client. My logs are below. Would somebody be able to perhaps provide input on the best way to further troubleshoot this issue? (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0400): krb5_child started. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x1000): total buffer size: [174] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x0100): cmd [241] uid [339788572] gid [339788572] validate [true] enterprise principal [false] offline [false] UPN [user at domain@DOMAIN] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x2000): No old ccache (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_339788572_XXXXXX] old_ccname: [not set] keytab: [/etc/krb5.keytab] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.fqdn at DOMAIN] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/server.fqdn at DOMAIN in keytab. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [match_principal] (0x1000): Principal matched to the sample (host/server.fqdn at DOMAIN). (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [become_user] (0x0200): Trying to become user [339788572][339788572]. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x2000): Running as [339788572][339788572]. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup] (0x2000): Running as [339788572][339788572]. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup] (0x0020): 2529: [-1765328250][Malformed representation of principal] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0020): krb5_child_setup failed. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0020): krb5_child failed! (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [parse_krb5_child_response] (0x0020): message too short. (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [check_wait_queue] (0x1000): Wait queue for user [user at domain] is empty. (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22 (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid argument I appreciate your help with this. Thank you, Dan Sullivan From sbose at redhat.com Fri Apr 28 15:13:20 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 28 Apr 2017 17:13:20 +0200 Subject: [Freeipa-users] Malformed representation of principal - krb5_child.log In-Reply-To: <39E73A82-E2AC-4E67-930A-1F62A388DC63@bsd.uchicago.edu> References: <39E73A82-E2AC-4E67-930A-1F62A388DC63@bsd.uchicago.edu> Message-ID: <20170428151320.GM24587@p.Speedport_W_724V_Typ_A_05011603_00_011> On Fri, Apr 28, 2017 at 02:54:44PM +0000, Sullivan, Daniel [CRI] wrote: > HI, > > I haven?t posted in a while, I hope everybody is doing well. I have a problem that I am having a difficult time diagnosing. To start, I want to say that we have a pretty large IPA environment. It generally works good. Most of our servers are of the same flavor RHEL6/7, and pull down their sssd/IPA RPMs from a standard repo. We also deploy sssd/ipa-client from SaltStack, so there?s not much variation on configuration. I have a client that is being very finicky, I am getting a message that says "Malformed representation of principal? in my krb5_child.log (when trying to log in). I?m really kind of an ends with the right way to troubleshoot this further. Here?s what I know; > > 1) I can kinit -k as root > 2) I can kinit user at domain, even for the user in the sssd logs > 3) I?ve blown away /var/lib/sss, deleted /etc/krb*, reinstalled sssd-common, sssd, & ipa-client. > > My logs are below. Would somebody be able to perhaps provide input on the best way to further troubleshoot this issue? > > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0400): krb5_child started. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x1000): total buffer size: [174] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x0100): cmd [241] uid [339788572] gid [339788572] validate [true] enterprise principal [false] offline [false] UPN [user at domain@DOMAIN] There was an issue in an older version of SSSD which saved a wrong UPN in the cache. Please check if the latest version of SSSD for your platform installed, stop SSSD, remove the cache file in /var/lib/sss/db/, start SSSD and try again. If you do not want to remove the cache completely you can use e.g. ldbedit to delete the offending entry individually, search for user at domain@DOMAIN. HTH bye, Sumit > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x2000): No old ccache > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_339788572_XXXXXX] old_ccname: [not set] keytab: [/etc/krb5.keytab] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.fqdn at DOMAIN] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/server.fqdn at DOMAIN in keytab. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [match_principal] (0x1000): Principal matched to the sample (host/server.fqdn at DOMAIN). > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [become_user] (0x0200): Trying to become user [339788572][339788572]. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x2000): Running as [339788572][339788572]. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup] (0x2000): Running as [339788572][339788572]. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup] (0x0020): 2529: [-1765328250][Malformed representation of principal] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0020): krb5_child_setup failed. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0020): krb5_child failed! > > (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [read_pipe_handler] (0x0400): EOF received, client finished > (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [parse_krb5_child_response] (0x0020): message too short. > (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument > (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [check_wait_queue] (0x1000): Wait queue for user [user at domain] is empty. > (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22 > (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid argument > > I appreciate your help with this. > > Thank you, > > Dan Sullivan > > > -- > 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 Fri Apr 28 15:28:31 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Fri, 28 Apr 2017 15:28:31 +0000 Subject: [Freeipa-users] Malformed representation of principal - krb5_child.log In-Reply-To: <20170428151320.GM24587@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <39E73A82-E2AC-4E67-930A-1F62A388DC63@bsd.uchicago.edu> <20170428151320.GM24587@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: Hi, Sumit, Thank you for taking the time to respond to me. I tried that; it did not work. I am using sssd 1.14.0-3.el6. Any other support you (or anybody else) could provide would be greatly appreciated. Dan > On Apr 28, 2017, at 10:13 AM, Sumit Bose wrote: > > On Fri, Apr 28, 2017 at 02:54:44PM +0000, Sullivan, Daniel [CRI] wrote: >> HI, >> >> I haven?t posted in a while, I hope everybody is doing well. I have a problem that I am having a difficult time diagnosing. To start, I want to say that we have a pretty large IPA environment. It generally works good. Most of our servers are of the same flavor RHEL6/7, and pull down their sssd/IPA RPMs from a standard repo. We also deploy sssd/ipa-client from SaltStack, so there?s not much variation on configuration. I have a client that is being very finicky, I am getting a message that says "Malformed representation of principal? in my krb5_child.log (when trying to log in). I?m really kind of an ends with the right way to troubleshoot this further. Here?s what I know; >> >> 1) I can kinit -k as root >> 2) I can kinit user at domain, even for the user in the sssd logs >> 3) I?ve blown away /var/lib/sss, deleted /etc/krb*, reinstalled sssd-common, sssd, & ipa-client. >> >> My logs are below. Would somebody be able to perhaps provide input on the best way to further troubleshoot this issue? >> >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0400): krb5_child started. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x1000): total buffer size: [174] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x0100): cmd [241] uid [339788572] gid [339788572] validate [true] enterprise principal [false] offline [false] UPN [user at domain@DOMAIN] > > There was an issue in an older version of SSSD which saved a wrong UPN > in the cache. Please check if the latest version of SSSD for your > platform installed, stop SSSD, remove the cache file in > /var/lib/sss/db/, start SSSD and try again. > > If you do not want to remove the cache completely you can use e.g. > ldbedit to delete the offending entry individually, search for > user at domain@DOMAIN. > > HTH > > bye, > Sumit > >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x2000): No old ccache >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_339788572_XXXXXX] old_ccname: [not set] keytab: [/etc/krb5.keytab] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.fqdn at DOMAIN] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/server.fqdn at DOMAIN in keytab. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [match_principal] (0x1000): Principal matched to the sample (host/server.fqdn at DOMAIN). >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [become_user] (0x0200): Trying to become user [339788572][339788572]. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x2000): Running as [339788572][339788572]. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup] (0x2000): Running as [339788572][339788572]. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [k5c_setup] (0x0020): 2529: [-1765328250][Malformed representation of principal] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0020): krb5_child_setup failed. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722]]]] [main] (0x0020): krb5_child failed! >> >> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [read_pipe_handler] (0x0400): EOF received, client finished >> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [parse_krb5_child_response] (0x0020): message too short. >> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument >> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [check_wait_queue] (0x1000): Wait queue for user [user at domain] is empty. >> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22 >> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid argument >> >> I appreciate your help with this. >> >> Thank you, >> >> Dan Sullivan >> >> >> -- >> 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 Fri Apr 28 15:34:26 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 28 Apr 2017 17:34:26 +0200 Subject: [Freeipa-users] Malformed representation of principal - krb5_child.log In-Reply-To: References: <39E73A82-E2AC-4E67-930A-1F62A388DC63@bsd.uchicago.edu> <20170428151320.GM24587@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <20170428153426.lyrrtznnqb7bi2sv@hendrix> On Fri, Apr 28, 2017 at 03:28:31PM +0000, Sullivan, Daniel [CRI] wrote: > Hi, Sumit, > > Thank you for taking the time to respond to me. I tried that; it did not work. I am using sssd 1.14.0-3.el6. Any other support you (or anybody else) could provide would be greatly appreciated. Do you remember where did you install this RPM from? I don't think we ever released 1.14 for el6 via RHEL. (yum info sssd would tell you I think) From dsullivan2 at bsd.uchicago.edu Fri Apr 28 16:21:32 2017 From: dsullivan2 at bsd.uchicago.edu (Sullivan, Daniel [CRI]) Date: Fri, 28 Apr 2017 16:21:32 +0000 Subject: [Freeipa-users] Malformed representation of principal - krb5_child.log In-Reply-To: <20170428153426.lyrrtznnqb7bi2sv@hendrix> References: <39E73A82-E2AC-4E67-930A-1F62A388DC63@bsd.uchicago.edu> <20170428151320.GM24587@p.Speedport_W_724V_Typ_A_05011603_00_011> <20170428153426.lyrrtznnqb7bi2sv@hendrix> Message-ID: Jakub, Thank you for your email. We maintain our own repo that we populate from Copr; your question led me to realize that the repo was broken and this particular system was running an older version of sssd. I upgraded it to 1.14.2-2.el6 and the problem was resolved. Thank you Sumit and Jakub for your help. Have a nice weekend. Dan > On Apr 28, 2017, at 10:34 AM, Jakub Hrozek wrote: > > On Fri, Apr 28, 2017 at 03:28:31PM +0000, Sullivan, Daniel [CRI] wrote: >> Hi, Sumit, >> >> Thank you for taking the time to respond to me. I tried that; it did not work. I am using sssd 1.14.0-3.el6. Any other support you (or anybody else) could provide would be greatly appreciated. > > Do you remember where did you install this RPM from? I don't think we ever > released 1.14 for el6 via RHEL. > > (yum info sssd would tell you I think) > > -- > 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 Fri Apr 28 17:27:20 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Fri, 28 Apr 2017 19:27:20 +0200 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: References: <20170413150952.qyuinpdhij23bqpw@redhat.com> <20170413194406.j5paq2uldrmfpobm@redhat.com> <20170414082327.e72mrc4s7aaauqw7@redhat.com> <20170414120709.efhq6xpgf4746o6l@redhat.com> <20170414131352.lpy5ggt5lsne727j@redhat.com> Message-ID: Hello Alexander, list, I did get further by specifying --external=true in the ipa trust-add command, it works now for *both* the Windows and the Samba domain: ipa trust-add office.rdmedia.com --type=ad --admin Administrator --password --two-way=false --external=true IPA reports the trust is established successfully and I can also see it in Active Directory Domains and Trusts. However, adding users/groups to an external group fails: [root at ipa-ams-01 tiemen]# ipa group-add-member office_admins_external --external "OFFICE\domain admins" [member user]: [member group]: Group name: office_admins_external Description: office.rdmedia.com admins external map Failed members: member user: member group: *OFFICE\domain admins: trusted domain object not found* ------------------------- Number of members added 0 ------------------------- Of course that group exists on the Samba DC: [root at fluorine samba]# wbinfo -g OFFICE\cert publishers OFFICE\ras and ias servers OFFICE\allowed rodc password replication group OFFICE\denied rodc password replication group OFFICE\dnsadmins OFFICE\enterprise read-only domain controllers OFFICE\domain admins OFFICE\domain users OFFICE\domain guests OFFICE\domain computers OFFICE\domain controllers OFFICE\schema admins OFFICE\enterprise admins OFFICE\group policy creator owners OFFICE\read-only domain controllers OFFICE\dnsupdateproxy BTW, adding a two-way trust fails because the AD DC reports it can't contact any IPA server. Firewalls on all servers have been disabled. I would appreciate any insights! On 28 April 2017 at 12:09, Tiemen Ruiten wrote: > Hello, > > I set up a fresh Windows Server 2012R2 instance, configured a new forest > named 'clients.rdmedia.com' and I'm getting the same error in the httpd > error_log after running 'ipa trust-add clients.rdmedia.com --type=ad > --admin=Administrator --password': > > [Fri Apr 28 12:05:00.420174 2017] [:error] [pid 26417] ipa: ERROR: > non-public: RuntimeError: (-1073741811, 'Unexpected information received') > [Fri Apr 28 12:05:00.420225 2017] [:error] [pid 26417] Traceback (most > recent call last): > [Fri Apr 28 12:05:00.420230 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in > wsgi_execute > [Fri Apr 28 12:05:00.420235 2017] [:error] [pid 26417] result = > command(*args, **options) > [Fri Apr 28 12:05:00.420239 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in > __call__ > [Fri Apr 28 12:05:00.420243 2017] [:error] [pid 26417] return > self.__do_call(*args, **options) > [Fri Apr 28 12:05:00.420247 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in > __do_call > [Fri Apr 28 12:05:00.420251 2017] [:error] [pid 26417] ret = > self.run(*args, **options) > [Fri Apr 28 12:05:00.420255 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run > [Fri Apr 28 12:05:00.420258 2017] [:error] [pid 26417] return > self.execute(*args, **options) > [Fri Apr 28 12:05:00.420262 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 739, > in execute > [Fri Apr 28 12:05:00.420267 2017] [:error] [pid 26417] result = > self.execute_ad(full_join, *keys, **options) > [Fri Apr 28 12:05:00.420297 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 989, > in execute_ad > [Fri Apr 28 12:05:00.420304 2017] [:error] [pid 26417] trust_type > [Fri Apr 28 12:05:00.420308 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in > join_ad_full_credentials > [Fri Apr 28 12:05:00.420312 2017] [:error] [pid 26417] trust_type, > trust_external) > [Fri Apr 28 12:05:00.420316 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in > establish_trust > [Fri Apr 28 12:05:00.420320 2017] [:error] [pid 26417] > self.update_ftinfo(another_domain) > [Fri Apr 28 12:05:00.420324 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in > update_ftinfo > [Fri Apr 28 12:05:00.420328 2017] [:error] [pid 26417] ftinfo, 0) > [Fri Apr 28 12:05:00.420331 2017] [:error] [pid 26417] RuntimeError: > (-1073741811, 'Unexpected information received') > [Fri Apr 28 12:05:00.420975 2017] [:error] [pid 26417] ipa: INFO: > [jsonserver_session] admin at I.RDMEDIA.COM: trust_add/1(u'clients.rdmedia. > com', trust_type=u'ad', realm_admin=u'Administrator', > realm_passwd=u'********', version=u'2.213'): RuntimeError > > Am I doing something wrong? Logs are ofcourse available privately on > request. > > On 14 April 2017 at 15:13, Alexander Bokovoy wrote: > >> On pe, 14 huhti 2017, Tiemen Ruiten wrote: >> >>> Yes, office.rdmedia.com is the Samba AD domain. >>> >>> [root at fluorine samba]# samba-tool domain trust list >>> Type[Forest] Transitive[Yes] Direction[INCOMING] Name[i.rdmedia.com] >>> [root at fluorine samba]# samba-tool domain trust show i.rdmedia.com >>> LocalDomain Netbios[OFFICE] DNS[office.rdmedia.com] >>> SID[S-1-5-21-482924559-3201240232-3198541477] >>> TrusteDomain: >>> >>> NetbiosName: IPA >>> DnsName: i.rdmedia.com >>> SID: S-1-5-21-3716778977-2487905546-4034507762 >>> Type: 0x2 (UPLEVEL) >>> Direction: 0x1 (INBOUND) >>> Attributes: 0x8 (FOREST_TRANSITIVE) >>> PosixOffset: 0x00000000 (0) >>> kerb_EncTypes: 0x1c >>> (RC4_HMAC_MD5,AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96) >>> Namespaces[0] TDO[i.rdmedia.com]: >>> >> Ok, thanks. I'll look into this part of Samba code later, after Easter. >> >> >> >>> >>> On 14 April 2017 at 14:07, Alexander Bokovoy >>> wrote: >>> >>> On pe, 14 huhti 2017, Tiemen Ruiten wrote: >>>> >>>> Hello Alexander, >>>>> >>>>> That's strange, when I try to setup a trust with a domain that isn't a >>>>> subdomain of FreeIPA, I get the same error. I reran: >>>>> >>>>> ipa-adtrust-install --netbios-name=IPA >>>>> >>>>> and then ran: >>>>> >>>>> ipa trust-add --type=ad office.rdmedia.com --admin Administrator >>>>> --password >>>>> >>>>> office.rdmedia.com is Samba AD? >>>> >>>> Then please show output of >>>> >>>> samba-tool domain trust list >>>> >>>> and for each domain name in the output above show >>>> >>>> samba-tool domain trust show >>>> >>>> >>>> >>>> >>>> >>>> Last bit of the error_log: >>>>> >>>>> rpc reply data: >>>>> [0000] 00 00 00 00 .... >>>>> lsa_lsaRSetForestTrustInformation: struct >>>>> lsa_lsaRSetForestTrustInformation >>>>> in: struct lsa_lsaRSetForestTrustInformation >>>>> handle : * >>>>> handle: struct policy_handle >>>>> handle_type : 0x00000000 (0) >>>>> uuid : >>>>> 43cfa5e6-c10a-49a5-9b75-f7284ee44aac >>>>> trusted_domain_name : * >>>>> trusted_domain_name: struct lsa_StringLarge >>>>> length : 0x001a (26) >>>>> size : 0x001c (28) >>>>> string : * >>>>> string : 'i.rdmedia.com' >>>>> highest_record_type : LSA_FOREST_TRUST_DOMAIN_INFO (2) >>>>> forest_trust_info : * >>>>> forest_trust_info: struct lsa_ForestTrustInformation >>>>> count : 0x00000004 (4) >>>>> entries : * >>>>> entries: ARRAY(4) >>>>> entries : * >>>>> entries: struct lsa_ForestTrustRecord >>>>> flags : >>>>> 0x00000000 >>>>> (0) >>>>> 0: LSA_TLN_DISABLED_NEW >>>>> 0: LSA_TLN_DISABLED_ADMIN >>>>> 0: LSA_TLN_DISABLED_CONFLICT >>>>> 0: LSA_SID_DISABLED_ADMIN >>>>> 0: LSA_SID_DISABLED_CONFLICT >>>>> 0: LSA_NB_DISABLED_ADMIN >>>>> 0: LSA_NB_DISABLED_CONFLICT >>>>> type : >>>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>>> time : Mon Apr >>>>> 10 >>>>> 08:43:18 2017 CEST >>>>> forest_trust_data : union >>>>> lsa_ForestTrustData(case 0) >>>>> top_level_name: struct >>>>> lsa_StringLarge >>>>> length : >>>>> 0x002c >>>>> (44) >>>>> size : >>>>> 0x002e >>>>> (46) >>>>> string : * >>>>> string : ' >>>>> test.ams.i.rdmedia.com' >>>>> entries : * >>>>> entries: struct lsa_ForestTrustRecord >>>>> flags : >>>>> 0x00000000 >>>>> (0) >>>>> 0: LSA_TLN_DISABLED_NEW >>>>> 0: LSA_TLN_DISABLED_ADMIN >>>>> 0: LSA_TLN_DISABLED_CONFLICT >>>>> 0: LSA_SID_DISABLED_ADMIN >>>>> 0: LSA_SID_DISABLED_CONFLICT >>>>> 0: LSA_NB_DISABLED_ADMIN >>>>> 0: LSA_NB_DISABLED_CONFLICT >>>>> type : >>>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>>> time : Mon Apr >>>>> 10 >>>>> 08:43:18 2017 CEST >>>>> forest_trust_data : union >>>>> lsa_ForestTrustData(case 0) >>>>> top_level_name: struct >>>>> lsa_StringLarge >>>>> length : >>>>> 0x002c >>>>> (44) >>>>> size : >>>>> 0x002e >>>>> (46) >>>>> string : * >>>>> string : ' >>>>> prod.ams.i.rdmedia.com' >>>>> entries : * >>>>> entries: struct lsa_ForestTrustRecord >>>>> flags : >>>>> 0x00000000 >>>>> (0) >>>>> 0: LSA_TLN_DISABLED_NEW >>>>> 0: LSA_TLN_DISABLED_ADMIN >>>>> 0: LSA_TLN_DISABLED_CONFLICT >>>>> 0: LSA_SID_DISABLED_ADMIN >>>>> 0: LSA_SID_DISABLED_CONFLICT >>>>> 0: LSA_NB_DISABLED_ADMIN >>>>> 0: LSA_NB_DISABLED_CONFLICT >>>>> type : >>>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>>> time : Mon Apr >>>>> 10 >>>>> 08:43:18 2017 CEST >>>>> forest_trust_data : union >>>>> lsa_ForestTrustData(case 0) >>>>> top_level_name: struct >>>>> lsa_StringLarge >>>>> length : >>>>> 0x001a >>>>> (26) >>>>> size : >>>>> 0x001c >>>>> (28) >>>>> string : * >>>>> string : ' >>>>> i.rdmedia.com' >>>>> entries : * >>>>> entries: struct lsa_ForestTrustRecord >>>>> flags : >>>>> 0x00000000 >>>>> (0) >>>>> 0: LSA_TLN_DISABLED_NEW >>>>> 0: LSA_TLN_DISABLED_ADMIN >>>>> 0: LSA_TLN_DISABLED_CONFLICT >>>>> 0: LSA_SID_DISABLED_ADMIN >>>>> 0: LSA_SID_DISABLED_CONFLICT >>>>> 0: LSA_NB_DISABLED_ADMIN >>>>> 0: LSA_NB_DISABLED_CONFLICT >>>>> type : >>>>> LSA_FOREST_TRUST_TOP_LEVEL_NAME (0) >>>>> time : Mon Apr >>>>> 10 >>>>> 08:43:18 2017 CEST >>>>> forest_trust_data : union >>>>> lsa_ForestTrustData(case 0) >>>>> top_level_name: struct >>>>> lsa_StringLarge >>>>> length : >>>>> 0x002c >>>>> (44) >>>>> size : >>>>> 0x002e >>>>> (46) >>>>> string : * >>>>> string : ' >>>>> prod.nyc.i.rdmedia.com' >>>>> check_only : 0x00 (0) >>>>> rpc request data: >>>>> [0000] 00 00 00 00 E6 A5 CF 43 0A C1 A5 49 9B 75 F7 28 .......C >>>>> ...I.u.( >>>>> [0010] 4E E4 4A AC 1A 00 1C 00 00 00 02 00 0E 00 00 00 N.J..... >>>>> ........ >>>>> [0020] 00 00 00 00 0D 00 00 00 69 00 2E 00 72 00 64 00 ........ >>>>> i...r.d. >>>>> [0030] 6D 00 65 00 64 00 69 00 61 00 2E 00 63 00 6F 00 m.e.d.i. >>>>> a...c.o. >>>>> [0040] 6D 00 02 00 04 00 00 00 04 00 02 00 04 00 00 00 m....... >>>>> ........ >>>>> [0050] 08 00 02 00 0C 00 02 00 10 00 02 00 14 00 02 00 ........ >>>>> ........ >>>>> [0060] 00 00 00 00 00 00 00 00 00 C7 B7 BC C5 B1 D2 01 ........ >>>>> ........ >>>>> [0070] 00 00 00 00 2C 00 2E 00 18 00 02 00 17 00 00 00 ....,... >>>>> ........ >>>>> [0080] 00 00 00 00 16 00 00 00 74 00 65 00 73 00 74 00 ........ >>>>> t.e.s.t. >>>>> [0090] 2E 00 61 00 6D 00 73 00 2E 00 69 00 2E 00 72 00 ..a.m.s. >>>>> ..i...r. >>>>> [00A0] 64 00 6D 00 65 00 64 00 69 00 61 00 2E 00 63 00 d.m.e.d. >>>>> i.a...c. >>>>> [00B0] 6F 00 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 o.m..... >>>>> ........ >>>>> [00C0] 00 C7 B7 BC C5 B1 D2 01 00 00 00 00 2C 00 2E 00 ........ >>>>> ....,... >>>>> [00D0] 1C 00 02 00 17 00 00 00 00 00 00 00 16 00 00 00 ........ >>>>> ........ >>>>> [00E0] 70 00 72 00 6F 00 64 00 2E 00 61 00 6D 00 73 00 p.r.o.d. >>>>> ..a.m.s. >>>>> [00F0] 2E 00 69 00 2E 00 72 00 64 00 6D 00 65 00 64 00 ..i...r. >>>>> d.m.e.d. >>>>> [0100] 69 00 61 00 2E 00 63 00 6F 00 6D 00 00 00 00 00 i.a...c. >>>>> o.m..... >>>>> [0110] 00 00 00 00 00 00 00 00 00 C7 B7 BC C5 B1 D2 01 ........ >>>>> ........ >>>>> [0120] 00 00 00 00 1A 00 1C 00 20 00 02 00 0E 00 00 00 ........ >>>>> ....... >>>>> [0130] 00 00 00 00 0D 00 00 00 69 00 2E 00 72 00 64 00 ........ >>>>> i...r.d. >>>>> [0140] 6D 00 65 00 64 00 69 00 61 00 2E 00 63 00 6F 00 m.e.d.i. >>>>> a...c.o. >>>>> [0150] 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 m....... >>>>> ........ >>>>> [0160] 00 C7 B7 BC C5 B1 D2 01 00 00 00 00 2C 00 2E 00 ........ >>>>> ....,... >>>>> [0170] 24 00 02 00 17 00 00 00 00 00 00 00 16 00 00 00 $....... >>>>> ........ >>>>> [0180] 70 00 72 00 6F 00 64 00 2E 00 6E 00 79 00 63 00 p.r.o.d. >>>>> ..n.y.c. >>>>> [0190] 2E 00 69 00 2E 00 72 00 64 00 6D 00 65 00 64 00 ..i...r. >>>>> d.m.e.d. >>>>> [01A0] 69 00 61 00 2E 00 63 00 6F 00 6D 00 00 i.a...c. >>>>> o.m.. >>>>> signed SMB2 message >>>>> lsa_lsaRSetForestTrustInformation: struct >>>>> lsa_lsaRSetForestTrustInformation >>>>> out: struct lsa_lsaRSetForestTrustInformation >>>>> collision_info : * >>>>> collision_info : NULL >>>>> result : NT_STATUS_INVALID_PARAMETER >>>>> rpc reply data: >>>>> [0000] 00 00 00 00 0D 00 00 C0 ........ >>>>> [Fri Apr 14 13:05:15.626311 2017] [:error] [pid 22596] ipa: ERROR: >>>>> non-public: RuntimeError: (-1073741811, 'Unexpected information >>>>> received') >>>>> [Fri Apr 14 13:05:15.626384 2017] [:error] [pid 22596] Traceback (most >>>>> recent call last): >>>>> [Fri Apr 14 13:05:15.626392 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, >>>>> in >>>>> wsgi_execute >>>>> [Fri Apr 14 13:05:15.626399 2017] [:error] [pid 22596] result = >>>>> command(*args, **options) >>>>> [Fri Apr 14 13:05:15.626405 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in >>>>> __call__ >>>>> [Fri Apr 14 13:05:15.626416 2017] [:error] [pid 22596] return >>>>> self.__do_call(*args, **options) >>>>> [Fri Apr 14 13:05:15.626422 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in >>>>> __do_call >>>>> [Fri Apr 14 13:05:15.626428 2017] [:error] [pid 22596] ret = >>>>> self.run(*args, **options) >>>>> [Fri Apr 14 13:05:15.626434 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in >>>>> run >>>>> [Fri Apr 14 13:05:15.626439 2017] [:error] [pid 22596] return >>>>> self.execute(*args, **options) >>>>> [Fri Apr 14 13:05:15.626445 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line >>>>> 739, >>>>> in >>>>> execute >>>>> [Fri Apr 14 13:05:15.626451 2017] [:error] [pid 22596] result = >>>>> self.execute_ad(full_join, *keys, **options) >>>>> [Fri Apr 14 13:05:15.626457 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line >>>>> 989, >>>>> in >>>>> execute_ad >>>>> [Fri Apr 14 13:05:15.626463 2017] [:error] [pid 22596] trust_type >>>>> [Fri Apr 14 13:05:15.626468 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in >>>>> join_ad_full_credentials >>>>> [Fri Apr 14 13:05:15.626474 2017] [:error] [pid 22596] trust_type, >>>>> trust_external) >>>>> [Fri Apr 14 13:05:15.626479 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in >>>>> establish_trust >>>>> [Fri Apr 14 13:05:15.626485 2017] [:error] [pid 22596] >>>>> self.update_ftinfo(another_domain) >>>>> [Fri Apr 14 13:05:15.626490 2017] [:error] [pid 22596] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in >>>>> update_ftinfo >>>>> [Fri Apr 14 13:05:15.626495 2017] [:error] [pid 22596] ftinfo, 0) >>>>> [Fri Apr 14 13:05:15.626500 2017] [:error] [pid 22596] RuntimeError: >>>>> (-1073741811, 'Unexpected information received') >>>>> [Fri Apr 14 13:05:15.627265 2017] [:error] [pid 22596] ipa: INFO: >>>>> [jsonserver_session] admin at I.RDMEDIA.COM: >>>>> trust_add/1(u'office.rdmedia.c >>>>> om', >>>>> trust_type=u'ad', realm_admin=u'Administrator', >>>>> realm_passwd=u'********', >>>>> version=u'2.213'): RuntimeError >>>>> >>>>> >>>>> >>>>> On 14 April 2017 at 10:23, Alexander Bokovoy >>>>> wrote: >>>>> >>>>> On to, 13 huhti 2017, Alexander Bokovoy wrote: >>>>> >>>>>> >>>>>> On Thu, 13 Apr 2017, Tiemen Ruiten wrote: >>>>>> >>>>>>> >>>>>>> Excerpt from the httpd error_log on the FreeIPA replica: >>>>>>> >>>>>>>> >>>>>>>> [Thu Apr 13 11:17:44.072996 2017] [:error] [pid 28346] ipa: INFO: >>>>>>>> [jsonserver_kerb] admin at I.RDMEDIA.COM: ping(): SUCCESS >>>>>>>> [Thu Apr 13 11:17:50.708019 2017] [:error] [pid 28347] ipa: ERROR: >>>>>>>> non-public: RuntimeError: (-1073741811, 'Unexpected information >>>>>>>> received') >>>>>>>> >>>>>>>> Please add 'log level = 10' to /usr/share/ipa/smb.conf.empty and >>>>>>>> re-try >>>>>>>> >>>>>>> 'ipa trust-add', then send me resulting error_log privately. >>>>>>> >>>>>>> To get back to the public mailing list, Tiemen sent me logs and I >>>>>>> >>>>>> confirm that this is the same as https://bugzilla.redhat.com/sh >>>>>> ow_bug.cgi?id=1421869 >>>>>> >>>>>> We currently have no solution to this problem (AD is subdomain of IPA >>>>>> domain). >>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Tiemen Ruiten >>>>> Systems Engineer >>>>> R&D Media >>>>> >>>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> >>> -- >>> Tiemen Ruiten >>> Systems Engineer >>> R&D Media >>> >> >> -- >> / Alexander Bokovoy >> > > > > -- > Tiemen Ruiten > Systems Engineer > R&D Media > -- Tiemen Ruiten Systems Engineer R&D Media -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri Apr 28 17:28:13 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 28 Apr 2017 19:28:13 +0200 Subject: [Freeipa-users] Malformed representation of principal - krb5_child.log In-Reply-To: References: <39E73A82-E2AC-4E67-930A-1F62A388DC63@bsd.uchicago.edu> <20170428151320.GM24587@p.Speedport_W_724V_Typ_A_05011603_00_011> <20170428153426.lyrrtznnqb7bi2sv@hendrix> Message-ID: <20170428172812.GE25002@10.4.128.1> On (28/04/17 16:21), Sullivan, Daniel [CRI] wrote: >Jakub, > >Thank you for your email. We maintain our own repo that we populate from Copr; your question led me to realize that the repo was broken and this particular system was running an older version of sssd. I upgraded it to 1.14.2-2.el6 and the problem was resolved. Thank you Sumit and Jakub for your help. Have a nice weekend. > Do you really maintain own copr? Or do you use https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/ I am just curious :-) LS From jhrozek at redhat.com Fri Apr 28 18:34:06 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 28 Apr 2017 20:34:06 +0200 Subject: [Freeipa-users] add trust between FreeIPA and Samba AD DC In-Reply-To: References: <20170413194406.j5paq2uldrmfpobm@redhat.com> <20170414082327.e72mrc4s7aaauqw7@redhat.com> <20170414120709.efhq6xpgf4746o6l@redhat.com> <20170414131352.lpy5ggt5lsne727j@redhat.com> Message-ID: <20170428183406.mdscr5276drecrpf@hendrix> On Fri, Apr 28, 2017 at 07:27:20PM +0200, Tiemen Ruiten wrote: > Hello Alexander, list, > > I did get further by specifying --external=true in the ipa trust-add > command, it works now for *both* the Windows and the Samba domain: > > ipa trust-add office.rdmedia.com --type=ad --admin Administrator --password > --two-way=false --external=true > > IPA reports the trust is established successfully and I can also see it in > Active Directory Domains and Trusts. However, adding users/groups to an > external group fails: > > [root at ipa-ams-01 tiemen]# ipa group-add-member office_admins_external > --external "OFFICE\domain admins" > [member user]: > [member group]: > Group name: office_admins_external > Description: office.rdmedia.com admins external map > Failed members: > member user: > member group: *OFFICE\domain admins: trusted domain object not found* > ------------------------- > Number of members added 0 > ------------------------- Domain Admins is a domain-local group typically. I would advise against using those for cross-forest trust memberships in general. Can you also check if you can resolve objects from the trusted AD/Samba domain? Try: getent passwd administrator at office.rdmedia.com for example. From abokovoy at redhat.com Fri Apr 28 20:46:16 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Apr 2017 23:46:16 +0300 Subject: [Freeipa-users] Blog post: Debugging FreeIPA 4.5 privilege separation code Message-ID: <20170428204616.rwrattuiuwcsfvzm@redhat.com> Hi, Simo and I wrote an article on how to debug FreeIPA 4.5 privilege separation code. It is not about debugging, in fact, but on where to look for various types of logs and how to interpret them. The article also provides a high level explanation of how privilege separation in FreeIPA works and what it allows us to achieve. You can read the article here: https://vda.li/en/docs/freeipa-debug-privsep/ -- / Alexander Bokovoy From raje at gworks.mobi Fri Apr 28 05:11:29 2017 From: raje at gworks.mobi (rajkumar) Date: Fri, 28 Apr 2017 10:41:29 +0530 Subject: [Freeipa-users] how to setup freeipa project to local environment Message-ID: <7a5d9354-cb5f-fc36-ab08-e7b1ef84dcc4@gworks.mobi> Hello freeipa team, I have download freeipa4.4.4.tar.gz and I need to setup freeipa project as a local environment(to customize via IDE like eclipse) for customization. suggest me how can do that. or any reference link. Thanks, -- Regards, Rajkumar E raje at gworks.mobi 8675496254.