Full Server backup fails with IPA version error
by Saurabh Garg
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
4 years, 5 months
Re: Full Server backup fails with IPA version error
by Saurabh Garg
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.fe...
> List Guidelines:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>
4 years, 5 months
Fedora -> CentOS, 4.7.2 -> 4.7.1
by David Harvey
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
4 years, 5 months
Upgrade 389-ds-base
by Dirk Streubel
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
4 years, 5 months
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
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/msg0790...). 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
4 years, 5 months
IPA ocsp responder cert
by Sandor Juhasz
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
4 years, 5 months
Re: Ipa user can't login via ssh
by Rob Crittenden
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.fedorahosted.org
> > > > > _______________________________________________
> > > > > 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.fedorahosted.org
> > > > >
> > > >
> > >
> >
>
4 years, 5 months
