October 2018 - FreeIPA-users - Fedora mailing-lists

DNs forwaders
by Andrew Meyer 31 Oct '18

31 Oct '18

I have configured DNS forwarders in each of my FreeIPA servers. However I want to be able to go back and verify they are there. I can't remember how to get that information. I am running CentOS 7 latest with FreeIPA version 4.5.0. I want to say there is an LDAP command I found. This is not for global forwarders. Thanks!

2 3

Testing requested - certificate checking tool
by Rob Crittenden 30 Oct '18

30 Oct '18

As part of a larger IPA "health" checker and driven largely by necessity I have the beginning of a certificate checking tool available at https://github.com/rcritten/checkcerts It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+ patches). YMMV. There is not much of a user-friendly interface to it. There are only two options, debug and verbose, which increase the amount of debug output (and it is immense). The UI is limited because I expect it to be rolled up into some larger tool at some point and don't want to have to throw away a ton of framework code. It needs to be run on an IPA master and checks the things I thought of to check. I've only done limited testing on mostly brand new installs so I'd appreciate feedback. Don't freak out of it spits out errors as it could just be bugs on my part :-) It is read-only so it shouldn't blow up anything. So if you want to run it against your system and send me the any output I can try to figure out if it is my tool that is the issue or your system (it is supposed to help pro-actively diagnose issues after all). To use just clone it from git (or download ipa-checkcerts.py from the repo) Run it as root: # kinit admin # python ipa-checkcerts.py IPA version 4.5.4-10.el7_5.3 Check CA status Check tracking Check NSS trust Check dates Checking certificates in CS.cfg Comparing certificates to requests in LDAP Checking RA certificate Checking authorities Checking host keytab Validating certificates Checking renewal master End-to-end cert API test Checking permissions and ownership All checks passed thanks rob

5 14

Service Account vs System Account vs User Account
by Ryan Slominski 30 Oct '18

30 Oct '18

It is not always clear the best way to create an account for a script or application to use. Generally this special type of account has no password expiration (or a very long expiration window). For example, some applications require a bind user to connect to LDAP. It seems there are a half a dozen ways to do it. When should each be used? Here are the options I'm aware of: 1. Create IPA Service (ipa service-add) My understanding is an IPA Service cannot reveal the plaintext password (keytab only) and must be tied to a single host. This doesn't work when the bind user password plaintext must be known (unless I missed that somewhere). Also, you can't assign a service to the "admins" user group, which is a special user group - so if you want a "root-like" service you can't use an IPA service (maybe you could cobble together some roles that mostly did what admins members get). 2. Create IPA User (ipa user-add) There are few ways to make a special password expiration (not clear which is best): A. You can use a special password policy where the password doesn't expire for a very long time (must be done before setting password). B. Use kadmin.local to set password expiration to never (or a very long time). C. Use ldapmodify (dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com) to set expiration to a very long time D. If you never set a password, but execute the ipa getkeytab command then there doesn't appear to be any expiration on the user account password (though web interface says there is no password so not sure if this is a bug or what) 3. Create LDAP System Account (ldapmodify - dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com) This seems like a back door and only works if your "application account" needs LDAP, but not Kerberos. Account does not show up in the web interface anywhere. See: https://www.freeipa.org/page/HowTo/LDAP 4. Create Kerberos Service (kadmin.local addprinc) Probably no need to ever use kadmin.local to create a service? Then again, maybe there is?

2 4

Is IPA secure enough for public exposure plus trust management issue
by William Muriithi 29 Oct '18

29 Oct '18

Hello, I am looking for a way of allowing users to reset their password without going through the VPN. I usually send users notification when the password are about to expire, but they don't follow up until something stop working. At that point, they can't even VPN. Have anyone else exposed IPA to the public and have it faired well? Also, is there a way of changing one way trust (The default) to two way trust without first removing the current trust? Regards, William

3 2

Replica load balancing and priority without DNS SRV
by Ryan Slominski 29 Oct '18

29 Oct '18

