October 2019 - FreeIPA-users - Fedora mailing-lists

Re: Can't resolve external users on clients, but I can on servers
by TOULMONDE Sébastien (SPC/DCS) 29 Oct '19

29 Oct '19

Hi Sumit, I'll try to search if there's any duplicates, but it seems unlikely... Nevertheless - this bug is only hit when the domain search order is null? Thanks, Seb. This e-mail cannot be used for other purposes than Proximus business use. See more on https://www.proximus.be/maildisclaimer

2 1

Re: Can't resolve external users on clients, but I can on servers
by TOULMONDE Sébastien (SPC/DCS) 29 Oct '19

29 Oct '19

Ok, so here’s the solution I found almost by accident… If I specify the domain search order to ‘ad.domain:ipa.domain’ -> the clients can now resolve the external users If, for whatever reason, the search order is empty, the clients are back to ipa-only resolve… Hope it helps someone 😊 Sébastien Toulmonde Linux Engineering | ITS Linux CC M +32 (0)475 49 81 45 [Proximus]<http://www.proximus.be/> Connect with us on: [Proximus Facebook]<https://www.facebook.com/proximusBe> [Proximus Twitter] <https://twitter.com/proximus> [Proximus YouTube] <https://www.youtube.com/proximus> [Proximus LinkedIn] <https://www.linkedin.com/company/proximus> This e-mail cannot be used for other purposes than Proximus business use. See more on https://www.proximus.be/maildisclaimer

2 1

Full Server backup fails with IPA version error
by Saurabh Garg 29 Oct '19

29 Oct '19

Background - We are trying to restore "full server" from an existing IPA server (with replication ON to another server) to a newly created IPA Server from the same golden image as all other servers. Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo) # ipa-server-install --version 4.6.4 Destination IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo) # ipa-server-install --version 4.6.4 Problem Statement - While running "ipa-restore" (exact command: # ipa-restore /root/backup/) on the new IPA server for full server backup, system throws the following error lines in iparestore.log: 2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to be upgraded (expected version '4.6.4-10.el7_6.6', current version '4.6.4-10.el7_6.3') Automatically running upgrade, for details see /var/log/ipaupgrade.log Be patient, this may take a few minutes. Automatic upgrade failed: Update complete Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] Publish directory already set to new location [Verifying that CA proxy configuration is correct] IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. CA did not start in 300.0s The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade again Aborting ipactl 2019-10-25T08:19:26Z INFO Restoring umask to 23 2019-10-25T08:19:26Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_restore.py", line 428, in run run(['ipactl', 'start']) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run raise CalledProcessError(p.returncode, arg_string, str(output)) 2019-10-25T08:19:26Z DEBUG The ipa-restore command failed, exception: CalledProcessError: Command 'ipactl start' returned non-zero exit status 1 2019-10-25T08:19:26Z ERROR Command 'ipactl start' returned non-zero exit status 1 2019-10-25T08:19:26Z ERROR The ipa-restore command failed. See /var/log/iparestore.log for more information In case you are aware of its fix/workaround, kindly share the steps. Thanks, sgarg

3 4

DNS - IPA masters' own PTR records in a classless subnet
by lejeczek 29 Oct '19

29 Oct '19

2 5

Re: Full Server backup fails with IPA version error
by Saurabh Garg 29 Oct '19

29 Oct '19

