[Freeipa-users] Blog post: Debugging FreeIPA 4.5 privilege separation code
Hi, Simo and I wrote an article on how to debug FreeIPA 4.5 privilege separation code. It is not about debugging, in fact, but on where to look for various types of logs and how to interpret them. The article also provides a high level explanation of how privilege separation in FreeIPA works and what it allows us to achieve. You can read the article here: https://vda.li/en/docs/freeipa-debug-privsep/ -- / Alexander Bokovoy -- 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 trust between FreeIPA and Samba AD DC
On Fri, Apr 28, 2017 at 07:27:20PM +0200, Tiemen Ruiten wrote: > Hello Alexander, list, > > I did get further by specifying --external=true in the ipa trust-add > command, it works now for *both* the Windows and the Samba domain: > > ipa trust-add office.rdmedia.com --type=ad --admin Administrator --password > --two-way=false --external=true > > IPA reports the trust is established successfully and I can also see it in > Active Directory Domains and Trusts. However, adding users/groups to an > external group fails: > > [root@ipa-ams-01 tiemen]# ipa group-add-member office_admins_external > --external "OFFICE\domain admins" > [member user]: > [member group]: > Group name: office_admins_external > Description: office.rdmedia.com admins external map > Failed members: > member user: > member group: *OFFICE\domain admins: trusted domain object not found* > - > Number of members added 0 > - Domain Admins is a domain-local group typically. I would advise against using those for cross-forest trust memberships in general. Can you also check if you can resolve objects from the trusted AD/Samba domain? Try: getent passwd administra...@office.rdmedia.com for example. -- 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] Malformed representation of principal - krb5_child.log
On (28/04/17 16:21), Sullivan, Daniel [CRI] wrote: >Jakub, > >Thank you for your email. We maintain our own repo that we populate from >Copr; your question led me to realize that the repo was broken and this >particular system was running an older version of sssd. I upgraded it to >1.14.2-2.el6 and the problem was resolved. Thank you Sumit and Jakub for your >help. Have a nice weekend. > Do you really maintain own copr? Or do you use https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/ I am just curious :-) LS -- 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 trust between FreeIPA and Samba AD DC
Hello Alexander, list, I did get further by specifying --external=true in the ipa trust-add command, it works now for *both* the Windows and the Samba domain: ipa trust-add office.rdmedia.com --type=ad --admin Administrator --password --two-way=false --external=true IPA reports the trust is established successfully and I can also see it in Active Directory Domains and Trusts. However, adding users/groups to an external group fails: [root@ipa-ams-01 tiemen]# ipa group-add-member office_admins_external --external "OFFICE\domain admins" [member user]: [member group]: Group name: office_admins_external Description: office.rdmedia.com admins external map Failed members: member user: member group: *OFFICE\domain admins: trusted domain object not found* - Number of members added 0 - Of course that group exists on the Samba DC: [root@fluorine samba]# wbinfo -g OFFICE\cert publishers OFFICE\ras and ias servers OFFICE\allowed rodc password replication group OFFICE\denied rodc password replication group OFFICE\dnsadmins OFFICE\enterprise read-only domain controllers OFFICE\domain admins OFFICE\domain users OFFICE\domain guests OFFICE\domain computers OFFICE\domain controllers OFFICE\schema admins OFFICE\enterprise admins OFFICE\group policy creator owners OFFICE\read-only domain controllers OFFICE\dnsupdateproxy BTW, adding a two-way trust fails because the AD DC reports it can't contact any IPA server. Firewalls on all servers have been disabled. I would appreciate any insights! On 28 April 2017 at 12:09, Tiemen Ruiten wrote: > Hello, > > I set up a fresh Windows Server 2012R2 instance, configured a new forest > named 'clients.rdmedia.com' and I'm getting the same error in the httpd > error_log after running 'ipa trust-add clients.rdmedia.com --type=ad > --admin=Administrator --password': > > [Fri Apr 28 12:05:00.420174 2017] [:error] [pid 26417] ipa: ERROR: > non-public: RuntimeError: (-1073741811, 'Unexpected information received') > [Fri Apr 28 12:05:00.420225 2017] [:error] [pid 26417] Traceback (most > recent call last): > [Fri Apr 28 12:05:00.420230 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in > wsgi_execute > [Fri Apr 28 12:05:00.420235 2017] [:error] [pid 26417] result = > command(*args, **options) > [Fri Apr 28 12:05:00.420239 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in > __call__ > [Fri Apr 28 12:05:00.420243 2017] [:error] [pid 26417] return > self.__do_call(*args, **options) > [Fri Apr 28 12:05:00.420247 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in > __do_call > [Fri Apr 28 12:05:00.420251 2017] [:error] [pid 26417] ret = > self.run(*args, **options) > [Fri Apr 28 12:05:00.420255 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run > [Fri Apr 28 12:05:00.420258 2017] [:error] [pid 26417] return > self.execute(*args, **options) > [Fri Apr 28 12:05:00.420262 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 739, > in execute > [Fri Apr 28 12:05:00.420267 2017] [:error] [pid 26417] result = > self.execute_ad(full_join, *keys, **options) > [Fri Apr 28 12:05:00.420297 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 989, > in execute_ad > [Fri Apr 28 12:05:00.420304 2017] [:error] [pid 26417] trust_type > [Fri Apr 28 12:05:00.420308 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in > join_ad_full_credentials > [Fri Apr 28 12:05:00.420312 2017] [:error] [pid 26417] trust_type, > trust_external) > [Fri Apr 28 12:05:00.420316 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in > establish_trust > [Fri Apr 28 12:05:00.420320 2017] [:error] [pid 26417] > self.update_ftinfo(another_domain) > [Fri Apr 28 12:05:00.420324 2017] [:error] [pid 26417] File > "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in > update_ftinfo > [Fri Apr 28 12:05:00.420328 2017] [:error] [pid 26417] ftinfo, 0) > [Fri Apr 28 12:05:00.420331 2017] [:error] [pid 26417] RuntimeError: > (-1073741811, 'Unexpected information received') > [Fri Apr 28 12:05:00.420975 2017] [:error] [pid 26417] ipa: INFO: > [jsonserver_session] ad...@i.rdmedia.com: trust_add/1(u'clients.rdmedia. > com', trust_type=u'ad', realm_admin=u'Administrator', > realm_passwd=u'', version=u'2.213'): RuntimeError > > Am I doing something wrong? Logs are ofcourse available privately on > request. > > On 14 April 2017 at 15:13, Alexander Bokovoy wrote: > >> On pe, 14 huhti 2017, Tiemen Ruiten wrote: >> >>> Yes, office.rdmedia.com is the Samba AD domain. >>> >>> [root@fluorine samba]# samba-tool domai
Re: [Freeipa-users] Malformed representation of principal - krb5_child.log
Jakub, Thank you for your email. We maintain our own repo that we populate from Copr; your question led me to realize that the repo was broken and this particular system was running an older version of sssd. I upgraded it to 1.14.2-2.el6 and the problem was resolved. Thank you Sumit and Jakub for your help. Have a nice weekend. Dan > On Apr 28, 2017, at 10:34 AM, Jakub Hrozek wrote: > > On Fri, Apr 28, 2017 at 03:28:31PM +, Sullivan, Daniel [CRI] wrote: >> Hi, Sumit, >> >> Thank you for taking the time to respond to me. I tried that; it did not >> work. I am using sssd 1.14.0-3.el6. Any other support you (or anybody >> else) could provide would be greatly appreciated. > > Do you remember where did you install this RPM from? I don't think we ever > released 1.14 for el6 via RHEL. > > (yum info sssd would tell you I think) > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- 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] Malformed representation of principal - krb5_child.log
On Fri, Apr 28, 2017 at 03:28:31PM +, Sullivan, Daniel [CRI] wrote: > Hi, Sumit, > > Thank you for taking the time to respond to me. I tried that; it did not > work. I am using sssd 1.14.0-3.el6. Any other support you (or anybody else) > could provide would be greatly appreciated. Do you remember where did you install this RPM from? I don't think we ever released 1.14 for el6 via RHEL. (yum info sssd would tell you I think) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Malformed representation of principal - krb5_child.log
Hi, Sumit, Thank you for taking the time to respond to me. I tried that; it did not work. I am using sssd 1.14.0-3.el6. Any other support you (or anybody else) could provide would be greatly appreciated. Dan > On Apr 28, 2017, at 10:13 AM, Sumit Bose wrote: > > On Fri, Apr 28, 2017 at 02:54:44PM +, Sullivan, Daniel [CRI] wrote: >> HI, >> >> I haven’t posted in a while, I hope everybody is doing well. I have a >> problem that I am having a difficult time diagnosing. To start, I want to >> say that we have a pretty large IPA environment. It generally works good. >> Most of our servers are of the same flavor RHEL6/7, and pull down their >> sssd/IPA RPMs from a standard repo. We also deploy sssd/ipa-client from >> SaltStack, so there’s not much variation on configuration. I have a client >> that is being very finicky, I am getting a message that says "Malformed >> representation of principal” in my krb5_child.log (when trying to log in). >> I’m really kind of an ends with the right way to troubleshoot this further. >> Here’s what I know; >> >> 1) I can kinit -k as root >> 2) I can kinit user@domain, even for the user in the sssd logs >> 3) I’ve blown away /var/lib/sss, deleted /etc/krb*, reinstalled sssd-common, >> sssd, & ipa-client. >> >> My logs are below. Would somebody be able to perhaps provide input on the >> best way to further troubleshoot this issue? >> >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0400): >> krb5_child started. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] >> (0x1000): total buffer size: [174] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] >> (0x0100): cmd [241] uid [339788572] gid [339788572] validate [true] >> enterprise principal [false] offline [false] UPN [user@domain@DOMAIN] > > There was an issue in an older version of SSSD which saved a wrong UPN > in the cache. Please check if the latest version of SSSD for your > platform installed, stop SSSD, remove the cache file in > /var/lib/sss/db/, start SSSD and try again. > > If you do not want to remove the cache completely you can use e.g. > ldbedit to delete the offending entry individually, search for > user@domain@DOMAIN. > > HTH > > bye, > Sumit > >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] >> (0x2000): No old ccache >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] >> (0x0100): ccname: [FILE:/tmp/krb5cc_339788572_XX] old_ccname: [not set] >> keytab: [/etc/krb5.keytab] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_precreate_ccache] >> (0x4000): Recreating ccache >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup_fast] >> (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.fqdn@DOMAIN] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 >> [find_principal_in_keytab] (0x4000): Trying to find principal >> host/server.fqdn@DOMAIN in keytab. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [match_principal] >> (0x1000): Principal matched to the sample (host/server.fqdn@DOMAIN). >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [check_fast_ccache] >> (0x0200): FAST TGT is still valid. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [become_user] >> (0x0200): Trying to become user [339788572][339788572]. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x2000): >> Running as [339788572][339788572]. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x2000): >> Running as [339788572][339788572]. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x0020): >> 2529: [-1765328250][Malformed representation of principal] >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): >> krb5_child_setup failed. >> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): >> krb5_child failed! >> >> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [read_pipe_handler] >> (0x0400): EOF received, client finished >> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] >> [parse_krb5_child_response] (0x0020): message too short. >> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [krb5_auth_done] >> (0x0040): Could not parse child response [22]: Invalid argument >> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [check_wait_queue] >> (0x1000): Wait queue for user [user@domain] is empty. >> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [krb5_auth_queue_done] >> (0x0040): krb5_auth_recv failed with: 22 >> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] >> [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid >> argument >> >> I appreciate your help with this. >> >> Thank you, >> >> Dan Sullivan >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the pr
Re: [Freeipa-users] Malformed representation of principal - krb5_child.log
On Fri, Apr 28, 2017 at 02:54:44PM +, Sullivan, Daniel [CRI] wrote: > HI, > > I haven’t posted in a while, I hope everybody is doing well. I have a > problem that I am having a difficult time diagnosing. To start, I want to > say that we have a pretty large IPA environment. It generally works good. > Most of our servers are of the same flavor RHEL6/7, and pull down their > sssd/IPA RPMs from a standard repo. We also deploy sssd/ipa-client from > SaltStack, so there’s not much variation on configuration. I have a client > that is being very finicky, I am getting a message that says "Malformed > representation of principal” in my krb5_child.log (when trying to log in). > I’m really kind of an ends with the right way to troubleshoot this further. > Here’s what I know; > > 1) I can kinit -k as root > 2) I can kinit user@domain, even for the user in the sssd logs > 3) I’ve blown away /var/lib/sss, deleted /etc/krb*, reinstalled sssd-common, > sssd, & ipa-client. > > My logs are below. Would somebody be able to perhaps provide input on the > best way to further troubleshoot this issue? > > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0400): > krb5_child started. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] > (0x1000): total buffer size: [174] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] > (0x0100): cmd [241] uid [339788572] gid [339788572] validate [true] > enterprise principal [false] offline [false] UPN [user@domain@DOMAIN] There was an issue in an older version of SSSD which saved a wrong UPN in the cache. Please check if the latest version of SSSD for your platform installed, stop SSSD, remove the cache file in /var/lib/sss/db/, start SSSD and try again. If you do not want to remove the cache completely you can use e.g. ldbedit to delete the offending entry individually, search for user@domain@DOMAIN. HTH bye, Sumit > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] > (0x2000): No old ccache > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] > (0x0100): ccname: [FILE:/tmp/krb5cc_339788572_XX] old_ccname: [not set] > keytab: [/etc/krb5.keytab] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_precreate_ccache] > (0x4000): Recreating ccache > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.fqdn@DOMAIN] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 > [find_principal_in_keytab] (0x4000): Trying to find principal > host/server.fqdn@DOMAIN in keytab. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [match_principal] > (0x1000): Principal matched to the sample (host/server.fqdn@DOMAIN). > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [check_fast_ccache] > (0x0200): FAST TGT is still valid. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [become_user] (0x0200): > Trying to become user [339788572][339788572]. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x2000): > Running as [339788572][339788572]. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x2000): > Running as [339788572][339788572]. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x0020): > 2529: [-1765328250][Malformed representation of principal] > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): > krb5_child_setup failed. > (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): > krb5_child failed! > > (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [read_pipe_handler] > (0x0400): EOF received, client finished > (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [parse_krb5_child_response] > (0x0020): message too short. > (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [krb5_auth_done] (0x0040): > Could not parse child response [22]: Invalid argument > (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [check_wait_queue] > (0x1000): Wait queue for user [user@domain] is empty. > (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [krb5_auth_queue_done] > (0x0040): krb5_auth_recv failed with: 22 > (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] > [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid > argument > > I appreciate your help with this. > > Thank you, > > Dan Sullivan > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Malformed representation of principal - krb5_child.log
HI, I haven’t posted in a while, I hope everybody is doing well. I have a problem that I am having a difficult time diagnosing. To start, I want to say that we have a pretty large IPA environment. It generally works good. Most of our servers are of the same flavor RHEL6/7, and pull down their sssd/IPA RPMs from a standard repo. We also deploy sssd/ipa-client from SaltStack, so there’s not much variation on configuration. I have a client that is being very finicky, I am getting a message that says "Malformed representation of principal” in my krb5_child.log (when trying to log in). I’m really kind of an ends with the right way to troubleshoot this further. Here’s what I know; 1) I can kinit -k as root 2) I can kinit user@domain, even for the user in the sssd logs 3) I’ve blown away /var/lib/sss, deleted /etc/krb*, reinstalled sssd-common, sssd, & ipa-client. My logs are below. Would somebody be able to perhaps provide input on the best way to further troubleshoot this issue? (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0400): krb5_child started. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] (0x1000): total buffer size: [174] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] (0x0100): cmd [241] uid [339788572] gid [339788572] validate [true] enterprise principal [false] offline [false] UPN [user@domain@DOMAIN] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] (0x2000): No old ccache (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_339788572_XX] old_ccname: [not set] keytab: [/etc/krb5.keytab] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_precreate_ccache] (0x4000): Recreating ccache (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.fqdn@DOMAIN] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [find_principal_in_keytab] (0x4000): Trying to find principal host/server.fqdn@DOMAIN in keytab. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [match_principal] (0x1000): Principal matched to the sample (host/server.fqdn@DOMAIN). (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [become_user] (0x0200): Trying to become user [339788572][339788572]. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x2000): Running as [339788572][339788572]. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x2000): Running as [339788572][339788572]. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x0020): 2529: [-1765328250][Malformed representation of principal] (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): krb5_child_setup failed. (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): krb5_child failed! (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [parse_krb5_child_response] (0x0020): message too short. (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [check_wait_queue] (0x1000): Wait queue for user [user@domain] is empty. (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22 (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid argument I appreciate your help with this. Thank you, Dan Sullivan -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA integration within enterprise AD domain - ca sub or root?
Hi, We will start setting up IDM/FreeIPA for a specific linux subdomain in our enterprise. The part of setting up a trust is clear: we will be using an external trust - for a selected Active Directory domain But how can we best integrate with the enterprise CA infrastructure (MS Certificate Services)? Is it possible to deploy FreeIPA (dogtag) as rootCA, and to publish requests for public HTTPS certitificates by GlobalSign, or if internal, the MS Certificate Services rootCA? We can still use FreeIPA for all certificates where we need to encrypt end-to-end communication between servers (as example) What about the principle of an offline rootCA in that case? Or is there a specific reason that a subordinate CA is a better idea, signed by the root CA of the MS PKI infrastructure? And if we ask a subordinate CA, is it possible to limit exposure/risks? By setting some extensions? To conclude: own rootCA, or subordinate CA signed by the existing MS Certificate Services PKI Sincerely, Pieter Baele -- 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] Creating another sudo rules full
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! On 04/28/2017 07:26 PM, Jason B. Nance wrote: > Hi Dewangga, > >> [root@idm ~]# ipa sudorule-show sudo_rules_rekanalar Rule name: >> sudo_rules_rekanalar Enabled: TRUE Command category: all RunAs >> User category: all RunAs Group category: all User Groups: >> rekanalar Host Groups: rekanalarservers Sudo Option: >> !authenticate >> >> ## Client [user@server02-v2 ~]$ sudo -l [sudo] password for >> user: > > The rule in your example above only matches users in the group > "rekanalar" on servers in the host group "rekanalarservers". Is > the user "user" in your example in that group and is the host > "server02-v2" in your example in that host group? Yes, usergroup `rekanalar` contain `user`, and `server02-v2` is member of `rekanalarservers` host group. But, if I assign `user` to usergroup `admins`, they can do sudo as root. The goal is, member of usergroup `rekanalar` can do all sudo command in hostgroup `rekanalarservers` only. [root@idm ~]# ipa user-show xxx User login: xxx First name: xxx Last name: [removed] Home directory: /home/xxx Login shell: /bin/bash Principal name: xxx@REALM Principal alias: xxx@REALM Email address: [REMOVED] UID: 1107600016 GID: 1107600016 Job Title: Rekanalar Director SSH public key fingerprint: 51:23:68:4B:BC:17:56:11:50:E1:72:B5:0C:00:B7:B6 xxx (ssh-rsa) Account disabled: False Password: False Member of groups: rekanalar Indirect Member of Sudo rule: sudo_rules_rekanalar Kerberos keys available: False [root@idm ~]# ipa group-show rekanalar Group name: rekanalar GID: 1107600017 Member users: xxx Member of Sudo rule: sudo_rules_rekanalar Am I miss something? > > Regards, > > j > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQI4BAEBCAAiBQJZA0sdGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcND0D/4gJ+MFRuaNX9vfuhZwtXnWGCTfhTZiwWBhp6yniAE1PvCvJ0cT 03kGLzNHTp/EPyysXK/oT8yei09B475UFERxfG2rCdY0AN9aCpOHjxQKgWWFw7LJ 3ntLQNoVEFBqpHoa7fbsBpXiKuonqnt0wV1qCNJKUF8z/62TgdsFUmrO7qjMvUbd FIBCQu2sCZ4Hx4duS8JpHgl9SJSGZkDRJN7XUpnd6bC2+zgUDfkAf74czwbjHQpb yitDmWslG+V3KpZDcbuMFLhNtwOVVavhhEqacqMoMkuEpSHtHk8oF0CvD/YhuiKv WUpzyDzLCx1u7xkRBTSRVRouzOi1WvEZ3JVnWSkFFExOW8SNWjpJhXF5ij4kBRF3 CRuKGys65SJA1HSUtH5eIPvXAYGxP+bJsoy72vyFZcy04+Jql9NRIHIMWZaZLe5Z +qdbhxpBxuCSua1ddMBnGUP/UAmGER0SsxbXq5k6ZjHo9PHwrOlxHZlPyHylbfLr Go1t2phtam410Rv8oMBB+6vO17QWduGZtBpXxSUXP+hvosE72FkLYnn5IOBIrKvC Z0GK1jLFDtMU79JECkjm/wfKywgq9XjcyodG6aMaD2iaVqSWhqfphBHm0nbSnEXz IpDT/WfK0uZkJUaIWYZ3dI7Iv9QCfwwVoWKaKjLkM9ReATti6ks/LYDz8Q== =TP6o -END PGP SIGNATURE- -- 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] I think I lost my CA...
Flo, I did find that issue and made those corrections to our /etc/hosts file, but the problem persists. Thanks for the idea! Bret On 04/27/2017 03:42 AM, Florence Blanc-Renaud wrote: On 04/26/2017 04:33 PM, Bret Wortman wrote: So I can see my certs using cert-find, but can't get details using cert-show or add new ones using cert-request. # ipa cert-find : -- Number of entries returned 385 -- # ipa cert-show 895 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # ipa cert-show 1 (which does not exist) ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # ipa cert-status 895 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # Is this an IPV6 thing? Because ipactl shows everything green and certmonger is running. Hi Bret, the issue looks similar to https://pagure.io/freeipa/issue/6575 and https://pagure.io/dogtagpki/issue/2570 which were IPv6 related. Note that IPv6 must be enabled on the machine but IPA does not require an IPv6 address to be configured (except for the loopback). You can check the following: - is PKI listening to port 8009 on IPv6 or IPv4 interface? sudo netstat -tunpl | grep 8009 tcp6 0 0 127.0.0.1:8009 :::* LISTEN 10749/java - /etc/pki/pki-tomcat/server.xml defines a redirection from port 8009 to 8443, and the "address" part is important: In the above example, it will be using localhost which can resolve either to IPv4 or IPv6. - /etc/hosts must define the loopback addresses with 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 HTH, Flo. Bret On 04/26/2017 09:03 AM, Bret Wortman wrote: Digging still deeper: # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) Looks like this is an HTTP error; so is it possible that my IPA thinks it has a CA but there's no CMS available? On 04/26/2017 08:41 AM, Bret Wortman wrote: Using the firefox debugger, I get these errors when trying to pop up the New Certificate dialog: Empty string passed to getElementById(). (5) jquery.js:4:1060 TypeError: u is undefined app.js:1:362059 Empty string passed to getElementById(). (5) jquery.js:4:1060 TypeError: t is undefined app.js:1:217432 I'm definitely not a web kind of guy so I'm not sure if this is helpful or not. This is on 4.4.0, API Version 2.213. Bret On 04/26/2017 08:35 AM, Bret Wortman wrote: Good news. One of my servers _does_ have CA installed. So why does "Action -> New Certificate" not do anything on this or any other server? Bret On 04/25/2017 02:52 PM, Bret Wortman wrote: I recently had to upgrade all my Fedora IPA servers to C7. It went well, and we've been up and running nicely on 4.4.0 on C7 for the past month or so. Today, someone came and asked me to generate a new certificate for their web server. All was good until I went to the IPA UI and tried to perform Actions->New Certificate, which did nothing. I tried each of our 3 servers in turn. All came back with no popup window and no error, either. I suspect the problem might be that we no longer have a CA server due to the method I used to upgrade the servers. I likely missed a "--setup-ca" in there somewhere, so my rolling update rolled over the CA. What's my best hope of recovery? I never ran this before, so I'm not sure if this shows that I'm missing a CA or not: # ipa ca-find 1 CA matched Name: ipa Description IPA CA Authority ID: 3ce3346[...] Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM Number of entries returned 1 # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, O=DAMASCUSGRP.COM" ipa: ERROR: Failed to authenticate to CA REST API # klist Ticket cache: KEYRING:persistent:0:0 Default principal: ad...@damascusgrp.com Valid starting Expires Service principal 04/25/2017 18:48:26 04/26/2017 18:48:21 krbtgt/damascusgrp@damascusgrp.com # What's my best path of recovery? -- *Bret Wortman* The Damascus Group -- 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] Creating another sudo rules full
Hi Dewangga, > [root@idm ~]# ipa sudorule-show sudo_rules_rekanalar > Rule name: sudo_rules_rekanalar > Enabled: TRUE > Command category: all > RunAs User category: all > RunAs Group category: all > User Groups: rekanalar > Host Groups: rekanalarservers > Sudo Option: !authenticate > > ## Client > [user@server02-v2 ~]$ sudo -l > [sudo] password for user: The rule in your example above only matches users in the group "rekanalar" on servers in the host group "rekanalarservers". Is the user "user" in your example in that group and is the host "server02-v2" in your example in that host group? Regards, j -- 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] List SPAM
Yes, I am aware of the workarounds, and went through the exact same steps that you mentioned several times. This is clearly not a solution. Can someone from the team comment on why email addresses are published in the first place ? I do not see any advantages and plenty of disadvantages. Spam notwithstanding, I am not a big fan of the email being published at all. On Thu, Apr 27, 2017 at 11:10 PM, Lachlan Musicman wrote: > On 24 April 2017 at 12:24, Prasun Gera wrote: > >> That doesn't work very well. The spam bots use different emails. And >> gmail marks the entire message thread as spam, not just the spam reply. >> >> On Sun, Apr 23, 2017 at 7:20 AM, Dewangga Bachrul Alam < >> dewangg...@xtremenitro.org> wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> Mark as spam, and they gone from my inbox. :) >>> >>> > > > If you are using gmail: > > - block the email address > - mark the message as spam (not the thread) > - you can then delete the message in question > > > Note that this can still cause issues wrt workplace and SFW images, as > Gmail automatically "previews" images. > > I leave them to deal with at home and have reported the problem to my > manager and IT team so they know it's not my fault - as both acknowledge > and understand that this forum has been very valuable to us wrt getting > things working. > > L. > > > > -- > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -- 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 trust between FreeIPA and Samba AD DC
Hello, I set up a fresh Windows Server 2012R2 instance, configured a new forest named 'clients.rdmedia.com' and I'm getting the same error in the httpd error_log after running 'ipa trust-add clients.rdmedia.com --type=ad --admin=Administrator --password': [Fri Apr 28 12:05:00.420174 2017] [:error] [pid 26417] ipa: ERROR: non-public: RuntimeError: (-1073741811, 'Unexpected information received') [Fri Apr 28 12:05:00.420225 2017] [:error] [pid 26417] Traceback (most recent call last): [Fri Apr 28 12:05:00.420230 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 366, in wsgi_execute [Fri Apr 28 12:05:00.420235 2017] [:error] [pid 26417] result = command(*args, **options) [Fri Apr 28 12:05:00.420239 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 449, in __call__ [Fri Apr 28 12:05:00.420243 2017] [:error] [pid 26417] return self.__do_call(*args, **options) [Fri Apr 28 12:05:00.420247 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 477, in __do_call [Fri Apr 28 12:05:00.420251 2017] [:error] [pid 26417] ret = self.run(*args, **options) [Fri Apr 28 12:05:00.420255 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 799, in run [Fri Apr 28 12:05:00.420258 2017] [:error] [pid 26417] return self.execute(*args, **options) [Fri Apr 28 12:05:00.420262 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 739, in execute [Fri Apr 28 12:05:00.420267 2017] [:error] [pid 26417] result = self.execute_ad(full_join, *keys, **options) [Fri Apr 28 12:05:00.420297 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 989, in execute_ad [Fri Apr 28 12:05:00.420304 2017] [:error] [pid 26417] trust_type [Fri Apr 28 12:05:00.420308 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1683, in join_ad_full_credentials [Fri Apr 28 12:05:00.420312 2017] [:error] [pid 26417] trust_type, trust_external) [Fri Apr 28 12:05:00.420316 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1363, in establish_trust [Fri Apr 28 12:05:00.420320 2017] [:error] [pid 26417] self.update_ftinfo(another_domain) [Fri Apr 28 12:05:00.420324 2017] [:error] [pid 26417] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1252, in update_ftinfo [Fri Apr 28 12:05:00.420328 2017] [:error] [pid 26417] ftinfo, 0) [Fri Apr 28 12:05:00.420331 2017] [:error] [pid 26417] RuntimeError: (-1073741811, 'Unexpected information received') [Fri Apr 28 12:05:00.420975 2017] [:error] [pid 26417] ipa: INFO: [jsonserver_session] ad...@i.rdmedia.com: trust_add/1(u'clients.rdmedia.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'', version=u'2.213'): RuntimeError Am I doing something wrong? Logs are ofcourse available privately on request. On 14 April 2017 at 15:13, Alexander Bokovoy wrote: > On pe, 14 huhti 2017, Tiemen Ruiten wrote: > >> Yes, office.rdmedia.com is the Samba AD domain. >> >> [root@fluorine samba]# samba-tool domain trust list >> Type[Forest] Transitive[Yes] Direction[INCOMING] Name[i.rdmedia.com] >> [root@fluorine samba]# samba-tool domain trust show i.rdmedia.com >> LocalDomain Netbios[OFFICE] DNS[office.rdmedia.com] >> SID[S-1-5-21-482924559-3201240232-3198541477] >> TrusteDomain: >> >> NetbiosName:IPA >> DnsName:i.rdmedia.com >> SID:S-1-5-21-3716778977-2487905546-4034507762 >> Type: 0x2 (UPLEVEL) >> Direction: 0x1 (INBOUND) >> Attributes: 0x8 (FOREST_TRANSITIVE) >> PosixOffset:0x (0) >> kerb_EncTypes: 0x1c >> (RC4_HMAC_MD5,AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96) >> Namespaces[0] TDO[i.rdmedia.com]: >> > Ok, thanks. I'll look into this part of Samba code later, after Easter. > > > >> >> On 14 April 2017 at 14:07, Alexander Bokovoy wrote: >> >> On pe, 14 huhti 2017, Tiemen Ruiten wrote: >>> >>> Hello Alexander, That's strange, when I try to setup a trust with a domain that isn't a subdomain of FreeIPA, I get the same error. I reran: ipa-adtrust-install --netbios-name=IPA and then ran: ipa trust-add --type=ad office.rdmedia.com --admin Administrator --password office.rdmedia.com is Samba AD? >>> >>> Then please show output of >>> >>> samba-tool domain trust list >>> >>> and for each domain name in the output above show >>> >>> samba-tool domain trust show >>> >>> >>> >>> >>> >>> Last bit of the error_log: rpc reply data: [] 00 00 00 00 lsa_lsaRSetForestTrustInformation: struct lsa_lsaRSetForestTrustInformation in: struct lsa_lsaRSetForestTrustInformation handle : *
Re: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s)
On 04/28/2017 03:50 AM, Dewangga Bachrul Alam wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! On 04/26/2017 08:08 PM, Florence Blanc-Renaud wrote: On 04/25/2017 10:56 AM, Dewangga Bachrul Alam wrote: Hello! Master IPA Server: - I install 1 (one) server as master (self-signed) and add/modify using external CA. - I am using ipa-cacert-manage install then ipa-certupdate on master Hi, I think I got you wrong... Do you mean that you installed IPA with an integrated IdM CA which was self-signed, then your intent was to move to integrated IdM CA externally signed? In this case, the right command would be ipa-cacert-manage renew --external-ca, and the procedure is described in "Changing the certificate chain" [1]. Ah thanks for your corrections and information, then what should I do? Should I run ipa-cacert-manage renew --external-ca ? Yes, this is the way to go, documented here [1]. This is a 2-step process: when the command is run, it will create a CSR that needs to be signed by an external CA. Then the command must be re-launched with the new certificate delivered by the CA. Also do not forget to run ipa-certupdate on the master and all the replicas/clients. Flo. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext The command ipa-cacert-manage install does not replace the integrated IdM CA but adds the certificate as a known CA. Hope this clarifies, Flo [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-ce rt-chaining.html Replica IPA Server: - I install 1 (one) server as client and promoted to ipa-replica: - I run `ipa-client-install` and autodiscovery - Then `ipa-replica-install --principal admin --admin-password ` I've hit ipa-certupdate -v to verbose the logs (attached at first email). Then replica server aren't using external CA(s) like master did. So, I did the same like master, using `ipa-cacert-manage` on replica, and it's work fine. If it's normal, then thanks for clarifying this. On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote: Hi, As your email refers to self-signed and signed CA certificate, can you please clarify the exact steps that you followed? It looks like - you first installed FreeIPA with a self-signed CA - you added an external CA (did you use ipa-cacert-manage install on 1 server then ipa-certupdate on all replicas?) - you replaced the httpd/LDAP certificates with a cert signed from the external CA (you probably ran ipa-server-certinstall on one server). In this case it is normal that the httpd/LDAP certificates on the replica were not updated as they are different (each IPA server has his own httpd/LDAP cert which contains the hostname in its subject). You can check this by performing on each server: ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert | grep Subject: Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM" ^ If the goal is to replace the httpd/LDAP certificates on the replica, the command ipa-server-certinstall must also be run on the replica with the appropriate certificate. HTH, Flo. On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello! Just update, manually add external CA(s) and signed certificated was successful, but why it's didn't automatically transferred to replica(s) from master. On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote: Hello! I've successfully create replica, everything works fine but why my signed CA certificate didn't automatically transfer to another replica(s)? Is it normal? Trying to add manually, but the certificate in replica(s) still using self-signed. Here's the output from `ipa-certupdate -v` https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1U NdI GYh yR LivL9gydE= Interesting line was : ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found ipa: DEBUG: Starting external process ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA cert -a ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert : PR_FILE_NOT_FOUND_ERROR: File not found FYI: The replica server previously was a client and promoted to be a replica by hitting this command: `ipa-replica-install --principal admin --admin-password admin_password` Any hints? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQI4BAEBCAAiBQJZAp/fGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl f9IgoCjNcFhED/0VncBpnHq9jTIjQCel6wpqITpob3CeqtFMKFvx9gl6/7jKzkbO 1sNr8qcvB2Hne9mp41EDXhQw9ZLxNHTqt6JOAzdGFGO3qwsIH+l8V0pNX2knnsSw b2MEhNmftKO