FreeIPA allows disabling DNS Autodiscovery by explicitly listing the host names of FreeIPA servers. However, it isn't clear if the order of host names matters. For example: ipa-client-install --server firsthostname.example.com --server secondhostname.example.com Is the first host name I list the one that will always be consulted first? Or does SSSD attempt to use whichever one responds to a ping faster? I have not configured any DNS SRV records.

2 2

FreeIPA Plugin Development
by Yuri Krysko 29 Oct '18

29 Oct '18

Hi, We are looking to develop several custom plugins for FreeIPA. Could anyone please advise on any documentation guidelines on FreeIPA plugin development? Thanks, Yuri ________________________________ LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail and any files transmitted with it to be protected, proprietary or privileged information intended solely for the use of the named recipient(s). Any disclosure of this material or the information contained herein, in whole or in part, to anyone outside of the intended recipient or affiliates is strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of the information contained in it, unless that information is subsequently confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to infringe on any rights of the recipient; any such communication violates company policy. If you are not the intended recipient, any disclosure, copying, distribution, or action taken or omitted in reliance on this information is strictly prohibited by M.C. Dean, Inc.; please notify the sender immediately by return e-mail, delete this communication and destroy all copies.

3 2

IPA sub-CAs; cleaning up spurious Dogtag LWCA entries
by Fraser Tweedale 29 Oct '18

29 Oct '18

Hi Rob, (Cc freeipa-users@ for visibility) On Mon, Oct 22, 2018 at 04:12:05PM -0400, Rob Crittenden wrote: > I've gotten some upstream feedback on my cert checking tool and one user > came back with a bunch of errors: > > Error looking up CA entry in IPA aeca4a88-630d-4f47-9585-73bad089260b: > no matching entry found > Error looking up CA entry in IPA d8a6fe60-eebe-4dfd-8352-47ca38a29028: > no matching entry found > Error looking up CA entry in IPA 3203c388-7da5-44d3-923b-dd87a3a62ecb: > no matching entry found > Error looking up CA entry in IPA f875b832-16cb-4b08-bc8c-1dbef027d101: > no matching entry found > Error looking up CA entry in IPA 2e18e695-55c3-4675-a7f2-84e6b2726893: > no matching entry found > Error looking up CA entry in IPA 327f1d40-cf4f-4a6a-95b1-3ba88b725e5f: > no matching entry found > Error looking up CA entry in IPA 21288a66-d4c2-48d2-9901-a464cd926681: > no matching entry found > > So these UUID come from ou=authorities, ou=ca, o=ipaca and the > equivalent doesn't exist in IPA. Is that by default a problem or is it > perfectly valid? > > How would you recommend debugging this further? > > thanks > > rob It could be an occurrence of https://pagure.io/dogtagpki/issue/2475 / https://bugzilla.redhat.com/show_bug.cgi?id=1390322 which resulted in the creation of a new lightweight CA (LWCA) entry for the host/primary CA each time Dogtag started. The issue was fixed a while ago but we didn't do anything to clean up the spurious entries. To confirm that this is the issue, check if the extra entries have the same 'authorityDN' attribute. If confirmed the resolution is: 1. find the IPA CA authority ID (`ipa ca-show ipa`) 2. find all the Dogtag LWCA entries with the same subject DN 3. keep the one with the authority ID matching IPA (from step 1) and delete the others Cheers, Fraser

2 2

Re: FreeIPA stops working on nodes ... need help debugging.
by Rob Crittenden 26 Oct '18

26 Oct '18