Thanks Angus for the reply. In my case, original IPA server is completely damaged / deleted, and now I am attempting to create an exactly similar server using "full-server" backup. Do you have any suggestions for such a scenario? Thanks sgarg On Fri, Oct 25, 2019 at 6:05 PM Angus Clarke <post(a)angusclarke.com> wrote: > Hi > > An alternative approach would be to setup your new server as an IPA client > and then to promote it. > > On new server: > # ipa-client-install > > Followed by > # ipa-replica-install > > Check the man pages for options suitable to your environment, otherwise I > specify --setup-ca for all our new IPA instances. > > I use this process for rolling out new IPA servers when we add new > environments. > > Regards > Angus > > ------------------------------ > *From:* Saurabh Garg via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org> > *Sent:* Friday, October 25, 2019 11:55:40 AM > *To:* freeipa-users(a)lists.fedorahosted.org < > freeipa-users(a)lists.fedorahosted.org> > *Cc:* Saurabh Garg <saurabh.grg(a)gmail.com> > *Subject:* [Freeipa-users] Full Server backup fails with IPA version error > > Background - > We are trying to restore "full server" from an existing IPA server (with > replication ON to another server) to a newly created IPA Server from the > same golden image as all other servers. > > Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo) > # ipa-server-install --version > 4.6.4 > > Destination IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo) > # ipa-server-install --version > 4.6.4 > > Problem Statement - > While running "ipa-restore" (exact command: # ipa-restore /root/backup/) > on the new IPA server for full server backup, system throws the following > error lines in iparestore.log: > > > 2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to be > upgraded (expected version '4.6.4-10.el7_6.6', current version > '4.6.4-10.el7_6.3') > Automatically running upgrade, for details see /var/log/ipaupgrade.log > Be patient, this may take a few minutes. > Automatic upgrade failed: Update complete > Upgrading the configuration of the IPA services > [Verifying that root certificate is published] > [Migrate CRL publish directory] > Publish directory already set to new location > [Verifying that CA proxy configuration is correct] > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command > ipa-server-upgrade manually. > CA did not start in 300.0s > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information > > See the upgrade log for more details and/or run > /usr/sbin/ipa-server-upgrade again > Aborting ipactl > > 2019-10-25T08:19:26Z INFO Restoring umask to 23 > 2019-10-25T08:19:26Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in > execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_restore.py", line > 428, in run > run(['ipactl', 'start']) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, > in run > raise CalledProcessError(p.returncode, arg_string, str(output)) > > 2019-10-25T08:19:26Z DEBUG The ipa-restore command failed, exception: > CalledProcessError: Command 'ipactl start' returned non-zero exit status 1 > 2019-10-25T08:19:26Z ERROR Command 'ipactl start' returned non-zero exit > status 1 > 2019-10-25T08:19:26Z ERROR The ipa-restore command failed. See > /var/log/iparestore.log for more information > > In case you are aware of its fix/workaround, kindly share the steps. > > Thanks, > sgarg > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > List Guidelines: > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… >

2 1

Fedora -> CentOS, 4.7.2 -> 4.7.1
by David Harvey 28 Oct '19

28 Oct '19

Dear FreeIPA users, TL:DR *any* way of moving from 4.7.2->4.7.1? I've managed to get into a situation.. On realising the support for Debian/Ubuntu was a bit ropey, I successfully made Fedora replicas and promoted them a year or so ago. These run OK, but wanting to be off the treadmill of Fedora upgrades, the promise of CentOS8 beckoned. With seeing the release notes for 4.7.2 pointing to Redhat 8 relates patches I was quite confident that 4.7.2 would be included, allowing another hop over to a longer term supported OS. So the short version is, that I'm on 4.7.2 very much wanting to get to CentOS8 where 4.7.1 is currently. I understand the replica installer will let you create against the same or older than itself, but are there any actual LDAP schema differences between these versions? Might it be possible to tweak what 4.7.2 reports in order to force it to allow a 4.7.1 replica? Is there a backup and restore process that might allow the moving back by 0.0.1 versions!? Given that FreeIPA call out Redhat and Fedora support but not CentOS, would I actually be better off on the Fedora frequent update path? Many thanks in advance, David

2 3

Upgrade 389-ds-base
by Dirk Streubel 28 Oct '19

28 Oct '19

