certmonger failing
by Rob Verduijn
Hello,
Today I upgraded my ipaserver from centos 8.1 to centos 8.2
And ipa-healthcheck --failures-only claims all my certs have expired in
1970.
Which is a bit weird since they all seem to work fine for me.
Everything seems to work except for a lot of errors in my logs from
certmonger.
I get a lot of these :
... [8777] Error authenticating to token "NSS Certificate DB".
... [8777] Error shutting down NSS.
... [8778] Token is named "NSS Generic Crypto Services", not "NSS
Certificate DB", skipping.
... [8778] certread-n: Error authenticating to cert db slot NSS Certificate
DB.
... [8778] Error locating certificate.
... [8778] Error shutting down NSS.
... [8779] Error authenticating to token "NSS Certificate DB".
... [8779] Error shutting down NSS.
... [8780] Token is named "NSS Generic Crypto Services", not "NSS
Certificate DB", skipping.
... [8780] certread-n: Error authenticating to cert db slot NSS Certificate
DB.
Certmonger is up and running, but not functioning.
Anybody know how to get certmonger to function properly again ?
Rob
3 years, 10 months
Re: Last FreeIPA master is failing
by Rob Crittenden
Ricardo Mendes via FreeIPA-users wrote:
>>I think you need to see what certs and keys are in /etc/httpd/alias.
>> Sounds like there is no Server-Cert nickname.
>
> certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
> certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
>
> This is the output, and I'm adding getcert list in the end as well.
>
>
> # certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
>
> Certificate Nickname Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
>
> DSTRootCAX3 C,,
> CN=main.domain.io u,u,u
> letsencryptx3 C,,
> letsencryptx3 C,,
> ISRGRootCAX1 C,,
> DOMAIN.IO IPA CA CT,C,
>
> # certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
> < 0> rsa 493a92843c598413e3f50ca923706417821bf392 CN=main.domain.io
> < 1> rsa e946257bb7a486f489287ccd72dab14067eae2b7 CN=main.domain.io
> < 2> rsa 8bbe08dd006063eea896aee19f24da6b5f28f348 CN=main.domain.io
> < 3> rsa ac96e477d65db3ba63213332c30ac7733bf70a10 (orphan)
> < 4> rsa b40bea3d28cce1ea7274f8ecf47b2d70f5e0c0c1 CN=main.domain.io
> #
>
Right the cert nickname is CN=main.domain.io. I'm assuming you manually
installed the LE certs originally using ipa-server-certinstall right?
That doesn't follow the pattern of using Server-Cert for the nickname by
default.
You can probably just hack the LE script and replace Server-Cert with
CN=main.domain.io.
It's important to know that the LE script was written specifically for
the IPA demo site and a repo created to share the general method. It
isn't shipped with IPA or otherwise really supported at all. No
backwards compatibility testing is done, just what is needed for the
demo site. So while it might eventually work fine for you it isn't
intended to be a general-purpose tool.
rob
> # getcert list
> Number of certificates and requests being tracked: 7.
> Request ID '20190220114014':
> status: MONITORING
> stuck: no
> key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
> certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
> CA: IPA
> issuer: CN=Certificate Authority,O=DOMAIN.IO
> subject: CN=main.domain.io,O=DOMAIN.IO
> expires: 2021-02-20 11:40:16 UTC
> principal name: krbtgt/DOMAIN.IO(a)DOMAIN.IO
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-pkinit-KPKdc
> pre-save command:
> post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
> track: yes
> auto-renew: yes
> Request ID '20190819230939':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=DOMAIN.IO
> subject: CN=CA Audit,O=DOMAIN.IO
> expires: 2021-02-09 11:36:51 UTC
> key usage: digitalSignature,nonRepudiation
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "auditSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20190819230940':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS
> Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS
> Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=DOMAIN.IO
> subject: CN=OCSP Subsystem,O=DOMAIN.IO
> expires: 2021-02-09 11:36:48 UTC
> eku: id-kp-OCSPSigning
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "ocspSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20190819230941':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=DOMAIN.IO
> subject: CN=CA Subsystem,O=DOMAIN.IO
> expires: 2021-02-09 11:36:50 UTC
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-clientAuth
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "subsystemCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20190819230942':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=DOMAIN.IO
> subject: CN=Certificate Authority,O=DOMAIN.IO
> expires: 2039-02-20 11:36:43 UTC
> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "caSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20190819230943':
> status: MONITORING
> stuck: no
> key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
> certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=DOMAIN.IO
> subject: CN=IPA RA,O=DOMAIN.IO
> expires: 2021-02-09 11:37:44 UTC
> key usage: digitalSignature,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
> post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
> track: yes
> auto-renew: yes
> Request ID '20190819230944':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=DOMAIN.IO
> subject: CN=main.domain.io,O=DOMAIN.IO
> expires: 2021-02-09 11:36:49 UTC
> dns: main.domain.io
> key usage: digitalSignature,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "Server-Cert cert-pki-ca"
> track: yes
> auto-renew: yes
>
>
>> > (btw https://lists.fedoraproject.org is down)
>
>> Related to the Fedora infrastructure move.
>
> hope all is going well!
>
> Ricardo
> _______________________________________________
> 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://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.fedoraho...
>
3 years, 10 months
[CVE-2020-10747] FreeIPA 4.6.9 released
by Alexander Bokovoy
Hello!
The FreeIPA team would like to announce FreeIPA 4.6.9 release!
It can be downloaded from http://www.freeipa.org/page/Downloads.
== Highlights in 4.6.9 ==
* CVE-2020-10747
It was found that if an account with a name corresponding to an account
local to a system, such as 'root', was created via IPA, such account could
access any enrolled machine with that identitity and the local system
privileges. This also bypass the absence of explicit HBAC rules.
Since the account can only be created by user administrators in FreeIPA,
several changes were done to tighten permissions and prevent creation of 'root'
identity by mistake.
root principal alias
-------------------
The principal "root@REALM" is now a Kerberos principal alias for "admin". This
prevent user with "User Administrator" role or "System: Add User" privilege to
create an account with "root" principal name.
Modified user permissions
-------------------------
Several user permissions no longer apply to admin users and filter on
posixAccount object class. This prevents user managers from modifying admin
acounts:
- System: Manage User Certificates
- System: Manage User Principals
- System: Manage User SSH Public Keys
- System: Modify Users
- System: Remove Users
- System: Unlock user
``System: Unlock User`` permission is now restricted because the permission
also allows a user manager to lock an admin account.
``System: Modify Users`` is restricted to prevent user managers from changing
login shell or notification channels (mail, mobile) of admin accounts.
New user permission
-------------------
- System: Change Admin User password
This new permission allows manipulation of admin user password fields. By
default only the ``PassSync Service`` privilege is allowed to modify admin user
password fields.
Modified group permissions
--------------------------
Group permissions are now restricted as well. Group admins can no longer modify
the admins group and are limited to groups with object class ``ipausergroup``.
- System: Modify Groups
- System: Remove Groups
The permission ``System: Modify Group Membership`` was already limited.
== Upgrading ==
Upgrade instructions are available on [[Upgrade]] page.
== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users mailing
list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...)
or #freeipa channel on Freenode.
== Resolved tickets ==
* [https://pagure.io/freeipa/issue/8326 #8326] CVE-2020-10747
== Detailed changelog since 4.6.8 ==
=== Alexander Bokovoy (1) ===
* Become FreeIPA 4.6.9 [https://pagure.io/freeipa/c/4f1f8754742d55263a7da89575c5d94b5ea4c7e3 commit]
=== Christian Heimes (1) ===
* Prevent local account takeover [https://pagure.io/freeipa/c/316ac7cd62ac130f88b374c1f9f47b41806187c1 commit] [https://pagure.io/freeipa/issue/8326 #8326]
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3 years, 10 months
[CVE-2020-10747] FreeIPA 4.8.8 released
by Alexander Bokovoy
Hello!
The FreeIPA team would like to announce FreeIPA 4.8.8 release!
It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for
Fedora distributions will be available from the official repository soon.
== Highlights in 4.8.8 ==
* CVE-2020-10747
It was found that if an account with a name corresponding to an account
local to a system, such as 'root', was created via IPA, such account could
access any enrolled machine with that identitity and the local system
privileges. This also bypass the absence of explicit HBAC rules.
Since the account can only be created by user administrators in FreeIPA,
several changes were done to tighten permissions and prevent creation of 'root'
identity by mistake.
root principal alias
-------------------
The principal "root@REALM" is now a Kerberos principal alias for "admin". This
prevent user with "User Administrator" role or "System: Add User" privilege to
create an account with "root" principal name.
Modified user permissions
-------------------------
Several user permissions no longer apply to admin users and filter on
posixAccount object class. This prevents user managers from modifying admin
acounts:
- System: Manage User Certificates
- System: Manage User Principals
- System: Manage User SSH Public Keys
- System: Modify Users
- System: Remove Users
- System: Unlock user
``System: Unlock User`` permission is now restricted because the permission
also allows a user manager to lock an admin account.
``System: Modify Users`` is restricted to prevent user managers from changing
login shell or notification channels (mail, mobile) of admin accounts.
New user permission
-------------------
- System: Change Admin User password
This new permission allows manipulation of admin user password fields. By
default only the ``PassSync Service`` privilege is allowed to modify admin user
password fields.
Modified group permissions
--------------------------
Group permissions are now restricted as well. Group admins can no longer modify
the admins group and are limited to groups with object class ``ipausergroup``.
- System: Modify Groups
- System: Remove Groups
The permission ``System: Modify Group Membership`` was already limited.
== Upgrading ==
Upgrade instructions are available on [[Upgrade]] page.
== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users mailing
list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...)
or #freeipa channel on Freenode.
== Resolved tickets ==
* [https://pagure.io/freeipa/issue/8326 #8326] CVE-2020-10747
== Detailed changelog since 4.8.7 ==
=== Alexander Bokovoy (1) ===
* Become FreeIPA 4.8.8 [https://pagure.io/freeipa/c/86ab7590779b9e25c6a52cf5a785925103d9ee8a commit]
=== Christian Heimes (1) ===
* Prevent local account takeover [https://pagure.io/freeipa/c/65c2736bd20ffb9d98769e71d905f71d1a4d857e commit] [https://pagure.io/freeipa/issue/8326 #8326]
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3 years, 10 months
automember hostgroup by account?
by Amos
Is it possible to have an automember rule to add a host to a hostgroup
based on the account used with ipa-install-client?
Amos
3 years, 10 months
Re: Last FreeIPA master is failing
by Rob Crittenden
Ricardo Mendes wrote:
> Hi Rob,
>
> Again thanks for your reply. So I got went to the commit that lasted
> from 2017 and re-ran setup-le.sh
> Output is here:
>
> https://pastebin.com/JAaD4R21
>
> In the end I get this error:
>
> ipaplatform.redhat.tasks: INFO: Systemwide CA database updated.
> ipalib.backend: DEBUG: Destroyed connection
> context.rpcclient_140213913461328
> ipapython.admintool: INFO: The ipa-certupdate command was successful
> certutil: Server-Cert is neither a key-type nor a nickname nor a key-id:
> SEC_ERROR_INVALID_ARGS: security library: invalid arguments.
>
> If I try renew-le
>
> # bash renew-le.sh
> certutil: could not find certificate named "Server-Cert":
> PR_FILE_NOT_FOUND_ERROR: File not found
> certutil: Server-Cert is neither a key-type nor a nickname nor a key-id:
> SEC_ERROR_INVALID_ARGS: security library: invalid arguments.
I think you need to see what certs and keys are in /etc/httpd/alias.
Sounds like there is no Server-Cert nickname.
certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
> (btw https://lists.fedoraproject.org is down)
Related to the Fedora infrastructure move.
rob
>
>
> Ricardo Mendes via FreeIPA-users wrote:
>
>> Ok so I don't know what happened the server really did take a long
>> time to come up but it did.
>>
>> Everything looks pretty much the same. The setup-le.sh command I ran
>> that said
>>
>>> The ipa-certupdate command was successful
>> But I can't see it. I have to start ipa services with
>> --ignore-service-failure and --skip-version-check
>> When I go to web I still see the old expired certificate from May 21st.
>>
>> I tried to run renew-le and I get this error:
>>
>> # bash renew-le.sh
>> Error opening Certificate /var/lib/ipa/certs/httpd.crt
>> 140430772283280:error:02001002:system library:fopen:No such file or
>> directory:bss_file.c:402:fopen('/var/lib/ipa/certs/httpd.crt','r')
>> 140430772283280:error:20074002:BIO routines:FILE_CTRL:system
>> lib:bss_file.c:404:
>> unable to load certificate
>>
> That's the incompatibilities I mentioned. I think if you pop the top one
> or two commits off then it will start to work again. Look for a commit
> that's like "switch to mod_ssl" and pop that off.
>
> rob
>
>
3 years, 10 months
Last FreeIPA master is failing
by Ricardo Mendes
Hi all,
I'm having serious issues with our FreeIPA setup and I need some direction.
Our FreeIPA setup had two master-replicas. Late last month one of the hypervisors at OVH died, they replaced hardware but the server is having issues so hasn't come up yet. So for all matters, one master-replica is dead.
The original master was configured with letsencrypt-freeipa which failed to renew certificates.
There are around 10 clients connected to it, and several services authenticate against it. One for example is Gitlab, but I am still able to login to Gitlab. Another example we have a number of pfSense routers that also use LDAP auth and that always fails we had to fallback to the local admin user.
One of the most critical services is the DNS. When DNS goes down, everything goes down, including email. This is currently one of the most critical services.
ipactl always fails. I have to manually start the services using systemctl, like
`systemctl start {named-pkcs11,httpd,ipa-custodia,ipa-dnskeysyncd,ipa-ods-exporter,ods-enforcerd,krb5kdc,kadmin}`
getcert list returns 7 certificates, all MONITORING, none expired.
# getcert list -d /etc/httpd/alias -n ipaCert
No request found that matched arguments.
I can run ldap commands on the cli.
ALL ipa commands fail:
# ipa userlist
ipa: ERROR: cannot connect to 'any of the configured servers': https://main.domain.io/ipa/json, https://secondary.domain.io/ipa/json
# certutil -L -d /etc/httpd/alias
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
DSTRootCAX3 C,,
CN=main.domain.io u,u,u
letsencryptx3 C,,
letsencryptx3 C,,
ISRGRootCAX1 C,,
DOMAIN.IO IPA CA CT,C,
the ipa-cert-fix command with increased verbosity:
```
ipapython.ipautil: DEBUG: stderr=
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/pki/pki-tomcat/alias -L -n transportCert cert-pki-kra -a -f /etc/pki/pki-tomcat/alias/pwdfile.txt
ipapython.ipautil: DEBUG: Process finished, return code=255
ipapython.ipautil: DEBUG: stdout=
ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: transportCert cert-pki-kra
: PR_FILE_NOT_FOUND_ERROR: File not found
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/pki/pki-tomcat/alias -L -n storageCert cert-pki-kra -a -f /etc/pki/pki-tomcat/alias/pwdfile.txt
ipapython.ipautil: DEBUG: Process finished, return code=255
ipapython.ipautil: DEBUG: stdout=
ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: storageCert cert-pki-kra
: PR_FILE_NOT_FOUND_ERROR: File not found
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/pki/pki-tomcat/alias -L -n auditSigningCert cert-pki-kra -a -f /etc/pki/pki-tomcat/alias/pwdfile.txt
ipapython.ipautil: DEBUG: Process finished, return code=255
ipapython.ipautil: DEBUG: stdout=
ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: auditSigningCert cert-pki-kra
: PR_FILE_NOT_FOUND_ERROR: File not found
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/httpd/alias -L -n Server-Cert -a -f /etc/httpd/alias/pwdfile.txt
ipapython.ipautil: DEBUG: Process finished, return code=255
ipapython.ipautil: DEBUG: stdout=
ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: Server-Cert
: PR_FILE_NOT_FOUND_ERROR: File not found
ipapython.admintool: 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_cert_fix.py", line 100, in run
certs, extra_certs = expired_certs(now)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cert_fix.py", line 142, in expired_certs
return expired_dogtag_certs(now), expired_ipa_certs(now)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cert_fix.py", line 191, in expired_ipa_certs
cert = db.get_cert('Server-Cert')
File "/usr/lib/python2.7/site-packages/ipapython/certdb.py", line 744, in get_cert
raise RuntimeError("Failed to get %s" % nickname)
ipapython.admintool: DEBUG: The ipa-cert-fix command failed, exception: RuntimeError: Failed to get Server-Cert
ipapython.admintool: ERROR: Failed to get Server-Cert
ipapython.admintool: ERROR: The ipa-cert-fix command failed.
```
I thought this command was to fix the certificates, so I don't get it why it fails if one certificate is missing.
But anyway, can someone PLEASE give me some help I'm not great with certificates and I'm not being able to fix this.
If there's a way of creating a new master from start and then importing the data would be nice, but looking at ipa-backup/restore it clearly says it has to be the same server.
3 years, 10 months
Better way to upgrade IPAServer4.6.4 to 4.6.5 + OS 7.6 to 7.7?
by Karim Bourenane
Hello Team
I have some questions :
1°) I need your help, to find the better way to upgrade my 3 servers linked
(replicat).
I want to upgrade servers from CentOS 7.6 to CentOS7.7 with update in same
time the IPAServer (or separately ?)
After searching on Freeipa.org and other site, i find :
#ipactl stop
#ipa-server-upgrade
#ipactl start
I not need to delete first the replication link before ?
What is the better solution ways ?
2°) Is not better to migrate my IPAServers's to 4.7 or 4.8 version ?
Or i need steps too ?
Thanks you for your help
Best Regard
Bien à vous
Mr Karim Bourenane
+33686464439
+32 493 86 63 54
3 years, 10 months
IPA web login: 401 "Login failed due to an unknown reason."
by Chris Carr
We are unable to login to the FreeIPA web console. However, it is able to tell when I use an incorrect password (shows "The password you entered is incorrect.")
Also one of the CentOS servers getting ssh login credentials from our ipa server is using my old password (expired several weeks ago.)
These lines are from httpd error.log
ipa: INFO: 401 Unauthorized: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)
SSL Library Error: -12269 The server has rejected your certificate as expired
I've spent quite a bit of time researching the issue. At first I thought it was because a recent upgrade to FreeIPA (CentOS 7) ipa-server-4.6.6-11.el7.centos.x86_64
But when I looked back in /var/log/messages I can see the error(s) appear to have started occurring before the upgrade.
from journalctl:
Jun 03 22:41:52 ipa.michiganlabs.com systemd[1]: Started IPA key daemon.
Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 1
Jun 03 22:41:54 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipa-dnskeysyncd: INFO LDAP bind...
Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 1
Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 1
Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 2
Jun 03 22:41:54 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipa-dnskeysyncd: INFO Commencing sync process
Jun 03 22:41:54 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipaserver.dnssec.keysyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BIND
Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: GSSAPI client step 1
Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: GSSAPI client step 1
Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: GSSAPI client step 1
Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: ObjectStore.cpp(59): Failed to enumerate object store in /var/lib/softhsm/tokens/
Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: SoftHSM.cpp(476): Could not load the object store
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: Traceback (most recent call last):
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 116, in <module>
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_poll
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: self.syncrepl_refreshdone()
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 126, in syncrepl_refreshdon
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: self.hsm_replica_sync()
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 192, in hsm_replica_sync
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 563, in run
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: raise CalledProcessError(p.returncode, arg_string, str(output))
Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit
Jun 03 22:41:55 ipa.michiganlabs.com systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE
Jun 03 22:41:55 ipa.michiganlabs.com systemd[1]: Unit ipa-dnskeysyncd.service entered failed state.
Jun 03 22:41:55 ipa.michiganlabs.com systemd[1]: ipa-dnskeysyncd.service failed.
Jun 03 22:42:55 ipa.michiganlabs.com systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling restart.
Jun 03 22:42:55 ipa.michiganlabs.com systemd[1]: Stopped IPA key daemon.
possibly relevant output of
> getcert list -c IPA
Number of certificates and requests being tracked: 8.
Request ID '20170928130908':
status: CA_UNCONFIGURED
ca-error: Unable to determine principal name for signing request.
stuck: yes
key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IPA-MICHIGANLABS-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-MICHIGANLABS-COM/pwdfile.txt'
certificate: type=NSSDB,location='/etc/dirsrv/slapd-IPA-MICHIGANLABS-COM',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IPA-MICHIGANLABS-COM
track: yes
auto-renew: yes
possibly relevant SELinux info:
> ausearch -m AVC,USER_AVC -ts recent
type=PROCTITLE msg=audit(1591756304.759:2543): proctitle=2F7573722F62696E2F707974686F6E32002F7573722F6C6962657865632F6970612F6970612D646E736B657973796E632D7265706C696361
type=SYSCALL msg=audit(1591756304.759:2543): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=de4478 a2=90800 a3=0 items=0 ppid=22017 pid=22027 auid=4294967295 uid=994 gid=25 euid=994 suid=994 fsuid=994 egid=25 sgid=25 fsgid=25 tty=(none) ses=4294967295 comm="ipa-dnskeysync-" exe="/usr/bin/python2.7" subj=system_u:system_r:ipa_dnskey_t:s0 key=(null)
type=AVC msg=audit(1591756304.759:2543): avc: denied { read } for pid=22027 comm="ipa-dnskeysync-" name="tokens" dev="dm-6" ino=1373802 scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:named_cache_t:s0 tclass=dir permissive=0
output of
> ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
NOTE: it hangs for like at least 30 seconds when trying to display "ipa-dnskeysyncd Service: RUNNING"
This server was setup slightly less than two years ago using this as a basis of instructions: https://www.digitalocean.com/community/tutorials/how-to-set-up-centralize...
Also there was this note: "ipa.michiganlabs.com - Delegate ipa. dns to FreeIPA server"
Thanks for any assistance
3 years, 10 months
External users report being member of a lot of groups
by TOULMONDE Sébastien (NBU/MST)
Hi - I have an IPA setup (4.6.6) with a trust to AD servers. The users can login to the servers via ssh and everything is allowed via HBAC groups.
I have some users that are admins so I created an all-servers access group.
But when I issue the "id" or "groups" command, users are reported being member of groups they don't belong to, for example:
User id094844 (an external user in AD), is reported member of:
[root@el6983 ~]# id id094844 | tr ',' '\n' | grep acc
1856201464(acc-devredhat-hbac-usergroup(a)dev.ipa.bc)
1856233001(acc-el2720-hbac-usergroup(a)dev.ipa.bc)
1856230575(acc-el2740-hbac-usergroup(a)dev.ipa.bc)
1856231052(acc-el2741-hbac-usergroup(a)dev.ipa.bc)
[...]
But if I check the group membership of acc-el2740-hbac-usergroup (my POSIX group):
[root@el6983 ~]# ipa group-show acc-el2740-hbac-usergroup
Group name: acc-el2740-hbac-usergroup
GID: 1856230575
Member users: id999026
Member groups: acc-el2740-hbac-usergroup-ext, ai-it_rpa_accesses, cmos, is-storage_backup_bo, is-storage_backup_fo
Member of HBAC rule: acc-el2740-hbac
Indirect Member users: abiaload, abidload
Indirect Member groups: ai-it_rpa_accesses-extgrp, is-storage_backup_fo-extgrp, is-storage_backup_bo-extgrp, cmos-
extgrp
# Checking my external group:
[root@el6983 ~]# ipa group-show acc-el2740-hbac-usergroup-ext
Group name: acc-el2740-hbac-usergroup-ext
Member of groups: acc-el2740-hbac-usergroup
Indirect Member of HBAC rule: acc-el2740-hbac
And id094844 isn't member of any groups nested in acc-el2740-hbac-usergroup
As we have a lot of servers, I'm afraid that we'll get a lot of membership once our migration is over... Any way to fix this?
Thanks!
Sébastien Toulmonde
Linux Engineering | ITS Linux CC
[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>
Sensitivity: Internal Use Only
This e-mail cannot be used for other purposes than Proximus business use. See more on https://www.proximus.be/maildisclaimer
3 years, 10 months