Jeff wrote: > Thanks for the hint. The master replica server was having issues. It's > been updated and is running now. The question I have now is why would > it stop working if the other two replicas were still functioning, > especially since a reinstall of the client seems to fix it? It probably depends on how the client was original configured (whether your client was using DNS discovery). I imagine it wasn't so SSSD didn't have, or couldn't find, another master to fall back on. rob > > On Thu, Oct 25, 2018 at 12:13 PM Rob Crittenden <rcritten(a)redhat.com > <mailto:rcritten@redhat.com>> wrote: > > Jeff Vincent via FreeIPA-users wrote: > > I inherited the management of our FreeIPA instance (master + 2 > replicas). Most of our clients are running Ubuntu 14.04 or > greater. It is becoming an issue where only cached credentials > will work and any new users are unable to log in. > > > > So far in all cases, if I unconfigure freeipa ('ipa-client-install > --uninstall') and then reinstall (using the --force-join) option, it > starts working again. However, I want to get to the bottom of why > it is happening so frequently. It's hard to pinpoint to a specific > time because the cached credentials work for a while. > > > > I've added: > > > > debug_level = 0x3ff0 > > > > to my /etc/sssd/sssd.conf file. Once I restart sssd, it seems to > show that it is 'off-line'. I've tried the following: > > > > - verified DNS is working and all 3 ipa server nodes can be resolved > > - verified the client 'hostname' is fully qualified > > - verified time is in sync > > > > I see this error a lot in the /var/log/syslog, but I also see it > on systems that work: > > Oct 25 17:37:41 server [sssd[ldap_child[26118]]]: Failed to > initialize credentials using keytab [default]: Generic error (see > e-text). Unable to create GSSAPI-encrypted LDAP connection. > > Oct 25 17:37:41 server [sssd[ldap_child[26118]]]: Generic > error (see e-text) > > > > I see this in the /var/log/sssd/ldap_child.log: > > (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] > [ldap_child_get_tgt_sync] (0x2000): Kerberos context initialized > > (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] > [ldap_child_get_tgt_sync] (0x2000): got realm_name: > [WP.MYCOMPANY.COM <http://WP.MYCOMPANY.COM>] > > (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] > [ldap_child_get_tgt_sync] (0x0100): Principal name is: > [host/server.mycompany.com(a)WP.MYCOMPANY.COM > <mailto:server.mycompany.com@WP.MYCOMPANY.COM>] > > (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] > [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] > > (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] > [ldap_child_get_tgt_sync] (0x2000): keytab ccname: > [FILE:/var/lib/sss/db/ccache_WP.MYCOMPANY.COM_EhCBvz] > > (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] > [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > > (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: > Generic error (see e-text) > > > > The contents of /var/log/sssd/krb5_child.log > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [main] > (0x0400): krb5_child started. > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [unpack_buffer] (0x1000): total buffer size: [136] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [unpack_buffer] (0x0100): cmd [241] uid [718000010] gid [718000010] > validate [true] enterprise principal [false] offline [false] UPN > [jeff.vincent(a)WP.MYCOMPANY.COM <mailto:jeff.vincent@WP.MYCOMPANY.COM>] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [unpack_buffer] (0x0100): ccname: > [FILE:/tmp/krb5cc_718000010_5IZeI7] keytab: [/etc/krb5.keytab] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] > from environment. > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > [true] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/server.mycompany.com(a)WP.MYCOMPANY.COM > <mailto:server.mycompany.com@WP.MYCOMPANY.COM>] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [match_principal] (0x1000): Principal matched to the sample > (host/server.mycompany.com(a)WP.MYCOMPANY.COM > <mailto:server.mycompany.com@WP.MYCOMPANY.COM>). > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > [true] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [get_and_save_tgt_with_keytab] (0x0020): 936: [-1765328324][Generic > error (see e-text)] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [check_fast_ccache] (0x0020): get_and_save_tgt_with_keytab failed. > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [k5c_setup_fast] (0x0020): check_fast_ccache failed. > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] > [k5c_setup_fast] (0x0020): 1812: [-1765328324][Generic error (see > e-text)] > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [main] > (0x0020): krb5_child_setup failed. > > (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [main] > (0x0020): krb5_child failed! > > > > It *seems* to be kerberos related, but I have little working > knowledge of kerberos. > > > > Searches hinted at manually trying the kinit: > > > > root@server:/var/log/sssd# kinit -V my.user > > Using default cache: /tmp/krb5cc_718000010_5IZeI7 > > Using principal: my.user(a)WP.MYCOMPANY.COM > <mailto:my.user@WP.MYCOMPANY.COM> > > kinit: Generic error (see e-text) while getting initial > credentials > > > > So the error seems consistent. I don't know where to go from here. > > > > Any help is much appreciated. > > Look in the KDC log on the IPA master(s) (/var/log/krb5kdc.log on > RHEL/Fedora) for clues. > > rob >