Hello, after Updating my FreeIPA Machine with the following Packages 389-ds-base-1.4.1.8-4.fc30.x86_64 and 389-ds-base-libs-1.4.1.8-4.fc30.x86_64 my IPAServer will not start because of a Dirsrv Error: [28/Oct/2019:15:24:33.197006547 +0100] - INFO - main - 389-Directory/1.4.1.8 B2019.288.179 starting up [28/Oct/2019:15:24:33.305073561 +0100] - INFO - main - Setting the maximum file descriptor limit to: 524288 [28/Oct/2019:15:24:34.015432996 +0100] - INFO - PBKDF2_SHA256 - Based on CPU performance, chose 2048 rounds [28/Oct/2019:15:24:34.148313874 +0100] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [28/Oct/2019:15:24:34.183483952 +0100] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [28/Oct/2019:15:24:34.216059053 +0100] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [28/Oct/2019:15:24:34.249251920 +0100] - NOTICE - ldbm_back_start - found 2034812k physical memory [28/Oct/2019:15:24:34.271787887 +0100] - NOTICE - ldbm_back_start - found 627800k available [28/Oct/2019:15:24:34.305153307 +0100] - NOTICE - ldbm_back_start - cache autosizing: db cache: 50870k [28/Oct/2019:15:24:34.346820319 +0100] - NOTICE - ldbm_back_start - cache autosizing: userRoot entry cache (3 total): 65536k [28/Oct/2019:15:24:34.380215639 +0100] - NOTICE - ldbm_back_start - cache autosizing: userRoot dn cache (3 total): 65536k [28/Oct/2019:15:24:34.413883565 +0100] - NOTICE - ldbm_back_start - cache autosizing: ipaca entry cache (3 total): 65536k [28/Oct/2019:15:24:34.446900772 +0100] - NOTICE - ldbm_back_start - cache autosizing: ipaca dn cache (3 total): 65536k [28/Oct/2019:15:24:34.480404651 +0100] - NOTICE - ldbm_back_start - cache autosizing: changelog entry cache (3 total): 65536k [28/Oct/2019:15:24:34.513586337 +0100] - NOTICE - ldbm_back_start - cache autosizing: changelog dn cache (3 total): 65536k [28/Oct/2019:15:24:34.545455448 +0100] - NOTICE - ldbm_back_start - total cache size: 444326133 B; [28/Oct/2019:15:24:34.660654207 +0100] - INFO - dblayer_start - Resizing db cache size: 82532761 -> 41672949 [28/Oct/2019:15:24:35.305068723 +0100] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher AES [28/Oct/2019:15:24:35.346977418 +0100] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [28/Oct/2019:15:24:35.389013473 +0100] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES [28/Oct/2019:15:24:35.430350643 +0100] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [28/Oct/2019:15:24:35.472051056 +0100] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. [28/Oct/2019:15:24:35.712098113 +0100] - ERR - schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [28/Oct/2019:15:24:35.767825035 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=groups,cn=compat,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:35.847642467 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=computers,cn=compat,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:35.889335963 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=ng,cn=compat,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:35.906058664 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target ou=sudoers,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:35.922645682 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=users,cn=compat,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:35.939342751 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:35.973017877 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:35.997578015 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.047582540 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.122682002 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.175397700 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.222712999 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.255979639 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.400353621 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.464434060 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.570672924 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.638393241 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.697648930 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipatest,dc=intranet,dc=xxx,dc=de does not exist [28/Oct/2019:15:24:36.839033805 +0100] - WARN - NSACLPlugin - acl_parse - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [28/Oct/2019:15:24:36.903400951 +0100] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipatest,dc=intranet,dc=xxx,dc=de--no CoS Templates found, which should be added before the CoS Definition. [28/Oct/2019:15:24:37.113354944 +0100] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa4.ipatest.intranet.XXX.de(a)IPATEST.INTRANET.XXX.DE] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [28/Oct/2019:15:24:37.132921236 +0100] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa4.ipatest.intranet.XXX.de(a)IPATEST.INTRANET.XXX.DE] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [28/Oct/2019:15:24:37.152041659 +0100] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests [28/Oct/2019:15:24:37.165159407 +0100] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests [28/Oct/2019:15:24:37.184192580 +0100] - INFO - slapd_daemon - Listening on /var/run/slapd-IPATEST-INTRANET-XXX-DE.socket for LDAPI requests [28/Oct/2019:15:24:37.249042042 +0100] - ERR - schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [28/Oct/2019:15:24:42.261321976 +0100] - ERR - schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipatest,dc=intranet,dc=XXX,dc=de [28/Oct/2019:15:24:42.336666961 +0100] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipatest,dc=intranet,dc=XXX,dc=de [28/Oct/2019:15:24:42.381915111 +0100] - ERR - schema-compat-plugin - Finished plugin initialization. [28/Oct/2019:15:51:27.596490424 +0100] - INFO - op_thread_cleanup - slapd shutting down - signaling operation threads - op stack size 3 max work q size 4 max work q stack size 4 [28/Oct/2019:15:51:27.885286001 +0100] - INFO - slapd_daemon - slapd shutting down - closing down internal subsystems and plugins This IPA Server is one of my replica setup here at work at the other works fine. At home after the update i have the same problems, Any Help? Regards Dirk

