[Freeipa-users] Thank You!
IPA/SSSD developers - I'm writing to give everyone involved in the IPA and sssd projects a big "Thank You". I've been poking at IPA for a little over 4 years now, looking to migrate away from our 389ds LDAP configuration. There have been lots of hurdles to jump, bugs to fix, as well as a complete change of direction (from migrating users to moving to an AD trust). Along the way I have received a huge amount of assistance from a large group of incredibly helpful people, including (but not limited to) Jakub Hrozek, Lukas Slebodnik, Simo Sorce, Pavel Březina, Nalin Dahyabhai, Rob Crittenden. My apologies if I left anyone out. I have two machines left to convert to IPA and can hardly believe sometimes that I've finally arrived at this point. So, thanks again for everyone for their work on this incredibly complex and critical set of software. - Orion -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] subdomain errors
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=u...@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=u...@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=u...@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=u...@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: 2 Number of IDs in the range: 2 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: 1 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 or...@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
Re: [Freeipa-users] subdomain errors
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=u...@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=u...@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=u...@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=u...@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=u...@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=u...@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=u...@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
Re: [Freeipa-users] ipa_add_ad_memberships_get_next errors
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=n...@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-us...@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 or...@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
[Freeipa-users] subdomain errors
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=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb (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=u...@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=u...@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]]] [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=u...@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=u...@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=u...@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
[Freeipa-users] ipa_add_ad_memberships_get_next errors
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=n...@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]. (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 or...@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
Re: [Freeipa-users] sudo sometimes doesn't work
On 01/30/2017 01:38 AM, Jakub Hrozek wrote: > On Fri, Jan 27, 2017 at 02:15:16PM -0700, Orion Poplawski wrote: >> EL7.3 >> Users are in active directory via AD trust with IPA server >> >> sudo is configured via files - users in our default "nwra" group can run >> certain sudo commands, e.g.: >> >> Cmnd_Alias WAKEUP = /sbin/ether-wake * >> %nwra,%visitor,%ivm ALL=NOPASSWD: WAKEUP >> >> However, sometimes when I run sudo /sbin/ether-wake I get prompted for my >> password. Other times it works fine. I've attached some logs from failed >> attempt. > > So the sudo command is successfull in the end, it 'just' prompts for a > password? No, it fails when given the password: Sorry, user USER is not allowed to execute '/sbin/ether-wake XXX' as root on HOST. Turns out I'm an idiot. Needed to run ipa-adtrust-install on all of the IPA servers and make sure things were working on all of them. Things would break depending on which ipa server the client sssd was connected to. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] Add host to hostgroup in ipa-client-add
On 03/10/2017 10:52 PM, Alexander Bokovoy wrote: > On pe, 10 maalis 2017, Orion Poplawski wrote: >> I'm using ipa-client-add with --unattended and a OTP to enroll machines at >> install time. I'd like to be able to add them to a particular hostgroup at >> the same time to avoid having to do that manually later. Does this seem like >> a reasonable RFE? Or is there some other way to handle this? > Use automember rules: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/automember.html Interesting but I don't think this will help me. After thinking about this a bit more, since I need to add the host anyway to set the OTP, I just added setting group membership to that script as well. Thanks for the info though. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
[Freeipa-users] Add host to hostgroup in ipa-client-add
I'm using ipa-client-add with --unattended and a OTP to enroll machines at install time. I'd like to be able to add them to a particular hostgroup at the same time to avoid having to do that manually later. Does this seem like a reasonable RFE? Or is there some other way to handle this? Thanks - Orion -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] documentation or example of using S42U for NFS
If you ever get this into a repository, I'd love to see it. Thanks. On 01/17/2017 07:44 PM, Charles Hedrick wrote: > Instructions like that are several places. But NFS is different, and I > believe the configuration would be different from other services. > > I’ve given up on this approach, and have written my own utilities. I’ve > actually got three. The first two assume that users who want to do cron jobs > on a machine register a keytab for that machine on a secure system. I don’t > want to put the actual keytab on the machine where the user is running, > because if someone can become root, they can take the keytab and use it > anywhere. (I’m in a computer science dept with systems run by faculty and > grad students; also systems in public labs.) > > So instead, I allow users to register that they want to do cron on a specific > machine by putting a keytab on a secure server, associated with their > username and the hostname. I expect to write a web app to set that up. > > Credserv runs on the machine with the keytabs. It accepts a request from a > server, authenticated using the host’s host key (i.e. /etc/krb5.keytab), with > a username in the request. If the user has registered a keytab for that host, > credserv returns a credential, locked to that IP address, with forwarding > off. > > Kgetcred is the client side. It runs setuid root (so it can read > /etc/krb5.keytab), though it drops privs as quickly as possible. It creates a > credentials cache for the user from the credentials returned from credserv. > > This gives the best granularity of control I can come up with. > > There’s a third utility in the family: renewd. It gets the uids of all > current processes, and renews credentials for all of the users. It’s more > complex than you’d expect because a normal renewal (as in kinit -R or kstart) > leaves a brief period of time when the credentials cache is unusable. This > can result in NFS failing. I use a special approach that depends upon the > details of the KEYRING implementation. It should be free of race conditions > for NFS. If desired, a different approach to avoid race conditions could be > used for caches located in /tmp. I haven’t written that code but there’s a > comment in the source outlining it. > > I’ll be creating a git repository for the code. > > >> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski <or...@cora.nwra.com> wrote: >> >> On 01/09/2017 09:52 AM, Charles Hedrick wrote: >>> Various documentation suggests that it is possible for Gssproxy to get >>> tickets for users who need to use NFS. This is a possible way to handle >>> things like cron jobs. >>> >>> However while a gssproxy.conf example is given, there’s no sign of what >>> needs to be done in freeipa to authorize it. I tried following instructions >>> for LDAP access, but it doesn’t work. NFS seems to use a different, >>> two-stage method for getting credentials, so that’s not a surprise. There >>> are, not surprisingly, no useful error messages even with logging turned >>> all the way up. >>> >>> >> >> I'm interested in this as well. All I've been able to find so far is: >> >> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ >> >> haven't tried anything. >> >> -- >> Orion Poplawski >> Technical Manager 720-772-5637 >> NWRA, Boulder/CoRA Office FAX: 303-415-9702 >> 3380 Mitchell Lane or...@nwra.com >> Boulder, CO 80301 http://www.nwra.com > -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
[Freeipa-users] sudo sometimes doesn't work
EL7.3 Users are in active directory via AD trust with IPA server sudo is configured via files - users in our default "nwra" group can run certain sudo commands, e.g.: Cmnd_Alias WAKEUP = /sbin/ether-wake * %nwra,%visitor,%ivm ALL=NOPASSWD: WAKEUP However, sometimes when I run sudo /sbin/ether-wake I get prompted for my password. Other times it works fine. I've attached some logs from failed attempt. In particular, these entries: -barry.cora.DNSDOMAIN sssd_be[701]: Got request with the following data -barry.cora.DNSDOMAIN sssd_be[701]: command: SSS_PAM_PREAUTH -barry.cora.DNSDOMAIN sssd_be[701]: domain: ad.DNSDOMAIN -barry.cora.DNSDOMAIN sssd_be[701]: user: USER@ad.DNSDOMAIN -barry.cora.DNSDOMAIN sssd_be[701]: service: sudo -barry.cora.DNSDOMAIN sssd_be[701]: tty: /dev/pts/0 -barry.cora.DNSDOMAIN sssd_be[701]: ruser: USER -barry.cora.DNSDOMAIN sssd_be[701]: rhost: -barry.cora.DNSDOMAIN sssd_be[701]: authtok type: 0 -barry.cora.DNSDOMAIN sssd_be[701]: newauthtok type: 0 -barry.cora.DNSDOMAIN sssd_be[701]: priv: 0 -barry.cora.DNSDOMAIN sssd_be[701]: cli_pid: 2860 -barry.cora.DNSDOMAIN sssd_be[701]: logon name: not set -barry.cora.DNSDOMAIN sssd_be[701]: Trying to resolve service 'IPA' -barry.cora.DNSDOMAIN sssd_be[701]: The status of SRV lookup is resolved -barry.cora.DNSDOMAIN sssd_be[701]: Found address for server ipa1.DNSDOMAIN: [10.0.1.74] TTL 86400 -barry.cora.DNSDOMAIN krb5_child[2869]: cmd [249] uid [22603] gid [22603] validate [true] enterprise principal [false] offline [false] UPN [u...@ad.nwra.com] -barry.cora.DNSDOMAIN krb5_child[2869]: SSSD_KRB5_FAST_PRINCIPAL is set to [host/barry.cora.dnsdom...@nwra.com] -barry.cora.DNSDOMAIN krb5_child[2869]: FAST TGT is still valid. -barry.cora.DNSDOMAIN krb5_child[2869]: Trying to become user [22603][22603]. -barry.cora.DNSDOMAIN krb5_child[2869]: Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. -barry.cora.DNSDOMAIN krb5_child[2869]: Cannot read [SSSD_KRB5_LIFETIME] from environment. -barry.cora.DNSDOMAIN krb5_child[2869]: SSSD_KRB5_CANONICALIZE is set to [true] -barry.cora.DNSDOMAIN krb5_child[2869]: Cannot handle password prompts. -barry.cora.DNSDOMAIN krb5_child[2869]: Received error code 0 -barry.cora.DNSDOMAIN sssd_be[701]: child [2869] finished successfully. -barry.cora.DNSDOMAIN sssd_be[701]: Marking port 389 of server 'ipa1.DNSDOMAIN' as 'working' -barry.cora.DNSDOMAIN sssd_be[701]: Marking server 'ipa1.DNSDOMAIN' as 'working' -barry.cora.DNSDOMAIN sssd_be[701]: connection is about to expire, releasing it -barry.cora.DNSDOMAIN sssd_be[701]: Trying to resolve service 'IPA' -barry.cora.DNSDOMAIN sssd_be[701]: The status of SRV lookup is resolved -barry.cora.DNSDOMAIN sssd_be[701]: Found address for server ipa1.DNSDOMAIN: [10.0.1.74] TTL 86400 -barry.cora.DNSDOMAIN sssd_be[701]: Trying to resolve service 'IPA' -barry.cora.DNSDOMAIN sssd_be[701]: The status of SRV lookup is resolved -barry.cora.DNSDOMAIN sssd_be[701]: Found address for server ipa1.DNSDOMAIN: [10.0.1.74] TTL 86400 -barry.cora.DNSDOMAIN ldap_child[2889]: Will run as [0][0]. -barry.cora.DNSDOMAIN ldap_child[2889]: Trying to become user [0][0]. -barry.cora.DNSDOMAIN ldap_child[2889]: Already user [0]. -barry.cora.DNSDOMAIN ldap_child[2889]: Principal name is: [host/barry.cora.dnsdom...@nwra.com] -barry.cora.DNSDOMAIN ldap_child[2889]: Using keytab [MEMORY:/etc/krb5.keytab] -barry.cora.DNSDOMAIN ldap_child[2889]: Will canonicalize principals -barry.cora.DNSDOMAIN sssd_be[701]: GSSAPI client step 1 -barry.cora.DNSDOMAIN sssd_be[701]: expire timeout is 900 -barry.cora.DNSDOMAIN sssd_be[701]: GSSAPI client step 1 -barry.cora.DNSDOMAIN sssd_be[701]: Executing sasl bind mech: GSSAPI, user: host/barry.cora.DNSDOMAIN -barry.cora.DNSDOMAIN sssd_be[701]: GSSAPI client step 1 -barry.cora.DNSDOMAIN sssd_be[701]: GSSAPI client step 2 -barry.cora.DNSDOMAIN sssd_be[701]: child [2889] finished successfully. -barry.cora.DNSDOMAIN sssd_be[701]: Marking port 389 of server 'ipa1.DNSDOMAIN' as 'working' -barry.cora.DNSDOMAIN sssd_be[701]: Marking server 'ipa1.DNSDOMAIN' as 'working' -barry.cora.DNSDOMAIN sssd_be[701]: No host groups were dereferenced -barry.cora.DNSDOMAIN sssd_be[701]: Received 0 additional command groups -barry.cora.DNSDOMAIN sssd_be[701]: Received 0 sudo rules -barry.cora.DNSDOMAIN sssd_be[701]: SUDO higher USN value: [1] -barry.cora.DNSDOMAIN sudo[2860]:USER : command not allowed ; TTY=pts/0 ; PWD=/export/home/USER/fedora/fail2ban ; USER=root ; COMMAND=/sbin/ether-wake -i eth0 00:25:64:e0:05:fa seem to appear in the failed attempt but not a successful one. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com Jan 27 13:25:43 barry.cora.DNSDOMAIN sssd_sudo[772]: Received client version [1]. Jan 27 13:25:43 barry.cora.DNSDOMAIN sssd_sudo[772]: Offered version [1]. Jan 2
Re: [Freeipa-users] documentation or example of using S42U for NFS
On 01/09/2017 09:52 AM, Charles Hedrick wrote: > Various documentation suggests that it is possible for Gssproxy to get > tickets for users who need to use NFS. This is a possible way to handle > things like cron jobs. > > However while a gssproxy.conf example is given, there’s no sign of what needs > to be done in freeipa to authorize it. I tried following instructions for > LDAP access, but it doesn’t work. NFS seems to use a different, two-stage > method for getting credentials, so that’s not a surprise. There are, not > surprisingly, no useful error messages even with logging turned all the way > up. > > I'm interested in this as well. All I've been able to find so far is: https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ haven't tried anything. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
[Freeipa-users] HBAC rules stop working
server: ipa-server-4.2.0-15.sl7_2.19.x86_64 sssd-1.13.0-40.el7_2.12.x86_64 client: sssd-1.14.1-3.el7.centos.x86_64 AD trust - users are in AD. HBAC rule in place for client to allow a user to login/ssh/su/etc. This seems to have happened a couple times now, and again today after rebooting the IPA server. sssd was denying the user to ssh into the client by pam rules. Logged on to the IPA server and disabled and then re-enabled the HBAC rule for the client and then was able to log back in again. Has anyone else seen this before? client sssd_pam just went from: (Thu Sep 29 19:30:40 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]: Permission denied. to (Thu Sep 29 19:37:04 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. so I assume I'll need to collect debug logs from sssd on the server next time. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.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
Re: [Freeipa-users] Default gid for AD trust users
On 09/02/2016 03:15 PM, Lukas Slebodnik wrote: On (24/08/16 11:42), Orion Poplawski wrote: While that is definitely *a* convention, it's not the one we've used which puts users by default in shared groups (nwra, visitors, etc). For example: uid=2941(user) gid=1991(nwra) The user "user" should be a member "nwra" group. If no then you have other issues. Why does it matter whether it is a primary group or no? LS Because that is the default group ownership of files created by the user. Yes, they can change it, and yes you can use setgid directories, but it is the default. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.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
Re: [Freeipa-users] Default gid for AD trust users
FWIW - I've filed https://fedorahosted.org/freeipa/ticket/6293 to request the ability to set the primary group for AD trust users. On 08/24/2016 11:42 AM, Orion Poplawski wrote: > While that is definitely *a* convention, it's not the one we've used which > puts users by default in shared groups (nwra, visitors, etc). For example: > > uid=2941(user) gid=1991(nwra) > > We may be fine changing conventions, but I'm researching whether or not we > have to. > > Thanks. > > On 08/24/2016 11:19 AM, Justin Stephenson wrote: >> Could you please explain further what you are trying to accomplish with an AD >> trust default group? I believe we are following the standard linux convention >> of creating a user private group using the ID number which matches the uid >> number for AD trust users. >> >> Kind regards, >> >> Justin Stephenson >> >> >> On 08/23/2016 06:27 PM, Orion Poplawski wrote: >>> Is there any way to control the default gid for AD trust users? At the >>> moment >>> each user has it's own default group, e.g.: >>> >>> uid=22603(user@ad.domain) gid=22603(user@ad.domain) >>> >>> It would be nice to be able to set this to an actual group. >>> >>> Thanks. >>> >> > > -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] Default gid for AD trust users
While that is definitely *a* convention, it's not the one we've used which puts users by default in shared groups (nwra, visitors, etc). For example: uid=2941(user) gid=1991(nwra) We may be fine changing conventions, but I'm researching whether or not we have to. Thanks. On 08/24/2016 11:19 AM, Justin Stephenson wrote: > Could you please explain further what you are trying to accomplish with an AD > trust default group? I believe we are following the standard linux convention > of creating a user private group using the ID number which matches the uid > number for AD trust users. > > Kind regards, > > Justin Stephenson > > > On 08/23/2016 06:27 PM, Orion Poplawski wrote: >> Is there any way to control the default gid for AD trust users? At the >> moment >> each user has it's own default group, e.g.: >> >> uid=22603(user@ad.domain) gid=22603(user@ad.domain) >> >> It would be nice to be able to set this to an actual group. >> >> Thanks. >> > -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
[Freeipa-users] Default gid for AD trust users
Is there any way to control the default gid for AD trust users? At the moment each user has it's own default group, e.g.: uid=22603(user@ad.domain) gid=22603(user@ad.domain) It would be nice to be able to set this to an actual group. Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] RHEL 7.2 update - ns-slapd replication keep alive entry
On 12/02/2015 01:42 PM, Andy Thompson wrote: > Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the system > up after a period of time. The directory becomes unresponsive to searches or > any connections. After a restart I see > > [02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 for LDAPS > requests > [02/Dec/2015:15:27:41 -0500] - Listening on /var/run/slapd-MHBENP-LIN.socket > for LDAPI requests > [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - > agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): Replication bind > with GSSAPI auth resumed > [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep alive > entry
Re: [Freeipa-users] Issue with ipa 4.2.0 upgrade
On 12/07/2015 12:17 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> I just upgraded my SL7 box to ipa-server-4.2.0, but this process appears to >> have broken ipa. From the ipaupgrade.log: >> >> 2015-12-07T17:47:46Z DEBUG Starting external process >> 2015-12-07T17:47:46Z DEBUG args='/bin/systemctl' 'is-active' >> 'certmonger.service' >> 2015-12-07T17:47:46Z DEBUG Process finished, return code=3 >> 2015-12-07T17:47:46Z DEBUG stdout=unknown >> >> 2015-12-07T17:47:46Z DEBUG stderr= >> 2015-12-07T17:47:46Z ERROR IPA server upgrade failed: Inspect >> /var/log/ipaupgrade.log and run com >> mand ipa-server-upgrade manually. >> 2015-12-07T17:47:46Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >> 171, in execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >> line 50, in ru >> n >> raise admintool.ScriptError(str(e)) >> >> 2015-12-07T17:47:46Z DEBUG The ipa-server-upgrade command failed, exception: >> ScriptError: Certmon >> ger is not running. Start certmonger and run upgrade again. >> 2015-12-07T17:47:46Z ERROR Certmonger is not running. Start certmonger and >> run >> upgrade again. >> >> I'm running in a CA-less mode and so certmonger is disabled on my system. I >> started certmonger and was able to complete the upgrade manually, but this >> looks like a bug in the upgrade script. Sound correct? > > Sounds like it to me. > > rob Reported: https://fedorahosted.org/freeipa/ticket/5519 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] web ui runtime error
On 11/23/2015 04:50 AM, Petr Vobornik wrote: On 11/23/2015 04:44 AM, Orion Poplawski wrote: Trying to install freeipa-server on Fedora 23. When I try to connect to the web UI from a non-domain EL7 client with firefox I get: Runtime error Web UI got in unrecoverable state during "init" phase Technical details: The operation is insecure. Does the browser trust IPA CA? I believe I've now imported the CA, but no difference. If you open Firefox developer tools (usually F12 key). In "network monitor" after page refresh which(if any) network requests have status other than "200 success" - first column? Everything is 200 or 304 (not modified) .cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:426 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3162 .cache["dojo/_base/array"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:29751 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3126 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2938 .cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:1410 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60885 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:61872 .cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2165 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2143 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 Vt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:7726 Zt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8899 nn/<@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9085 tn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8961 nn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9025 ln/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:10123 p.injectUrl/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js
[Freeipa-users] web ui runtime error
Trying to install freeipa-server on Fedora 23. When I try to connect to the web UI from a non-domain EL7 client with firefox I get: Runtime error Web UI got in unrecoverable state during "init" phase Technical details: The operation is insecure. .cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:426 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3162 .cache["dojo/_base/array"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:29751 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3126 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588 .cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2938 .cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:1410 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60885 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:61872 .cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2165 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959 .cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245 .cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2143 .cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298 Vt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:7726 Zt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8899 nn/<@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9085 tn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8961 nn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9025 ln/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:10123 p.injectUrl/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:12306 Do I have to do something to enable username/password auth for this version of IPA? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.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
Re: [Freeipa-users] Default shell for AD trust users
On 11/11/2015 12:57 AM, Jakub Hrozek wrote: > On Tue, Nov 10, 2015 at 11:44:12AM -0700, Orion Poplawski wrote: >> I see that AD trust users don't get their posix shell set: >> >> # getent passwd user >> u...@ad.nwra.com:*:2260345:2260345:A User:/export/home/user: >> >> I can fix this on the clients with override_shell, but that would apply to >> the >> IPA domain users as well. Is there some way to configure this in the >> trust/server? > > You might be interested in: > https://fedorahosted.org/sssd/wiki/DesignDocs/use_AD_homedir > > It's implemented in 7.2+ so any day now :) > Um, that's for homedir right, not the shell? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] Default shell for AD trust users
On 11/11/2015 12:57 AM, Jakub Hrozek wrote: > On Tue, Nov 10, 2015 at 11:44:12AM -0700, Orion Poplawski wrote: >> I see that AD trust users don't get their posix shell set: >> >> # getent passwd user >> u...@ad.nwra.com:*:2260345:2260345:A User:/export/home/user: >> >> I can fix this on the clients with override_shell, but that would apply to >> the >> IPA domain users as well. Is there some way to configure this in the >> trust/server? > > You might be interested in: > https://fedorahosted.org/sssd/wiki/DesignDocs/use_AD_homedir > > It's implemented in 7.2+ so any day now :) > Thanks for that, although I think default_shell = /bin/bash should work for me now. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
[Freeipa-users] Default shell for AD trust users
I see that AD trust users don't get their posix shell set: # getent passwd user u...@ad.nwra.com:*:2260345:2260345:A User:/export/home/user: I can fix this on the clients with override_shell, but that would apply to the IPA domain users as well. Is there some way to configure this in the trust/server? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] ipa-replica-prepare failing
On 08/06/2015 04:10 PM, David Dejaeghere wrote: Hello Guys, I was able to resolve this today. My webserver and dirsrv certificate were expired yesterday and trying to replace them gave me the same error ERROR: (SEC_ERROR_LIBRARY_FAILURE) security library failure. So I tried some things to resolve this. The trick was to replace /etc/ipa/ca.crt with the godaddy file gdig2 which only has 1 certificare. This file you can get while downloading your certificate from godaddy. Then I had to add the bundle from godaddy, file gd_bundle-g2-g1 into my server cert. This made both the command ipa-server-certinstall and ipa-replicate-prepare finish as expected! Hope this helps. I saw somebody else with a very similar issue. Kind Regards, D Yeah, the source of this issue appears to be a wrong /etc/ipa/ca.crt created during ipa-server-install. I was able to work around it with: ipa-certupdate Which wrote out a correct /etc/ipa/ca.crt. See https://fedorahosted.org/freeipa/ticket/5117#comment:16 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] ipa-replica-prepare error
On 07/28/2015 11:09 PM, Jan Cholasta wrote:
Dne 20.7.2015 v 19:52 Orion Poplawski napsal(a):
On 07/20/2015 12:57 AM, Jan Cholasta wrote:
Dne 15.7.2015 v 20:57 Orion Poplawski napsal(a):
On 07/14/2015 11:53 PM, Jan Cholasta wrote:
# ipa-replica-prepare -v ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12
--dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX
Directory Manager (existing master) password:
(SEC_ERROR_LIBRARY_FAILURE) security library failure.
I was able to debug this in gdb and tracked it down to a low entropy
condition. Details noted in https://fedorahosted.org/freeipa/ticket/5117.
Looks like prng_instantiate is being called 2-3 times and there just isn't
enough entropy:
Breakpoint 1, prng_instantiate (rng=0x7fffe5f9d3a0 theGlobalRng,
bytes=bytes@entry=0x7fffc220 \304(\336\350F8\375㨟\177\325\017+\302
\230\e\215\bf\201Rw;\300\260\330\366\315\342\235\034]\374J\324\263,
len=110) at drbg.c:160
160 if (len PRNG_SEEDLEN) {
1: len = 110
(gdb) c
Continuing.
Breakpoint 1, prng_instantiate (rng=rng@entry=0x7fffe5f9f620 testContext,
bytes=bytes@entry=0x2153b70
\216\234\r%u\\004\371\305y\020\213#y7\024\237,\307\v9\370\356\357\225\f\227Y\374\n\205A\240;\025\002,
len=len@entry=32) at drbg.c:160
160 if (len PRNG_SEEDLEN) {
1: len = 32
PRNG_SEEDLEN is 55 I think.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@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
Re: [Freeipa-users] ipa-replica-prepare error
On 07/20/2015 12:57 AM, Jan Cholasta wrote: Dne 15.7.2015 v 20:57 Orion Poplawski napsal(a): On 07/14/2015 11:53 PM, Jan Cholasta wrote: # ipa-replica-prepare -v ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX Directory Manager (existing master) password: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Not much :( Seems to be very early. I can't find an ipa-replica-prepare.log file. That's weird, there should be ~50 lines of output before ipa-replica-prepare prompts you for directory manager password. I didn't have any luck in reproducing the issue so far. Could you please try this: $ mkdir tmpdb $ certutil -N -d tmpdb $ pk12util -i nwra.com.p12 $ certutil -L -d tmpdb # look for nickname of certificate which has trust attributes of u,u,u $ certutil -O -d tmpdb -n nickname # use the nickname from above I would like to see the output of the last 2 commands. [root@europa ~]# pk12util -i nwra.com.p12 -d tmpdb Enter Password or Pin for NSS Certificate DB: Enter password for PKCS12 file: pk12util: no nickname for cert in PKCS12 file. pk12util: using nickname: *.nwra.com - COMODO CA Limited pk12util: PKCS12 IMPORT SUCCESSFUL [root@europa ~]# certutil -L -d tmpdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI COMODO RSA Domain Validation Secure Server CA - COMODO CA Limited ,, AddTrust External CA Root - AddTrust AB ,, *.nwra.com - COMODO CA Limited u,u,u COMODO RSA Certification Authority - AddTrust AB ,, [root@europa ~]# certutil -O -d tmpdb -n '*.nwra.com - COMODO CA Limited' AddTrust External CA Root - AddTrust AB [CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE] COMODO RSA Certification Authority - AddTrust AB [CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB] COMODO RSA Domain Validation Secure Server CA - COMODO CA Limited [CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB] *.nwra.com - COMODO CA Limited [CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Validated] -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] ipa-replica-prepare error
On 07/14/2015 11:53 PM, Jan Cholasta wrote: Hi, Dne 10.7.2015 v 22:33 Orion Poplawski napsal(a): On 07/08/2015 11:31 AM, Orion Poplawski wrote: But then when I go to make a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX Directory Manager (existing master) password: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Which looks like others are experiencing (with not resolution that I could see) https://www.redhat.com/archives/freeipa-users/2015-April/msg00514.html Unfortunately this error code can mean almost anything, NSS isn't particularly helpful with errors. Putting AddTrustExternalCARoot into nwra.com.p12 doesn't appear to help. Filed https://fedorahosted.org/freeipa/ticket/5117 Without ipa-replica-prepare log or pk12util output it's really hard to tell what's going on. Could you provide the output of the following commands: # pk12util -l nwra.com.p12 Certificate(has private key): Data: Version: 3 (0x2) Serial Number: 00:d1:3f:8c:79:cf:1c:87:53:f0:05:7c:f6:56:18:3a: 5c Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB Validity: Not Before: Thu Oct 11 00:00:00 2012 Not After : Sun Jan 10 23:59:59 2016 Subject: CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Val idated Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d8:08:80:96:8f:f0:80:86:cd:f0:e7:6a:11:7f:8e:fb: 4b:95:6a:42:93:c7:cf:c3:76:80:bd:a6:cc:6c:fd:e2: 89:1a:3f:97:c1:3d:2d:fe:e4:4a:90:c5:aa:33:97:b3: 54:cc:67:73:57:2d:cb:9f:d0:27:ea:f0:d8:9b:5d:24: 94:2f:f5:84:06:d4:04:e8:83:c5:b2:40:b1:59:2c:f8: 4f:73:9c:41:fc:8d:46:3d:be:46:e7:9f:15:5d:8c:a5: 47:23:de:e2:cf:b3:be:97:ed:0c:82:3e:00:29:b7:8b: a0:86:92:ec:07:00:8b:35:77:1c:27:ba:c8:a0:80:dc: 9a:69:dd:99:89:df:b4:70:f6:f6:8c:23:8b:f9:1d:bf: ba:07:32:36:17:bc:25:e7:fb:7a:b0:11:86:de:88:59: 51:ed:e5:de:5e:14:e5:c0:28:ce:d3:5b:92:38:de:fa: 4b:15:9d:62:13:69:31:5a:0d:21:6e:2e:a6:c6:ae:30: 94:95:ce:e6:6c:dc:22:71:b4:1a:3a:f9:ec:4b:72:e4: 9d:82:ba:6b:a5:46:b0:b7:5a:23:22:d3:92:57:5b:bf: 55:fd:70:df:36:13:9c:a9:df:50:6e:62:43:23:13:eb: f5:ef:ee:c7:15:e0:46:37:21:9b:3d:86:ea:2c:c7:01 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 90:af:6a:3a:94:5a:0b:d8:90:ea:12:56:73:df:43:b4: 3a:28:da:e7 Name: Certificate Subject Key ID Data: e9:88:f0:50:0f:f6:09:89:5c:3d:53:70:38:ca:82:22: 42:7e:21:e3 Name: Certificate Key Usage Critical: True Usages: Digital Signature Key Encipherment Name: Certificate Basic Constraints Critical: True Data: Is not a CA. Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6449.1.2.2.7 Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: https://secure.comodo.com/CPS; Policy Name: OID.2.23.140.1.2.1 Name: CRL Distribution Points Distribution point: URI: http://crl.comodoca.com/COMODORSADomainValidationSecure ServerCA.crl Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: http://crt.comodoca.com/COMODORSADomainValidationSecure ServerCA.crt Method: PKIX Online Certificate Status Protocol Location: URI: http://ocsp.comodoca.com; Name: Certificate Subject Alt Name DNS name: *.nwra.com DNS name: nwra.com Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 54:10:0f:42:9a:1f:42:df:1d:4e:e2:b8:bb:9f:c2:fc: e1:d7:b7:02:c5:9f:ed:5a:f1:d7:b4:58:23:ab:3c:a7: d3:9a:8d:71:f5:f4:a1:8b:02:0f:ce:ec:79:30:90:09: 41:fe:03:0d:0a:ee:44:ea:f0:9b:c0:e4:92:16:da:fd: b3:aa:bf:1d:30:7d:2d:40:33:cb:e5:a3:cc:a5:8f:0e: b3:40:8f:aa:1f:f5:74:40:95:5d:8f:5a:83
Re: [Freeipa-users] ipa-replica-prepare error
On 07/08/2015 11:31 AM, Orion Poplawski wrote: But then when I go to make a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX Directory Manager (existing master) password: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Which looks like others are experiencing (with not resolution that I could see) https://www.redhat.com/archives/freeipa-users/2015-April/msg00514.html Putting AddTrustExternalCARoot into nwra.com.p12 doesn't appear to help. Filed https://fedorahosted.org/freeipa/ticket/5117 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] ipa-replica-prepare error
On 06/01/2015 08:54 AM, Rob Crittenden wrote:
Orion Poplawski wrote:
On 05/28/2015 03:09 PM, Rob Crittenden wrote:
Orion Poplawski wrote:
We did a CAless install:
ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a
`cat
/etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt
--dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12
--http_pin= --idstart=8000
But now when we try to setup a replica:
# ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12
--dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin=
Directory Manager (existing master) password:
The full certificate chain is not present in nwra.com.p12
p12 file was created with:
openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey
/etc/pki/tls/private/nwra.com.key -certfile
/etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12
ipa-server-4.1.0-18.sl7_1.3.x86_64
Any thoughts?
At a glance your creation steps look ok. Strangely, the same code that loads
the PKCS#12 files are used both in the server install and replica prepare,
the
only difference it seems is that with the server install we get a copy of
the
CA separately too.
Can you provide the output of: pk12util -l nwra.com.p12
Maybe we can work out what it thinks is missing.
rob
I think I need to redo our install with an updated (SHA-2?) certificate, but
I
wouldn't think that would affect this issue either.
I don't believe this is related to the signature.
It looks like the right certs are there so I'm not sure what is going on. It
may be that the built-ins aren't being found and this is needed because the
AddTrust External Root isn't included, and it shouldn't need to be.
What is really blowing my mind is the same function that loads the PKCS#12
file is called both on install and replica prepare but only failing on the
later.
Maybe Honza has some ideas.
rob
Okay, getting back to this. Looks like this behavior was introduced later. I
installed with an earlier version of IPA. Now trying to reproduce the install
with 4.1 I get the same error on ipa-server-install.
Looks like the new behavior came in:
commit 88083887c994ab505d6e07151e5dd26b56bb7732
Author: Jan Cholasta jchol...@redhat.com
Date: Wed Sep 24 16:41:47 2014 +0200
CA-less installer options usability fixes
The --*_pkcs12 options of ipa-server-install and ipa-replica-prepare have
been replaced by --*-cert-file options which accept multiple files.
ipa-server-certinstall now accepts multiple files as well. The files are
accepted in PEM and DER certificate, PKCS#7 certificate chain, PKCS#8 and
raw private key and PKCS#12 formats.
The --root-ca-file option of ipa-server-install has been replaced by
--ca-cert-file option which accepts multiple files. The files are
accepted in PEM and DER certificate and PKCS#7 certificate chain formats.
The --*_pin options of ipa-server-install and ipa-replica-prepare have been
renamed to --*-pin.
https://fedorahosted.org/freeipa/ticket/4489
Reviewed-By: Petr Viktorin pvikt...@redhat.com
And is here (I added the root_logger.debug lines to figure out what is going
on):
# Check we have the whole cert chain the CA is in it
root_logger.debug('get_trust_chain for %s' % (key_nickname))
trust_chain = list(reversed(nssdb.get_trust_chain(key_nickname)))
root_logger.debug('trust_chain = %s' % (':'.join(trust_chain)))
ca_cert = None
for nickname in trust_chain[1:]:
cert = nssdb.get_cert(nickname)
if ca_cert is None:
ca_cert = cert
nss_cert = x509.load_certificate(cert, x509.DER)
subject = DN(str(nss_cert.subject))
issuer = DN(str(nss_cert.issuer))
root_logger.debug('nickname = %s, subject = %s, issuer = %s' %
(nickname, subject, issuer))
del nss_cert
if subject == issuer:
break
else:
raise ScriptError(
The full certificate chain is not present in %s %
(, .join(cert_files)))
So the issue for us is as follows:
We are issued a wildcard cert for *.nwra.com from namecheap.com/COMODO SSL.
They issue us a cert and a certificate chain file that provides two certs to
chain back to:
CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
This cert is in Firefox's certdb (and presumably other browsers) and so works.
FWIW - I don't seem to find this cert (or any AddTrust cert) in the openssl ca
certs in /etc/pki.
I'm not sure I follow the new logic. In the past with ldap SSL trusts in 389
we've always simply installed the cert that signed the DS cert as a trusted CA
cert (via /etc/openldap/{,ca}certs). I don't understand why we're now
insisting on having the issuer of the last cert in the DB.
But I am able to work with it by extracting the 'AddTrust External CA Root'
cert
[Freeipa-users] ipa-replica-prepare error
We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] ipa-replica-prepare error
On 05/28/2015 03:09 PM, Rob Crittenden wrote: Orion Poplawski wrote: We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? At a glance your creation steps look ok. Strangely, the same code that loads the PKCS#12 files are used both in the server install and replica prepare, the only difference it seems is that with the server install we get a copy of the CA separately too. Can you provide the output of: pk12util -l nwra.com.p12 Maybe we can work out what it thinks is missing. rob I think I need to redo our install with an updated (SHA-2?) certificate, but I wouldn't think that would affect this issue either. # pk12util -l nwra.com.p12 Enter password for PKCS12 file: Certificate(has private key): Data: Version: 3 (0x2) Serial Number: 45:22:20:8d:d6:04:19:2a:b1:e7:e5:4f:5e:e0:30:0e Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: CN=PositiveSSL CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB Validity: Not Before: Thu Oct 11 00:00:00 2012 Not After : Tue Oct 10 23:59:59 2017 Subject: CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Val idated Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d8:08:80:96:8f:f0:80:86:cd:f0:e7:6a:11:7f:8e:fb: 4b:95:6a:42:93:c7:cf:c3:76:80:bd:a6:cc:6c:fd:e2: 89:1a:3f:97:c1:3d:2d:fe:e4:4a:90:c5:aa:33:97:b3: 54:cc:67:73:57:2d:cb:9f:d0:27:ea:f0:d8:9b:5d:24: 94:2f:f5:84:06:d4:04:e8:83:c5:b2:40:b1:59:2c:f8: 4f:73:9c:41:fc:8d:46:3d:be:46:e7:9f:15:5d:8c:a5: 47:23:de:e2:cf:b3:be:97:ed:0c:82:3e:00:29:b7:8b: a0:86:92:ec:07:00:8b:35:77:1c:27:ba:c8:a0:80:dc: 9a:69:dd:99:89:df:b4:70:f6:f6:8c:23:8b:f9:1d:bf: ba:07:32:36:17:bc:25:e7:fb:7a:b0:11:86:de:88:59: 51:ed:e5:de:5e:14:e5:c0:28:ce:d3:5b:92:38:de:fa: 4b:15:9d:62:13:69:31:5a:0d:21:6e:2e:a6:c6:ae:30: 94:95:ce:e6:6c:dc:22:71:b4:1a:3a:f9:ec:4b:72:e4: 9d:82:ba:6b:a5:46:b0:b7:5a:23:22:d3:92:57:5b:bf: 55:fd:70:df:36:13:9c:a9:df:50:6e:62:43:23:13:eb: f5:ef:ee:c7:15:e0:46:37:21:9b:3d:86:ea:2c:c7:01 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 99:e4:40:5f:6b:14:5e:3e:05:d9:dd:d3:63:54:fc:62: b8:f7:00:ac Name: Certificate Subject Key ID Data: e9:88:f0:50:0f:f6:09:89:5c:3d:53:70:38:ca:82:22: 42:7e:21:e3 Name: Certificate Key Usage Critical: True Usages: Digital Signature Key Encipherment Name: Certificate Basic Constraints Critical: True Data: Is not a CA. Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6449.1.2.2.7 Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: http://www.positivessl.com/CPS; Policy Name: OID.2.23.140.1.2.1 Name: CRL Distribution Points Distribution point: URI: http://crl.comodoca.com/PositiveSSLCA2.crl; Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: http://crt.comodoca.com/PositiveSSLCA2.crt; Method: PKIX Online Certificate Status Protocol Location: URI: http://ocsp.comodoca.com; Name: Certificate Subject Alt Name DNS name: *.nwra.com DNS name: nwra.com Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 91:48:95:7d:ce:fa:42:46:16:57
[Freeipa-users] Broken krb5.conf after ipa-server-install
After running ipa-server-install like this:
ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat
/etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt
--dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXX --http_pkcs12=nwra.com.p12
--http_pin=XXX --idstart=8000
I'm not configuring bind.
I ended up with a broken krb5.conf with entries like:
[libdefaults]
default_realm = #
[realms]
NWRA.COM = {
kdc = server.nwra.com:88
master_kdc = server.nwra.com:88
admin_server = server.nwra.com:749
default_domain = nwra.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
# = {
kdc = server.nwra.com:88
admin_server = server.nwra.com:749
}
[domain_realm]
.nwra.com = NWRA.COM
nwra.com = NWRA.COM
# = #
.# = #
Any idea where the #'s are coming from?
ipa-server-3.3.3-28.el7_0.3.x86_64
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@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
Re: [Freeipa-users] Announcing FreeIPA 4.0.0
On 07/08/2014 03:53 AM, Petr Viktorin wrote: The FreeIPA team is proud to announce FreeIPA v4.0.0! It can be downloaded from http://www.freeipa.org/page/Downloads. As this is a major release, we did not add it to any stable Fedora release (yet), but we want to first give you a chance to test that yourself with a COPR repository: https://copr.fedoraproject.org/coprs/pviktori/freeipa/. Any reason not to have EL6/7 branches in the COPR repo? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@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
Re: [Freeipa-users] Updated doc, synchronization question
On 01/09/2014 06:07 AM, Martin Kosek wrote: On 01/08/2014 07:16 PM, Orion Poplawski wrote: Two questions: - Any ETA on an updated 3.3.3 Users Guide? Our current plan is to release next documentation release along with FreeIPA 3.4, when more documentation fixes are factored in. Just in case you would like to check the most recent status of the documentation work (or even help us with it), this page describes the details http://www.freeipa.org/page/Contribute/Documentation including instructions how to build HTMLs out of our git tree. Thanks, I'll take a look. - Is AD/IPA synchronization still supported in 3.3.3? Will it always? The AD/IPA synchronization is supported only in terms in bug fixes. As for the enhancements, the FreeIPA core team is focusing on the AD trusts: http://www.freeipa.org/page/Trusts (That does not mean we are not open to contributions from the community) Martin Thanks for the that link - the video was helpful. Although I'm afraid that is making me lean towards implementing the not recommended split brain approach. Although one thing that is not clear to me is weather doing this consumes CALs for the linux machines since they authenticate against AD. Currently we have two main office locations (DNS cora.nwra.com and nwra.com) plus some remote users and a 389-ds LDAP server for the Linux boxes and an AD domain (NWRA.LOCAL). We are using the LDAP/AD password/user sync module to sync users and passwords. Essentially, all of our Linux users are Windows users and vice versa, and we have well established UIDs on both sides. We would like to move to using Kerberos on the Linux machines and to be able to have as much SSO capability as possible. Am I correct in assuming that this either requires a single KDC or trusts between KDCs? While trusts are being promoted as the way to go for this, I'm afraid it will require a lot of tweaking to our current setup. Or perhaps not. We currently maintain DNS outside of both AD and would do the same IPA. We're happy to apply custom configurations via puppet, etc. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Updated doc, synchronization question
Two questions: - Any ETA on an updated 3.3.3 Users Guide? - Is AD/IPA synchronization still supported in 3.3.3? Will it always? Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Certificate Issues
This is a followup to some previous discussions. I have been lobbying to keep (and fix) the ability to install your own certificates when configuring IPA in order to make use of wildcard SSL certificates. But it seems this will not be the case. My last post on this went unanswered and I see tickets for the removal going forward. As I understand it though, I'll still be able to generate a CSR for the server and get it signed by and external CA? If this is the case, I guess this extra expense of individual SSL certificates for the various IPA servers could be acceptable, although unfortunate as this is what we had hoped to avoid with the wildcard cert. Finally, there was mention of the possibility of getting the IPA CA signed by an external authority. Just to let everyone know, this is a very expensive proposition. I was quoted a $22,500 start fee plus licensing costs. This is *way* out of our (and I suspect many other small businesses) price range. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate Issues
On 02/19/2013 03:10 PM, Simo Sorce wrote: On Tue, 2013-02-19 at 14:38 -0700, Orion Poplawski wrote: This is a followup to some previous discussions. I have been lobbying to keep (and fix) the ability to install your own certificates when configuring IPA in order to make use of wildcard SSL certificates. But it seems this will not be the case. My last post on this went unanswered and I see tickets for the removal going forward. As I understand it though, I'll still be able to generate a CSR for the server and get it signed by and external CA? If this is the case, I guess this extra expense of individual SSL certificates for the various IPA servers could be acceptable, although unfortunate as this is what we had hoped to avoid with the wildcard cert. Finally, there was mention of the possibility of getting the IPA CA signed by an external authority. Just to let everyone know, this is a very expensive proposition. I was quoted a $22,500 start fee plus licensing costs. This is *way* out of our (and I suspect many other small businesses) price range. Why would you need to get your CA signed by a public authority ? When we say external we generally think of another Internal CA that you already use for your own services. Simo. https://www.redhat.com/archives/freeipa-users/2013-January/msg00216.html -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate Issues
On 02/19/2013 07:31 PM, Dmitri Pal wrote: IMO this should eventually help https://fedoraproject.org/wiki/Features/SharedSystemCertificates Once this is solved the right certs can probably be delivered via OpenLMI or SSSD so rather than using already distributed certs it would be possible to easily distribute and apply the ones you need. Solves the problem but from a different side. Orion, if implemented would it work for you? My biggest concerns are Windows and OS X clients. Probably need to look at the various mozilla deployment tools. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Non-human users
Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 09:45 AM, Petr Viktorin wrote: On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between real human user accounts in IPA and non-human system accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. Yeah, that seems like the better idea, but: I think the main issue we've run into is needing the apache user to be a member of groups in ldap, and that not working unless the apache user was in ldap as well. Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 11:38 AM, John Dennis wrote: On 02/15/2013 01:35 PM, Rob Crittenden wrote: John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. The original message said this: I think the main issue we've run into is needing the apache user ... And: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 11:50 AM, John Dennis wrote: O.K. but I want to make sure you understand the difference. If you give login or other permissions to a network facing system daemon you're opening a huge security hole. Adding the apache user to the set of users managed by IPA is quite dangerous unless you are extraordinarily careful to remove privileges normally granted by IPA, it could lead to the complete compromise of your network. Understood. This is actually all before we have moved to IPA, but are exploring things. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 11:49 AM, Rob Crittenden wrote: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. In any case, it is probably reasonable to discuss these two cases separately. As John said, for pure system daemons it is probably best to leave those as local accounts. For quasi local accounts like mock or backup accounts things get a little fuzzy. I think I would avoid storing the user in /etc/passwd and the group in IPA, if possible. I imagine that sssd would be able to handle the case ok but I don't know that this is something they actively test. Why do you want/need to distinguish them from real people? rob What brought this up was the need to sync users from LDAP into another authentication system, and for that system we only wanted real human people to be listed. Also, we don't want these accounts listed in things like Thunderbird LDAP address books (hence no *person attributes: mail cn givenName sn). And just for doing periodic audits it would be helpful for distinguishing between them. I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 12:01 PM, Orion Poplawski wrote: I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using memberUid for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:56 PM, John Dennis wrote: On 02/15/2013 03:46 PM, Simo Sorce wrote: This is an interesting use case, it would probably be appropriate to have a RFE filed to allow to create ipa users marked as 'non-person' so that they are not assigned the person objectclass. Yes, that addresses one large component of the problem. But the part of the requirement is not to have non-humans show up in every client (e.g. mail clients) that support LDAP directory lookups. That means they have to modify the filter on every client. That's a tall order :-( Actually, this would cover it. The LDAP address book searches look for attributes that the *person objectclasses provide. Without them, they are excluded. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:42 PM, John Dennis wrote: On 02/15/2013 02:23 PM, Orion Poplawski wrote: On 02/15/2013 12:01 PM, Orion Poplawski wrote: I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using memberUid for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. Yes you're right, the user has to exist in LDAP in order to be a member of a group managed in LDAP. Your other alternative is not put these system users in LDAP and instead use local users groups managed via some other mechanism (puppet?). I've been testing with puppet, but that doesn't work. It detects the groups presence in ldap, so doesn't add them to /etc/group, then when it goes to add apache to the various groups, that fails. Possibly could missing functionality in puppet, but not a solution at the moment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 02:02 PM, John Dennis wrote: On 02/15/2013 03:57 PM, Orion Poplawski wrote: On 02/15/2013 01:56 PM, John Dennis wrote: On 02/15/2013 03:46 PM, Simo Sorce wrote: This is an interesting use case, it would probably be appropriate to have a RFE filed to allow to create ipa users marked as 'non-person' so that they are not assigned the person objectclass. Yes, that addresses one large component of the problem. But the part of the requirement is not to have non-humans show up in every client (e.g. mail clients) that support LDAP directory lookups. That means they have to modify the filter on every client. That's a tall order :-( Actually, this would cover it. The LDAP address book searches look for attributes that the *person objectclasses provide. Without them, they are excluded. Interesting, before I replied I checked the filter in my Thunderbird client and it's set to (objectclass=*). I don't know if I modified it as some point or if it's the default, I assumed it's the default. I suspect it's the default filter for many clients. Hmm, that is the filter in TB for me too, but: [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH base=ou=people,dc=nwra,dc=com scope=2 filter=(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*)) attrs=description notes title sn sn mozillaHomeLocalityName givenName mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager pagerphone ou department departmentNumber orgunit birthmonth mozillaWorkStreet2 mozillaHomePostalCode objectClass is what I see in the LDAP server log -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:46 PM, Simo Sorce wrote: On Fri, 2013-02-15 at 12:01 -0700, Orion Poplawski wrote: What brought this up was the need to sync users from LDAP into another authentication system, and for that system we only wanted real human people to be listed. Also, we don't want these accounts listed in things like Thunderbird LDAP address books (hence no *person attributes: mail cn givenName sn). And just for doing periodic audits it would be helpful for distinguishing between them. I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This is an interesting use case, it would probably be appropriate to have a RFE filed to allow to create ipa users marked as 'non-person' so that they are not assigned the person objectclass. Simo. Filed https://fedorahosted.org/freeipa/ticket/3431 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 02:34 PM, John Dennis wrote: On 02/15/2013 04:16 PM, Orion Poplawski wrote: Hmm, that is the filter in TB for me too, but: [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH base=ou=people,dc=nwra,dc=com scope=2 filter=(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*)) attrs=description notes title sn sn mozillaHomeLocalityName givenName mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager pagerphone ou department departmentNumber orgunit birthmonth mozillaWorkStreet2 mozillaHomePostalCode objectClass is what I see in the LDAP server log I don't know, beats me as to why there is no objectclass filter component. Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and ignores it when it builds the final filter. What happens if you set the TB filter to (objectclass=person)? Yup, then it adds it: filter=((objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*))) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 04:03 PM, Simo Sorce wrote: On Fri, 2013-02-15 at 17:12 -0500, John Dennis wrote: On 02/15/2013 04:54 PM, Orion Poplawski wrote: On 02/15/2013 02:34 PM, John Dennis wrote: On 02/15/2013 04:16 PM, Orion Poplawski wrote: Hmm, that is the filter in TB for me too, but: [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH base=ou=people,dc=nwra,dc=com scope=2 filter=(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*)) attrs=description notes title sn sn mozillaHomeLocalityName givenName mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager pagerphone ou department departmentNumber orgunit birthmonth mozillaWorkStreet2 mozillaHomePostalCode objectClass is what I see in the LDAP server log I don't know, beats me as to why there is no objectclass filter component. Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and ignores it when it builds the final filter. What happens if you set the TB filter to (objectclass=person)? Yup, then it adds it: filter=((objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*))) O.K. I presume it's obvious the consequence of this little experiment is that if we do an an RFE that results in removing the person objectclass from non-human users you'll have to configure a custom LDAP search filter in every client in your enterprise if you don't want them to see non-human users in their search results. Not really, without the person objectclass none of the attributes thunderbird searches by default would be part of the user object, so the user would *not* show up. So the RFE would perfectly solve also the requirement these 'non-person' users do not show up in thunderbird. Simo. posixAccount must have cn. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 04:06 PM, Orion Poplawski wrote: On 02/15/2013 04:03 PM, Simo Sorce wrote: On Fri, 2013-02-15 at 17:12 -0500, John Dennis wrote: On 02/15/2013 04:54 PM, Orion Poplawski wrote: Yup, then it adds it: filter=((objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*))) O.K. I presume it's obvious the consequence of this little experiment is that if we do an an RFE that results in removing the person objectclass from non-human users you'll have to configure a custom LDAP search filter in every client in your enterprise if you don't want them to see non-human users in their search results. Not really, without the person objectclass none of the attributes thunderbird searches by default would be part of the user object, so the user would *not* show up. So the RFE would perfectly solve also the requirement these 'non-person' users do not show up in thunderbird. Simo. posixAccount must have cn. That said, there are still other (and arguably more important) reasons for this RFE. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-replica-prepare failed
On 02/08/2013 06:44 AM, Rob Crittenden wrote: James James wrote: I had to set the --dirsrv_pkcs12, --dirsrv_pin, --http_pkcs12, --http_pin and the ipa-replica-prepare command runs without failure. Thanks for your help. Yes, this is what I was going to suggest. Using ipa-server-certinstall replace the IPA CA with an external one. I should note that we're deprecating this tool and do not recommend that it be used. We instead suggest that if you need certificates from an external CA you get the IPA CA signed as a subordinate. rob Is that possible to do from a commercial SSL certificate provider? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] using wildcard or other external CA certs
On 01/23/2013 01:43 PM, Dmitri Pal wrote: Yes please. Let us do it on the user list. Ticket URL:https://fedorahosted.org/freeipa/ticket/3360#comment:14 So, my goal in using a wildcard cert signed by a well known CA was to be able to avoid installing the IPA CA in clients like Thunderbird and Firefox. Thoughts, comments, suggestions? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] using wildcard or other external CA certs
On 01/23/2013 02:30 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 01/23/2013 03:45 PM, Orion Poplawski wrote: On 01/23/2013 01:43 PM, Dmitri Pal wrote: Yes please. Let us do it on the user list. Ticket URL:https://fedorahosted.org/freeipa/ticket/3360#comment:14 So, my goal in using a wildcard cert signed by a well known CA was to be able to avoid installing the IPA CA in clients like Thunderbird and Firefox. Thoughts, comments, suggestions? When you enroll the client we deliver the IPA CA cert to it and store it in every cert store we can AFAIU. But I will leave to Rob to comment on that. Well, that is certainly a good idea. Unfortunately that isn't something we can do right now, even with passing in PKCS#12 files. I suspect that with enough intimate knowledge of the cert code you could get something to work (I'd guess you'd need to get the PKCS#12 friendly names just right). This is just hard to automate in any sort of reliable way. I'm not clear if you are referring to client (as Dmitri did) or server install (as I was trying to do) here. Having client tools to install the IPA CA would be helpful, but would be needed on multiple platforms. Handling the cert names seems to be the big issue with the server install (and the subject of the bug). FWIW - I've managed to install and replicate 2.2 with such a cert with the hack to the cert code and pausing the install at the right place to fix the CA trust level. So I really don't think we are that far off if we wanted to go this route. The problem I see at the moment is properly identifying the name the CA cert will have in the NSS store without a Friendly Name. There is also a new feature in Fedora to consolidate the certificate store for different components: https://fedoraproject.org/wiki/Features/SharedSystemCertificates It is the step into the right direction. Once it is implemented we would be able to place IPA cert there during enrollment. Yup, I think this will help quite a bit. For Fedora. But Windows, OS X, etc ? FF users have to accept IPA cert when they hit IPA self service the first time. I do not see a way around placing the certs into the right stores but may be I am missing something. You can probably use something like puppet to deliver it but isn't the cert store for FF in the user home directory? It might not be available for puppet or any other central tool to mess with. His point is that if he uses a cert issued by a root CA (e.g. Verisign) then his users won't have to do anything SSL trust-wise because it would already be trusted. Yup. We spent a fair bit of time trying to figure this out a couple of years ago and could never come to any sort of workable solution. It is possible for the client installer to stuff the CA into various places but that always inevitably led to really bad corner cases, and in particular, issues with re-installs. rob Firefox is not so bad I suppose - you can click on a link and it will prompt you to install the cert. I remember Thunderbird to be a much bigger pain, but perhaps that has changed. I'll have to test. I can also imagine another architecture where there are slave LDAP servers with root CA assigned certs for general clients to connect to. The IPA webserver will only be accessed by a few clients so that is less of a big deal. Thanks for the good discussion. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CA cert issues
On 01/16/2013 06:50 PM, Rob Crittenden wrote: We really need to put a big fat warning on this too: there be dragons. It is really meant for v1 servers where we didn't have a full CA. The CA is really integrated into IPA v2+ such that replacing certs is going to cause some amount of grief (as you've seen). I didn't think we blew away the existing NSS database using the tool, though it certainly sounds like we are. What you're missing in the ipaCert in /etc/httpd/alias. This is used to authenticate to dogtag. Can you poke around in /etc/httpd to see if a backup was made, or use certutil to get a list of the nicknames in there? I'm guessing it is trying to issue an SSL cert for the CA 389-ds instance. There are no cli options for providing that. Even if you did manage to get a prepared file you'd likely run into a whole new batch of install problems. Sorry about that. We really need to decide whether this tool is worth supporting at all and fix it (or make it safer) or simply do away with it. Right now it's just a really sharp tool waiting to cut someone. rob Well, it looks like it move all of the existing files in /etc/httpd/alias to .orig extensions. I moved those over to an alias.orig directory and imported the ipaCert key. That allowed ipa-replica-prepare to run. Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com Copying SSL certificate for the Directory Server from STAR_cora_nwra_com.p12 Creating SSL certificate for the dogtag Directory Server Copying SSL certificate for the Web Server from STAR_cora_nwra_com.p12 Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg But then on ipa-replica-install, problems as predicted: ipa-replica-install --setup-ca /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg ... [16/30]: configuring ssl for ds instance creation of replica failed: Could not find a CA cert in /tmp/tmpPAtailipa/realm_info/dscert.p12 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CA cert issues
On 01/17/2013 09:27 AM, Rob Crittenden wrote: Orion Poplawski wrote: But then on ipa-replica-install, problems as predicted: ipa-replica-install --setup-ca /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg ... [16/30]: configuring ssl for ds instance creation of replica failed: Could not find a CA cert in /tmp/tmpPAtailipa/realm_info/dscert.p12 Ok, I think what I would recommend is preparing a replica w/o replacing the certs (e.g. let the CA issue certs for all the services). Install the replica. Then replace with the wildcard certs once the install is up and functioning. rob That gets to: [21/30]: setting up initial replication Starting replication, please wait until this has completed. [ipa.cora.nwra.com] reports: Update failed! Status: [-11 - System error] creation of replica failed: Failed to start replication Because on ipa.cora : [17/Jan/2013:09:31:42 -0700] NSMMReplicationPlugin - agmt=cn=meToipapub.cora.nwra.com (ipapub:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.) because the new cert install wiped out the old slapd-NWRA-COM certs. Installed the NWRA.COM IPA CA there. It seems like a most of the problems would be alleviated if instead of wiping out the old NSS dbs, it simply added the new certs. I don't know if there are any other security implications of this or not. I'm also tempted to start over and do the --dirsrv-cert options on the initial ipa-server-install to see if that helps. Anyway, tried again and now: Configuring Kerberos KDC: Estimated time 30 seconds [1/9]: adding sasl mappings to the directory [2/9]: writing stash file from DS [3/9]: configuring KDC [4/9]: creating a keytab for the directory [5/9]: creating a keytab for the machine [6/9]: adding the password extension to the directory [7/9]: enable GSSAPI for replication creation of replica failed: list index out of range 2013-01-17T16:41:33Z DEBUG [7/9]: enable GSSAPI for replication 2013-01-17T16:41:33Z INFO Setting agreement cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2013-01-17T16:41:34Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config 2013-01-17T16:41:35Z INFO Replication Update in progress: FALSE: status: -11 - System error: start: 0: end: 0 2013-01-17T16:41:35Z INFO Setting agreement cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2013-01-17T16:41:36Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config 2013-01-17T16:41:37Z INFO Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 20130117164126Z: end: 20130117164127Z 2013-01-17T16:41:37Z DEBUG list index out of range File /usr/sbin/ipa-replica-install, line 496, in module main() File /usr/sbin/ipa-replica-install, line 441, in main krb = install_krb(config, setup_pkinit=options.setup_pkinit) File /usr/sbin/ipa-replica-install, line 163, in install_krb setup_pkinit, pkcs12_info) File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 207, in create_replica self.start_creation(Configuring Kerberos KDC, 30) File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line 257, in start_creation method() File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 442, in __convert_to_gssapi_replication r_bindpw=self.dm_password) File /usr/lib/python2.6/site-packages/ipaserver/install/replication.py, line 833, in convert_to_gssapi_replication self.gssapi_update_agreements(self.conn, r_conn) File /usr/lib/python2.6/site-packages/ipaserver/install/replication.py, line 557, in gssapi_update_agreements self.setup_krb_princs_as_replica_binddns(a, b) File /usr/lib/python2.6/site-packages/ipaserver/install/replication.py, line 550, in setup_krb_princs_as_replica_binddns mod = [(ldap.MOD_ADD, nsds5replicabinddn, a_pn[0].dn)] I also see this in /var/log/dirsrv/slapd-NWRA-COM/errors on the master: [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - agmt=cn=meToipapub.cora.nwra.com (ipapub:389): Schema replication update failed: Type or value exists [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - agmt=cn=meToipapub.cora.nwra.com (ipapub:389): Warning: unable to replicate schema: rc=1 Which is probably due to some schema modifications I've made, but these don't really seem related to the error above. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane
[Freeipa-users] CA cert issues
I've installed ipa 2.2 on EL6. I initially simply did an ipa-server-install. Then I changed the cert used via ipa-server-certinstall to use a wildcard SSL cert issued by Comodo. This has led to a lot of grief and needing to install the Comodo CA chain into lots of SSL dbs. Now I'm looking at replicating the server with: ipa-replica-prepare ipapub.cora.nwra.com --dirsrv_pkcs12=STAR_cora_nwra_com.p12 --dirsrv_pin=x --http_pkcs12=STAR_cora_nwra_com.p12 --http_pin=xx But I get: Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com Copying SSL certificate for the Directory Server from STAR_cora_nwra_com.p12 Creating SSL certificate for the dogtag Directory Server ipa: ERROR: cert validation failed for CN=ipa.cora.nwra.com,O=NWRA.COM ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) preparation of replica failed: cannot connect to 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. cannot connect to 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. File /usr/sbin/ipa-replica-prepare, line 459, in module main() File /usr/sbin/ipa-replica-prepare, line 353, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, dogtagcert, replica_fqdn, subject_base) File /usr/sbin/ipa-replica-prepare, line 143, in export_certdb raise e Any suggestions? I don't really understand how the dogtag ca fits in with this scenario. Should I just get rid of it? Can I? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] compat and ou=People
We're looking at migrating from 389ds to ipa. Currently our users are in ou=People with rfc2307 attributes. Is there any way to provide an ou=people,dc=nwra,dc=com compatibility group in IPA? Or does everything have to remain under cn=compat? We have a lot of references to ou=People,dc=nwra,dc=com in clients. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] compat and ou=People
On 01/14/2013 01:40 PM, Nalin Dahyabhai wrote:
On Mon, Jan 14, 2013 at 12:06:35PM -0700, Orion Poplawski wrote:
We're looking at migrating from 389ds to ipa. Currently our users
are in ou=People with rfc2307 attributes. Is there any way to
provide an ou=people,dc=nwra,dc=com compatibility group in IPA? Or
does everything have to remain under cn=compat? We have a lot of
references to ou=People,dc=nwra,dc=com in clients.
Things show up under cn=compat because the Schema Compatibility plugin
is configured to put them there. With a bit of manual configuration,
the compatibility user entries can show up under ou=People, too. Here's
an initial guess at how that'd look, mostly copy/pasted from the compat
configuration:
dn: ou=people,cn=Schema Compatibility,cn=plugins,cn=config
schema-compat-entry-attribute: objectclass=posixAccount
schema-compat-entry-attribute: gecos=%{cn}
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-attribute: uidNumber=%{uidNumber}
schema-compat-entry-attribute: gidNumber=%{gidNumber}
schema-compat-entry-attribute: loginShell=%{loginShell}
schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
ou: people
objectClass: top
objectClass: extensibleObject
schema-compat-search-filter: objectclass=posixAccount
schema-compat-entry-rdn: uid=%{uid}
schema-compat-search-base: cn=users, cn=accounts, dc=nwra,dc=com
schema-compat-container-group: ou=people,dc=nwra,dc=com
You'd need to stop the directory server, add this to its dse.ldif file,
and start it up again.
HTH,
Nalin
Great, that seems to work well. Thanks!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] db2bak.pl and db2ldif utils
With our current 389ds installs we are making use of the db2bak.pl and db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0 install these scripts were create for the PKI-IPA ds server in /usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance. I suppose this is already address in 3.1 since it only creates a single instance. Are there any IPA backup utilities on the horizon? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] db2bak.pl and db2ldif utils
On 01/10/2013 03:22 PM, Rich Megginson wrote: On 01/10/2013 02:59 PM, Orion Poplawski wrote: With our current 389ds installs we are making use of the db2bak.pl and db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0 install these scripts were create for the PKI-IPA ds server in /usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance. They are in /var/lib/dirsrv/scripts-INSTANCE Hah, that's funny. I just didn't check after seeing the /usr/lib64/dirsrv/slapd-PKI-IPA directory. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] db2bak.pl and db2ldif utils
On 01/10/2013 03:29 PM, Orion Poplawski wrote:
On 01/10/2013 03:22 PM, Rich Megginson wrote:
On 01/10/2013 02:59 PM, Orion Poplawski wrote:
With our current 389ds installs we are making use of the db2bak.pl and
db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0
install these scripts were create for the PKI-IPA ds server in
/usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance.
They are in /var/lib/dirsrv/scripts-INSTANCE
Hah, that's funny. I just didn't check after seeing the
/usr/lib64/dirsrv/slapd-PKI-IPA directory. Thanks!
FWIW -
Here's my current backup script (in /etc/cron.daily/dirsrv-backup). Did this:
mv /usr/lib64/dirsrv/slapd-PKI-IPA /var/lib/dirsrv/scripts-PKI-IPA
ln -s /var/lib/dirsrv/scripts-PKI-IPA /usr/lib64/dirsrv/slapd-PKI-IPA
To make the two installs similar.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
#!/bin/bash
# Backup each instance
for dirsrv in /etc/dirsrv/slapd-*
do
name=${dirsrv/*slapd-/}
vardir=/var/lib/dirsrv/slapd-${name}
scriptdir=/var/lib/dirsrv/scripts-${name}
${scriptdir}/db2bak.pl -D 'cn=Directory Manager' -j /etc/ldap.secret -a
${vardir}/bak/${name}-`date +%Y_%m_%d_%H_%M_%S` /dev/null
/usr/sbin/tmpwatch -mM 240 ${vardir}/bak
dbdir=${vardir}/db
for dbentry in ${dbdir}/*
do
if [ -d ${dbentry} ]
then
dbname=$(basename ${dbentry})
${scriptdir}/db2ldif -n ${dbname} /dev/null
fi
done
/usr/sbin/tmpwatch -mM 240 ${vardir}/ldif
done
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] db2bak.pl and db2ldif utils
On 01/10/2013 03:50 PM, Rich Megginson wrote:
On 01/10/2013 03:45 PM, Orion Poplawski wrote:
FWIW -
Here's my current backup script (in /etc/cron.daily/dirsrv-backup). Did this:
mv /usr/lib64/dirsrv/slapd-PKI-IPA /var/lib/dirsrv/scripts-PKI-IPA
ln -s /var/lib/dirsrv/scripts-PKI-IPA /usr/lib64/dirsrv/slapd-PKI-IPA
To make the two installs similar.
I don't recommend doing that as it may break upgrades and/or cause problems
with selinux. But YMMV.
Okay, right you are. Here's a new script.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
#!/bin/bash
# Backup each instance
for dirsrv in /etc/dirsrv/slapd-*
do
name=${dirsrv/*slapd-/}
vardir=/var/lib/dirsrv/slapd-${name}
[ -d /var/lib/dirsrv/scripts-${name} ]
scriptdir=/var/lib/dirsrv/scripts-${name}
[ -d /usr/lib64/dirsrv/slapd-${name} ]
scriptdir=/usr/lib64/dirsrv/slapd-${name}
[ -d /usr/lib/dirsrv/slapd-${name} ]
scriptdir=/usr/lib/dirsrv/slapd-${name}
${scriptdir}/db2bak.pl -D 'cn=Directory Manager' -j /etc/ldap.secret -a
${vardir}/bak/${name}-`date +%Y_%m_%d_%H_%M_%S` /dev/null
/usr/sbin/tmpwatch -mM 240 ${vardir}/bak
dbdir=${vardir}/db
for dbentry in ${dbdir}/*
do
if [ -d ${dbentry} ]
then
dbname=$(basename ${dbentry})
${scriptdir}/db2ldif -n ${dbname} /dev/null
fi
done
/usr/sbin/tmpwatch -mM 240 ${vardir}/ldif
done
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Setting up single domain but with dns subdomains
I'm looking into migrating our 389ds ldap + kerberos to FreeIPA and I'm wondering how to setup DNS autodiscovery (if possible) in a way to point to different servers in different locations. We have two major offices, one that uses the nwra.com dnsdomain and one that uses the cora.nwra.com dns subdomain. We're planning on using the NWRA.COM domain for IPA/kerberos. I'd like to have the hosts is the cora office use the local servers instead of the one at the main office. Is this possible? While I can have: _ldap._tcp.cora.nwra.com. SRV 0 0 636 ipa.cora.nwra.com. If I have: _kerberos.cora.nwra.com. TXT NWRA.COM it will then automatically look for: _kerberos._udp.nwra.com. SRV Which will hold the servers for the other office. Any suggestions? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