1 0

Is IPA-AD two-way trust really two-way?
by Michal Sladek 26 Oct '18

26 Oct '18

Hello, I would like to use IPA server in heterogeneous environment with Linux servers and Windows workstations. IPA domain would be used as a primary source of users and groups. AD domain would be used for management of Widows hosts only (group policies etc.). I have setup a test network with two-trust between AD and IPA domain and realized, that IPA domain sees AD users but AD domain doesn't see IPA users. Am I missing something or the two-way trust is not two-way in fact? SW used: CentOS 7.5 - IPA server and IPA domain member Windows Server 2016 Standard - AD server Windows 10 Pro - AD domain member Best regards Michal

3 5

FreeIPA stops working on nodes ... need help debugging.
by Jeff Vincent 25 Oct '18

25 Oct '18

I inherited the management of our FreeIPA instance (master + 2 replicas). Most of our clients are running Ubuntu 14.04 or greater. It is becoming an issue where only cached credentials will work and any new users are unable to log in. So far in all cases, if I unconfigure freeipa ('ipa-client-install --uninstall') and then reinstall (using the --force-join) option, it starts working again. However, I want to get to the bottom of why it is happening so frequently. It's hard to pinpoint to a specific time because the cached credentials work for a while. I've added: debug_level = 0x3ff0 to my /etc/sssd/sssd.conf file. Once I restart sssd, it seems to show that it is 'off-line'. I've tried the following: - verified DNS is working and all 3 ipa server nodes can be resolved - verified the client 'hostname' is fully qualified - verified time is in sync I see this error a lot in the /var/log/syslog, but I also see it on systems that work: Oct 25 17:37:41 server [sssd[ldap_child[26118]]]: Failed to initialize credentials using keytab [default]: Generic error (see e-text). Unable to create GSSAPI-encrypted LDAP connection. Oct 25 17:37:41 server [sssd[ldap_child[26118]]]: Generic error (see e-text) I see this in the /var/log/sssd/ldap_child.log: (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] [ldap_child_get_tgt_sync] (0x2000): Kerberos context initialized (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [WP.MYCOMPANY.COM] (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/server.mycompany.com(a)WP.MYCOMPANY.COM] (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_WP.MYCOMPANY.COM_EhCBvz] (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals (Thu Oct 25 17:40:22 2018) [[sssd[ldap_child[26163]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Generic error (see e-text) The contents of /var/log/sssd/krb5_child.log (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [main] (0x0400): krb5_child started. (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [unpack_buffer] (0x1000): total buffer size: [136] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [unpack_buffer] (0x0100): cmd [241] uid [718000010] gid [718000010] validate [true] enterprise principal [false] offline [false] UPN [jeff.vincent(a)WP.MYCOMPANY.COM] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_718000010_5IZeI7] keytab: [/etc/krb5.keytab] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.mycompany.com(a)WP.MYCOMPANY.COM] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [match_principal] (0x1000): Principal matched to the sample (host/server.mycompany.com(a)WP.MYCOMPANY.COM) (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [get_and_save_tgt_with_keytab] (0x0020): 936: [-1765328324][Generic error (see e-text)] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [check_fast_ccache] (0x0020): get_and_save_tgt_with_keytab failed. (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [k5c_setup_fast] (0x0020): check_fast_ccache failed. (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [k5c_setup_fast] (0x0020): 1812: [-1765328324][Generic error (see e-text)] (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [main] (0x0020): krb5_child_setup failed. (Thu Oct 25 17:30:35 2018) [[sssd[krb5_child[26037]]]] [main] (0x0020): krb5_child failed! It *seems* to be kerberos related, but I have little working knowledge of kerberos. Searches hinted at manually trying the kinit: root@server:/var/log/sssd# kinit -V my.user Using default cache: /tmp/krb5cc_718000010_5IZeI7 Using principal: my.user(a)WP.MYCOMPANY.COM kinit: Generic error (see e-text) while getting initial credentials So the error seems consistent. I don't know where to go from here. Any help is much appreciated. -Jeff

2 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users October 2018