1 0

ca-certificate file not being parses correctly on Ubuntu with p11-kit-trust.so due to data inserted by FreeIPA Client install
by Kevin Vasko 28 Oct '19

28 Oct '19

Mainly looking for input on where to file a bug I think I found in p11-kit-trust.so but potentially caused by the FreeIPA client install process on Ubuntu. I have been trying to figure out a way of getting Ubuntu to load the system wide certs like CentOS/Fedora does. Alexander helped me troubleshoot my issues on CentOS/Fedora and those system work out of the box (after I fixed my mistake https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg07903.…) However, on Ubuntu you have to take it a slight step further by using the p11-kit-trust.so manually it seems. I found this link https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285 that has a bug report that states you can just symlink the p11-kit-trust.so to the /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so https://superuser.com/a/1312419/411058and it would “just work”. Unfortunately, I was having trouble figuring out how to get it to work. I spent a couple days or so troubleshooting and trying to figure out why it wasn’t working. Once I would do the symlink to the p11-kit-trust.so, no certificates _at all_ would load in any browser (chome/firefox). If I removed the symlink and put the libnssckbi.so file the browsers would go back to loading the static system wide certs (obviously the certs I included wouldn’t work). Eventually I ran across this documentation from p11-kit to find out how to debug p11-kit. https://p11-glue.github.io/p11-glue/trust-module.html I ran P11_KIT_DEBUG=all firefox With that log output I finally found something to point me in the correct direction. Based on this log it seems like p11-kit is having issues parsing the ca-certificates.crt file. $ P11_KIT_DEBUG=all firefox (p11-kit:10001) p11_library_init_impl: initializing library (p11-kit:10001) uninit_common: uninitializing library (p11-kit:10057) p11_library_init_impl: initializing library (p11-kit:10057) uninit_common: uninitializing library (p11-kit:10001) p11_library_init_impl: initializing library (p11-kit:10001) sys_C_Initialize: in (p11-kit:10001) sys_C_Initialize: doing initialization (p11-kit:10001) create_tokens_inlock: using paths: /etc/ssl/certs/ca-certificates.crt (p11-kit:10001) p11_token_new: token: System Trust: /etc/ssl/certs/ca-certificates.crt (p11-kit:10001) sys_C_Initialize: out: 0x0 (p11-kit:10001) sys_C_GetInfo: in (p11-kit:10001) sys_C_GetInfo: out: 0x0 (p11-kit:10001) sys_C_GetSlotList: in (p11-kit:10001) sys_C_GetSlotList: out: 0x0 (p11-kit:10001) sys_C_GetSlotList: in (p11-kit:10001) sys_C_GetSlotList: out: 0x0 (p11-kit:10001) sys_C_GetSlotInfo: in (p11-kit:10001) sys_C_GetSlotInfo: out: 0x0 (p11-kit:10001) sys_C_GetTokenInfo: in (p11-kit:10001) sys_C_GetTokenInfo: out: 0x0 (p11-kit:10001) sys_C_GetMechanismList: in (p11-kit:10001) sys_C_GetMechanismList: out: 0x0 (p11-kit:10001) sys_C_GetMechanismList: in (p11-kit:10001) sys_C_GetMechanismList: out: 0x0 (p11-kit:10001) sys_C_OpenSession: in (p11-kit:10001) sys_C_OpenSession: session: 17 (p11-kit:10001) sys_C_OpenSession: out: 0x0 (p11-kit:10001) sys_C_FindObjectsInit: in: 17, (1) [ { CKA_CLASS = CKO_NSS_BUILTIN_ROOT_LIST } ] (p11-kit:10001) message: ca-certificates.crt: BEGIN ...: pem block before p11-kit section header (p11-kit:10001) loader_load_file: failed to parse: /etc/ssl/certs/ca-certificates.crt (p11-kit:10001) sys_C_FindObjectsInit: out: 0x0 (p11-kit:10001) sys_C_FindObjects: in: 17, 1 (p11-kit:10001) sys_C_FindObjects: out: 0x11, 1 (p11-kit:10001) sys_C_FindObjectsFinal: in (p11-kit:10001) sys_C_FindObjectsFinal: out: 0x0 I looked at the ca-certificates.crt file Nothing looked abnormal until I saw this… ----previous part of ca-certificates.crt---- # This file was created by IPA. Do not edit. [p11-kit-object-v1] class: certificate certificate-type: x-509 certificate-category: authority label: <removed> subject: ": <removed>" issuer: ": <removed>" serial-number: “<removed>" x-public-key-info: ": <removed>" trusted: true ------BEGIN CERTIFICATE------ ….. ----rest of ca-certificates.crt ---- Once I removed the section above the “…BEGIN CERTIFICATE…” and after the prior “----END CERTIFICATE----“ everything started working properly. I put it back and things broke again. So this indicates that p11-kit-trust.so isn’t parsing the ca-certificate.crt file due to the information that the FreeIPA client install put into the file. I am using the latest version that comes with Ubuntu 18.04 of p11-kit-trust (0.23). So my question is, should this be a bug report to Ubuntu’s implementation of the FreeIPA client install that adds the certificate information or should I file a bug report against the p11-kit module to have them fix the parsing issue? Any thoughts/suggestions? -Kevin

