DNs forwaders
by Andrew Meyer
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!
5 years, 4 months
Testing requested - certificate checking tool
by Rob Crittenden
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 years, 5 months
Service Account vs System Account vs User Account
by Ryan Slominski
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?
5 years, 5 months
Is IPA secure enough for public exposure plus trust management issue
by William Muriithi
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
5 years, 5 months
Replica load balancing and priority without DNS SRV
by Ryan Slominski
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.
5 years, 5 months
FreeIPA Plugin Development
by Yuri Krysko
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.
5 years, 5 months
IPA sub-CAs; cleaning up spurious Dogtag LWCA entries
by Fraser Tweedale
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
5 years, 5 months
Re: FreeIPA stops working on nodes ... need help debugging.
by Rob Crittenden
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
>
5 years, 5 months
Is IPA-AD two-way trust really two-way?
by Michal Sladek
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
5 years, 5 months
FreeIPA stops working on nodes ... need help debugging.
by Jeff Vincent
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
5 years, 5 months