March 2020 - FreeIPA-users - Fedora Mailing-Lists

FreeIPA Diskless Client Issues with sssd ssh

by Mark L. Potter

Greetings, I am implementing FreeIPA in a large environment ro replace OpenLDAP. I have the initial client configuration scripted as the machines are diskless and almost everything is working properly. However I cannot seem to FreeIPA managed user ssh keys working with sssd. I have been reading for a couple of days and haven't found the answer as of yet. Here is what I have discerned to be pertinent information. I will gladly add anything else that's necessary. When 'sss_ssh_authorizedkeys markp --debug 10' produces no output at all and no errors. I cannot ssh between hosts without entering a password or using authorized_keys. 'journalctl -u sssd' shows: Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 1 Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 1 Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 1 Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 2 OS: CentOS 7.4 Packages: ipa-client-4.6.5-11.el7.centos.4.x86_64 sssd-1.16.4-21.el7_7.1.x86_64 sssd.conf: [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = host.example.com chpass_provider = ipa ipa_server = ipaserver.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] config_file_version = 2 services = nss, sudo, pam, ssh domains = example.com [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] [secrets] [session_recording] openldap/ldap.conf # File modified by ipa-client-install TLS_CACERTDIR /etc/openldap/certs # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on URI ldaps://ipaserver.example.com BASE dc=dugeo,dc=com TLS_CACERT /etc/ipa/ca.crt SASL_MECH GSSAPI krb5.conf #File modified by ipa-client-install includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false dns_canonicalize_hostname = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] EXAMPLE.COM = { kdc = ipaserver.example.com:88 master_kdc = ipaserver.example.com:88 admin_server = ipaserver.example.com:749 kpasswd_server = ipaserver.example.com:464 default_domain = example.com pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM host.example.com = EXAMPLE.COM I am hoping there's something simple that I am missing here, something I've overlooked or managed to just suck at library skills. Thanks in advance for any help.

4 years, 1 month

3
4
0 / 0

Debian client browsers don't trust root cert after ipa-client-install

by Nicholas DeMarco

Hello, Thanks to this group's help, I'm learning my way through IPA's certificate system. I read Fraser's well written post on creating sub-CAs, and successfully got everything to work. I then ran into the same problem Kevin Vasko hit in this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... It seems Debian-based Chrome and Firefox don't implicitly trust the OS root certificate store. For each Firefox profile (about:profiles), the NSS db is in ~/.mozilla/firefox/<profile>. The certs in this directory can be listed certutil -d sql:/home/nick/.mozilla/firefox/4sar5x5s.default-release/ -L On Ubuntu 18.04, after installing and configuring IPA client (# ipa-client-install --mkhomedir), the IPA certificate is listed in the store. Still, Firefox doesn't trust the IPA server or its trusted hosts. Why??? It's been established that Linux Firefox and Linux Chrome don't trust the OS trusted certificate stores. It seems, with all that comes with assumptions, that Firefox doesn't trust its own profile store, either. Nick

4 years, 1 month

2
3
0 / 0

A Debian Head-Scratcher

by White, Daniel E. (GSFC-770.0)[NICS]

Server: RHEL 7 IdM, ipa-server-4.6.5-11.el7_7.4.x86_64 Client: Debian 10, freeipa-client 4.7.2-3 amd64 Is this version difference a show stopper ? It sorta-kinda-mostly works. I created a test user to test the HBAC rules, and I cannot ssh into this Debian server as this test user. I can ssh in as me, but my login has admin permissions. I can ssh into a CentOS 7 and a RHEL 7 client as "test_user" I tried "su - test_user" and got "sh: Authentication failure" Any suggestions ? I am a novice at Debian. Most of my experience is with Red Hat/CentOS ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290

4 years, 1 month

2
1
0 / 0

How to make ipa root certificate available system wide

by Kevin Vasko

Hello, I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate. I think I’m pretty close but I’m missing a small part. The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt. I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly. On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser. That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted. If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified. So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically? when we enroll a host we simply do freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing? -Kevin

4 years, 1 month

6
14
0 / 0

sshd.config overwriten during FIRST ipa-client-installation

by pgb205

1. Happens on RHEL/Centos only(other distros are not affected) 2. Happens only during the first attempted install of ipa-client package. If we try to reinstall the sshd.conf is not modified.3. We tried with --no-sshd flag to prevent sshd configuration as suggested in the following ticket [Freeipa-devel] [PATCH] 85 Add --no-ssh option to ipa-client-install to We no longer get an messages in /var/log/ipaclientinstall.log about sshd.conf being backed up, BUT the file still gets changed.

4 years, 1 month

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users March 2020