2 2

IPA ocsp responder cert
by Sandor Juhasz 28 Oct '19

28 Oct '19

Hi, we are running freeipa server 4.6.5. Facing the issue, where the ocsp responder in the Server-Cert is set to Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://ipa-ca.bpo.cxn/ca/ocsp" Where the hosts cert's subject is Subject: "CN=ipa14.bpo.cxn,O=CXN" I have added DNS alias for the given machine, but the httpd shows only cert for the subject, but cannot add the ocsp. Tried with certutil, with ipa-getcert, but i was not able to add the alias to the given cert. Is there a way to fix this? -- *Sándor Juhász* System Administrator *ChemAxon* *Kft*. Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964

2 2

Re: Ipa user can't login via ssh
by Rob Crittenden 28 Oct '19

28 Oct '19

Elhamsadat Azarian wrote: > Hi. > Which details do u need? I will send. Adding freeipa-users yet again. I'll stop responding if this continues. We'd need to see the active HBAC Rules, hbactest output at a minimum. The sssd logs on the failing machine might be relevant too but you'll probably need to enable debugging first to capture the right data. See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html rob > > On Mon, 21 Oct 2019, 18:28 Rob Crittenden, <rcritten(a)redhat.com > <mailto:rcritten@redhat.com>> wrote: > > Elhamsadat Azarian wrote: > > Hi Rob > > Thank you for helping > > I disabled default HBAC rule and add a new rule that user "elham" > could > > login and ssh on hosts "ipa-client and ipa-server" > > Now it can ssh to ipa-server but still it had problem with ipa-client. > > So rules couldnt solve my problem. > > I don't know what to tell you without more details. > > rob > > > > > On Tue, 15 Oct 2019, 16:44 Rob Crittenden, <rcritten(a)redhat.com > <mailto:rcritten@redhat.com> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> wrote: > > > > Please keep freeipa-users in the responses. > > > > Elhamsadat Azarian wrote: > > > Hi Rob > > > I did it and i got this answer: > > > > > > Access granted : false > > > > > > What can i do now? > > > > IPA ships with a default HBAC rule, allow_all, which allows > all users to > > authenticate on all hosts. I can only assume you've deleted or > disabled > > that, and that's fine. > > > > But if you do then you need to create the set of rules to > grant access > > to hosts for the appropriate users. > > > > To provide specific assistance you'd need to share a bit of > internal > > details, current HBAC rules, etc. It is understandable if you > can't > > do that. > > > > But basically you need to evaluate your HBAC rules to find out > why this > > user can't log into hosts. The user may be missing from a > group, for > > example. > > > > rob > > > > > > On Mon, 14 Oct 2019, 18:07 Rob Crittenden, > <rcritten(a)redhat.com <mailto:rcritten@redhat.com> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>> > > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>> wrote: > > > > > > Elhamsadat Azarian wrote: > > > > I tryed to add HBAC rules to my user but it said : some > > operation > > > > failed. Users cannot be added when user category = all > > > > > > Adding list back. > > > > > > Try something like: > > > > > > ipa hbactest --user elham --service ssh --host <your host> > > > > > > There is an equivalent way to do it in the UI. > > > > > > rob > > > > > > > > > > > On Wed, 9 Oct 2019, 17:19 Rob Crittenden, > > <rcritten(a)redhat.com <mailto:rcritten@redhat.com> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>> > > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> > > > > <mailto:rcritten@redhat.com > <mailto:rcritten@redhat.com> <mailto:rcritten@redhat.com > <mailto:rcritten@redhat.com>> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>>> wrote: > > > > > > > > Kevin Vasko via FreeIPA-users wrote: > > > > > Have you made sure your “elham” user has the correct > > permissions > > > > to access the machines? Take a look in the UI at the > > > > groups/permissions that user elham has. Take a look at > > your HBAC > > > > rules as well. That would be my first > recommendation to > > check > > > if it > > > > was me. > > > > > > > > Right, and the troubleshooting page suggests that (and > > > increasing debug > > > > logging). > > > > > > > > Please provide the output of the things you have > already > > > looked at. > > > > > > > > rob > > > > > > > > > > > > > > -Kevin > > > > > > > > > >> On Oct 9, 2019, at 7:23 AM, Elhamsadat Azarian via > > > FreeIPA-users > > > > <freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>>> > > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>>>>> wrote: > > > > >> > > > > >> ### Request for enhancement > > > > >> as a Linux admin i want to login into my ipa client > > with a user > > > > that is defined in ipa-server UI. > > > > >> > > > > >> ### Issue > > > > >> I installed Ipa-server and an Ipa-client on > CentOS7.6 > > > > >> I defined Internal DNS on ipa-server and i > defined A > > and PTR > > > > records for client on ipa-server. > > > > >> now i can see my client in ipa-UI and i defined a > > user with > > > name > > > > "elham" and i expect that it can login into > ipa-client. > > > > >> when i login with root in ipa-client and i do sudo > > elham, it > > > > works and kinit elham works too but > > > > >> when i do ssh into ipa-client with this user, > it show > > > "Access denied" > > > > >> i have errors with this context: > > > > >> pam_reply : authentication failure to the client > > > > >> pam_sss: authentication falure > > > > >> > > > > >> im tired of this issue. please help me if you > know the > > > solution. > > > > >> > > > > >> #### Steps to Reproduce > > > > >> 1. define new user "elham" in ipa UI > > > > >> 2. SSH to ipa-client with elham > > > > >> 3. access denied > > > > >> > > > > >> #### Actual behavior > > > > >> (what happens) > > > > >> > > > > >> #### Expected behavior > > > > >> login into ipa-client successfully > > > > >> > > > > >> #### Version/Release/Distribution > > > > >> ipa-server 4.6.5-11.el7 > > > > >> ipa-client 4.6.4-10.el7.centos.3 > > > > >> Log files and config files are added below: > > > > >> > > > > >> > > > > >> > > > > >> krb5.conf > > > > >> ------------ > > > > >> #File modified by ipa-client-install > > > > >> > > > > >> includedir /etc/krb5.conf.d/ > > > > >> includedir /var/lib/sss/pubconf/krb5.include.d/ > > > > >> > > > > >> > > > > >> [logging] > > > > >> default = FILE:/var/log/krb5libs.log > > > > >> kdc = FILE:/var/log/krb5kdc.log > > > > >> admin_server = FILE:/var/log/kadmind.log > > > > >> [libdefaults] > > > > >> default_realm = LSHS.DC > > > > >> dns_lookup_realm = false > > > > >> dns_lookup_kdc = false > > > > >> rdns = false > > > > >> ticket_lifetime = 24h > > > > >> forwardable = yes > > > > >> allow_weak_crypto = true > > > > >> default_ccache_name = KEYRING:persistent:%{uid} > > > > >> > > > > >> [realms] > > > > >> LSHS.DC = { > > > > >> kdc = ipa-irvlt01.example.dc:88 > > > > >> admin_server = ipa-irvlt01.example.dc:749 > > > > >> default_domain = example.dc > > > > >> } > > > > >> [domain_realm] > > > > >> .example.com <http://example.com> > <http://example.com> > > <http://example.com> <http://example.com> = > > > LSHS.DC > > > > >> example.com <http://example.com> > <http://example.com> <http://example.com> > > <http://example.com> = LSHS.DC > > > > >> ############################################ > > > > >> > > > > >> > > > > >> sssd.conf > > > > >> ------------- > > > > >> [domain/example.dc] > > > > >> > > > > >> cache_credentials = True > > > > >> krb5_store_password_if_offline = True > > > > >> ipa_domain = example.dc > > > > >> id_provider = ipa > > > > >> auth_provider = ipa > > > > >> access_provider = ipa > > > > >> ldap_tls_cacert = /etc/ipa/ca.crt > > > > >> ipa_hostname = ipacli-irvlt01.example.dc > > > > >> chpass_provider = ipa > > > > >> dyndns_update = True > > > > >> ipa_server = _srv_, ipa-irvlt01.example.dc > > > > >> dyndns_iface = ens160 > > > > >> dns_discovery_domain = example.dc > > > > >> > > > > >> debug_level = 10 > > > > >> [sssd] > > > > >> ########### AFTER IPA ################### > > > > >> #services = nss, sudo, pam, ssh > > > > >> services = nss, pam > > > > >> config_file_version = 2 > > > > >> ######################################### > > > > >> domains = example.dc > > > > >> > > > > >> debug_level = 10 > > > > >> [nss] > > > > >> homedir_substring = /home > > > > >> > > > > >> [pam] > > > > >> debug_level = 10 > > > > >> > > > > >> [sudo] > > > > >> > > > > >> [autofs] > > > > >> > > > > >> [ssh] > > > > >> > > > > >> [pac] > > > > >> > > > > >> [ifp] > > > > >> > > > > >> [secrets] > > > > >> > > > > >> [session_recording] > > > > >> > > > > >> ########################################## > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> FreeIPA-users mailing list -- > > > > freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>>> > > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>>>> > > > > >> To unsubscribe send an email to > > > > freeipa-users-leave(a)lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>>> > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>>>> > > > > >> Fedora Code of Conduct: > > > > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > > >> List Guidelines: > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > >> List Archives: > > > > > > > > > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > > > > > _______________________________________________ > > > > > FreeIPA-users mailing list -- > > > freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>>> > > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>>>> > > > > > To unsubscribe send an email to > > > > freeipa-users-leave(a)lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>>> > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>>>> > > > > > Fedora Code of Conduct: > > > > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > > > List Guidelines: > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > List Archives: > > > > > > > > > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > > > > > > > > > > > > > > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users October 2019