Issue with Using 3rd part certificates for HTTP/LDAP
by dmitriys
Hi!
I use freeipa-server 4.7.0~pre1+git20180411-2ubuntu2 on Ubuntu 18.04.4 LTS
I installed freeipa-serve in default mode ( ipa-server-install )
Now i try change certificate on Comodo as write in this article https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
my steps:
1 ipa-cacert-manage -p 'password' -n COMODO -t C,, install addtrustexternalcaroot2.crt
Installing CA certificate, please wait
CA certificate successfully installed
The ipa-cacert-manage command was successful
2 ipa-server-certinstall -w -d /home/xattab/ldap_comodo.key ldap_comodo.pem -vvv
get error
ipapython.ipautil: DEBUG: stderr=
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=['/usr/bin/certutil', '-d', 'dbm:/tmp/tmpPsRUhs', '-V', '-n', 'CN=ldap.soft2bet.com', '-u', 'V', '-f', '/tmp/tmpPsRUhs/pwdfile.txt']
ipapython.ipautil: DEBUG: Process finished, return code=255
ipapython.ipautil: DEBUG: stdout=certutil: certificate is invalid: Peer's Certificate issuer is not recognized.
ipapython.ipautil: DEBUG: stderr=
ipapython.admintool: DEBUG: File "/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in execute
return_value = self.run()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/ipa_server_certinstall.py", line 113, in run
self.install_dirsrv_cert()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/ipa_server_certinstall.py", line 139, in install_dirsrv_cert
'restart_dirsrv %s' % serverid)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/ipa_server_certinstall.py", line 291, in import_cert
self.check_chain(pkcs12_file.name, pin, cdb)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/ipa_server_certinstall.py", line 277, in check_chain
"to install the CA certificate." % str(e))
ipapython.admintool: DEBUG: The ipa-server-certinstall command failed, exception: ScriptError: Peer's certificate issuer is not trusted (certutil: certificate is invalid: Peer's Certificate issuer is not recognized.
). Please run ipa-cacert-manage install and ipa-certupdate to install the CA certificate.
ipapython.admintool: ERROR: Peer's certificate issuer is not trusted (certutil: certificate is invalid: Peer's Certificate issuer is not recognized.
). Please run ipa-cacert-manage install and ipa-certupdate to install the CA certificate.
ipapython.admintool: ERROR: The ipa-server-certinstall command failed.
How to fix it ?
Can anybody help me ))) ?
4 years
Freeipa unicodepwd generator
by LUCAS GUILHERME DIEDRICH
Hello guys, is there any change for storing the password over freeipa it generate an password with the unicodepwd format?
I'm still trying to replicate some users from freeipa to AD, i would like to mantain my Freeipa as the principal manager for users and groups.
thanks.
4 years
Re: ipa-restore and the issues
by Rob Crittenden
Please keep responses on the list.
Ian Kumlien wrote:
> ipa find-user admin
> ipa: ERROR: No valid Negotiate header in server response
>
> And a lot of krb issues according to the http logs
I think we need to see the logs to diagnose.
>
> I wasn't expecting this - since all keys should be the same as the one
> installed - which is why i asked about any changes to the ldap data
It could happen, for example, if you had gotten a new keytab for one or
more service and restored old data. Unlikely, but possible.
Comparing the klist output with kvno for all the keytabs and principals
will tell you.
rob
> If there is something more specific you want me to look at, just let me know
>
> On Wed, Feb 5, 2020 at 4:54 PM Rob Crittenden <rcritten(a)redhat.com> wrote:
>>
>> Ian Kumlien via FreeIPA-users wrote:
>>> Hi,
>>>
>>> Due to issues, I'm trying to do a partial restore of all the "important bits"
>>>
>>> But if I do ipa-restore --online --data --backend=userRoot $BACKUP
>>>
>>> I end up in a semiworking environment - the webui doen't work - kinit does...
>>>
>>> ipa doesn't etc..
>>>
>>
>> It doesn't work how? What have you done to troubleshoot? What do the
>> logs say?
>>
>> rob
>>
>
4 years, 1 month
Certificates for embeded devices and old equipment.
by Kendrick .
I have a older kvm that is requiring an unencrypted pem for its cert from freeipa. I have also tried signing a csr from an older ilo product and the cert manager started giving a 404 check your services after trying to import it. any suggestions on how best to aproch these issues.
I did notice in the logs
Feb 19 20:49:40 ipa server[3225]: java.util.TimerThread.run(Timer.java:505)
Feb 19 20:49:40 ipa server[3225]: WARNING: The web application [ca] appears to have started a thread named [AsyncLoader watchdog] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
4 years, 1 month
Re: Issues with certificates: X509: KEY_VALUES_MISMATCH
by Rob Crittenden
Dmitri Moudraninets wrote:
> Hi Rob,
>
> I recovered the key file. Restarted FreeIPA and certmonger. Now issue
> looks different:
> image.png
>
> Subjects disappeared. If I click on a certificate 29 I see this:
> cannot connect to
> 'https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial':
> [Errno 13] Permission denied
Set the same ownership/permissions on the key as you did the cert and
run restorecon on it.
rob
>
> пн, 25 нояб. 2019 г. в 13:58, Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>>:
>
> Dmitri Moudraninets wrote:
> > Hi Rob,
> >
> >
> >
> > I did the following:
> > I removed original ra-agent.pem and ra-agent key
> > and
> > openssl x509 -in /root/debug.cert -out /var/lib/ipa/ra-agent.pem
> > chown root:ipaapi /var/lib/ipa/ra-agent.pem
> > chmod 0440 /var/lib/ipa/ra-agent.pem
> > restorecon /var/lib/ipa/ra-agent.pem
>
> You removed the key!? I sure hope you have a backup of it.
>
> Put it back and I think that will resolve things.
>
> >
> > Successfully restarted FreeIPA:
> > 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
> > smb Service: RUNNING
> > winbind Service: RUNNING
> > ipa-otpd Service: RUNNING
> > ipa-dnskeysyncd Service: RUNNING
> > ipa: INFO: The ipactl command was successful
>
> The agent cert is not required for the CA to operate.
>
> > Now GUI shows different error:
> > cannot connect to
> > 'https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial':
> > [Errno 2] No such file or directory
> >
> >
> > [root@freeipa ~]# getcert list -f /var/lib/ipa/ra-agent.pem
> > Number of certificates and requests being tracked: 16.
> > Request ID '20180912151611':
> > status: NEED_CSR
> > 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=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>
> > subject: CN=IPA RA,O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE>
> <http://CORP.MYDOMAIN.DE>
> > expires: 2019-11-25 15:32:12 UTC
> > key usage:
> digitalSignature,nonRepudiation,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
>
> This shows that the certificate has the right subject now which is good
> but you removed its private key so it won't work.
>
> rob
>
> >
> > сб, 23 нояб. 2019 г. в 20:26, Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>
> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>:
> >
> > Dmitri Moudraninets wrote:
> > > Hi Rob,
> > >
> > > ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory manager' -W
> > > -b uid=ipara,ou=People,o=ipaca usercertificate
> > >
> > > shows me the following:
> > >
> > > Issuer: O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE>
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>,
> > > CN=Certificate Authority
> > > Validity
> > > Not Before: Dec 5 15:32:12 2017 GMT
> > > Not After : *Nov 25 15:32:12 2019* GMT
> > >
> > > It's going to expire on Monday. Can it be a problem?
> >
> > You didn't provide the cert subject so I can't be sure this is
> the right
> > cert. If it contains CN = IPA RA then it is.
> >
> > And yes, it expires in two days. What you'd need to do is
> restore it per
> > my previous instruction into /var/lib/ipa/ra-agent.pem on the
> renewal
> > master (ipa config-show to see which one it is).
> >
> > Then run:
> >
> > # getcert resubmit -f /var/lib/ipa/ra-agent.pem
> >
> > That should renew the cert.
> >
> > On the other masters I'd run the same command and that may fix
> things
> > there as well.
> >
> > rob
> >
> > > I tried this command:
> > > openssl x509 -text -in /var/lib/ipa/ra-agent.pem
> > >
> > > and it shows the following:
> > > Certificate:
> > > Data:
> > > Version: 3 (0x2)
> > > Serial Number: 28 (0x1c)
> > > Signature Algorithm: sha256WithRSAEncryption
> > > Issuer: O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE>
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>,
> > > CN=Certificate Authority
> > > Validity
> > > Not Before: Oct 29 10:39:47 2019 GMT
> > > Not After : Oct 29 09:39:47 2021 GMT
> > > Subject: O=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>, CN=dmud
> > > Subject Public Key Info:
> > > Public Key Algorithm: rsaEncryption
> > > Public-Key: (2048 bit)
> > > Modulus:
> > >
> 00:ba:09:81:99:9b:17:99:07:5a:10:28:c8:7a:03:
> > > ...
> > >
> 18:db:02:ce:b4:66:ce:5a:e9:12:af:d3:da:bf:f7:
> > > 66:5f
> > > Exponent: 65537 (0x10001)
> > > X509v3 extensions:
> > > X509v3 Authority Key Identifier:
> > > keyid:D2:...70:BF
> > >
> > > X509v3 Subject Key Identifier:
> > > DE:...:51:0A
> > > X509v3 Subject Alternative Name:
> > > email:dmud@corp.mydomain.de
> <mailto:email%3Admud@corp.mydomain.de>
> > <mailto:email%3Admud@corp.mydomain.de
> <mailto:email%253Admud@corp.mydomain.de>>
> > > <mailto:email%3Admud@corp.mydomain.de
> <mailto:email%253Admud@corp.mydomain.de>
> > <mailto:email%253Admud@corp.mydomain.de
> <mailto:email%25253Admud@corp.mydomain.de>>>
> > > Authority Information Access:
> > > OCSP -
> URI:http://ipa-ca.corp.mydomain.de/ca/ocsp
> > >
> > >
> > > I did nothing to /var/lib/ipa/ra-agent.pem yet.
> > >
> > >
> > > чт, 21 нояб. 2019 г. в 16:54, 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>>>>:
> > >
> > > Dmitri Moudraninets wrote:
> > > > Hi Rob,
> > > >
> > > > Yes both masters are failing the same way. Output
> of openssl
> > x509
> > > -noout
> > > > -modulus -in /var/lib/ipa/ra-agent.pem is the same on both
> > masters.
> > > > Output of openssl rsa -noout -modulus -in
> > /var/lib/ipa/ra-agent.key is
> > > > also the same on both masters. But the output of the first
> > command is
> > > > not the same as the output of the second command.
> > > >
> > > > I can't remember that I troubleshoot any other
> problems but we
> > > tried to
> > > > generate some personal certificates for some users.
> Also we
> > tried to
> > > > generate certificates with key files for some of our
> internal
> > > services.
> > > > We did that for the first time and it worked at the
> end. Also I
> > > changed
> > > > the admin password not so long ago.
> > > >
> > > >
> > > > Below you can find the output of the requested commands:
> > > >
> > > >
> > > > [root@second_master ~]# getcert list -f
> > /var/lib/ipa/ra-agent.pem
> > > > Number of certificates and requests being tracked: 9.
> > > > Request ID '20180912151730':
> > > > 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=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>
> > > <http://CORP.MYDOMAIN.DE>
> > > > <http://CORP.MYDOMAIN.DE>
> > > > subject: CN=dmud,O=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>
> > > <http://CORP.MYDOMAIN.DE>
> > > > *<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I see a username here.
> > Does it have
> > > > to be like that?*
> > > > expires: 2021-10-29 09:39:47 UTC
> > > > email: dmud(a)corp.mydomain.de
> <mailto:dmud@corp.mydomain.de> <mailto:dmud@corp.mydomain.de
> <mailto:dmud@corp.mydomain.de>>
> > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>
> <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>>>
> > > <mailto:dmud@corp.mydomain.de
> <mailto:dmud@corp.mydomain.de> <mailto:dmud@corp.mydomain.de
> <mailto:dmud@corp.mydomain.de>>
> > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>
> <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>>>>
> > > > key usage:
> > >
> digitalSignature,nonRepudiation,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
> > >
> > > Right, someone overwrote the RA agent certificate.
> > >
> > > Look to see if the user entry in the CA has the right cert:
> > >
> > > $ ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory
> manager'
> > -W -b
> > > uid=ipara,ou=People,o=ipaca usercertificate
> > >
> > > Put the base64 value of the usercertificate attribute into a
> > file and
> > > add a prefix/suffix around it:
> > >
> > > -----BEGIN CERTIFICATE-----
> > > MII....blah=
> > > -----END CERTIFICATE-----
> > >
> > > $ openssl x509 -text -in /path/to/file
> > >
> > > If the Subject is O = CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>, CN
> > > = IPA RA then that's a good
> > > start. Also look at the expires date to be sure it is
> still valid.
> > >
> > > Assuming that is ok then re-run the openssl modulus commands
> > to ensure
> > > they are the same.
> > >
> > > Assuming that too is ok then you have the proper, valid RA
> > agent cert.
> > > In that case I'd move the current file out of the way, who
> > knows what it
> > > is, then run:
> > >
> > > # openssl x509 -in /path/to/file -out
> > /var/lib/ipa/ra-agent.pem (just to
> > > properly format the agent cert)
> > > # chown root:ipaapi /var/lib/ipa/ra-agent.pem
> > > # chmod 0440 /var/lib/ipa/ra-agent.pem
> > > # restorecon /var/lib/ipa/ra-agent.pem
> > >
> > > Then try something like: ipa cert-show 1
> > >
> > > This will exercise the RA agent cert and as long as you
> don't
> > get an
> > > error back things are working again.
> > >
> > > The cert is common among all masters so you can copy the
> file
> > to your
> > > other master(s), ensuring proper ownership, permissions and
> > SELinux
> > > context.
> > >
> > > rob
> > >
> > >
> > >
> > > --
> > > WBR
> > > Dmitry
> >
> >
> >
> > --
> > With best regards/Mit freundlichen Grüßen
> >
> > Moudraninets Dmitry, RHCSA
> > http://www.linkedin.com/in/moudraninets
> > http://www.xing.com/profile/Dmitry_Mudraninets
>
>
>
> --
> With best regards/Mit freundlichen Grüßen
>
> Moudraninets Dmitry, RHCSA
> http://www.linkedin.com/in/moudraninets
> http://www.xing.com/profile/Dmitry_Mudraninets
4 years, 1 month
kdb5_util: Kerberos database constraints violated while adding entries to the database
by Djan D
HI
Installed a fresh IPA server on CentOS 6 and all services are up and
running. While trying to create database for the first-time, i am facing
following error.
* # /usr/sbin/kdb5_util create -r TESTLAB.ORG <http://TESTLAB.ORG>
-sLoading random dataInitializing database
'/var/kerberos/krb5kdc/principal' for realm '* TESTLAB.ORG
*',master key name 'K/M@* TESTLAB.ORG
*'You will be prompted for the database Master Password.It is important
that you NOT FORGET this password.Enter KDC database master key:Re-enter
KDC database master key to verify:*
*kdb5_util: Kerberos database constraints violated while adding entries to
the database *
Facing the same error while trying to create a principal:
# kadmin.local -q "add_principal -randkey reader@ TESTLAB.ORG "
Authenticating as principal admin/admin@ TESTLAB.ORG with password.
WARNING: no policy specified for reader@ TESTLAB.ORG ; defaulting to no
policy
add_principal: Kerberos database constraints violated while creating
"reader@ TESTLAB.ORG ".
Can anyone point to me the exact reason for the error ?
Regards
4 years, 1 month
FreeIPA Diskless Client Issues with sssd ssh
by Mark L. Potter
Greetings,
I am implementing FreeIPA in a large environment ro replace OpenLDAP. I have the initial client configuration scripted as the machines are diskless and almost everything is working properly. However I cannot seem to FreeIPA managed user ssh keys working with sssd. I have been reading for a couple of days and haven't found the answer as of yet. Here is what I have discerned to be pertinent information. I will gladly add anything else that's necessary. When 'sss_ssh_authorizedkeys markp --debug 10' produces no output at all and no errors. I cannot ssh between hosts without entering a password or using authorized_keys.
'journalctl -u sssd' shows:
Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 1
Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 1
Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 1
Feb 28 11:38:40 hud9 sssd_be[3345]: GSSAPI client step 2
OS: CentOS 7.4
Packages: ipa-client-4.6.5-11.el7.centos.4.x86_64 sssd-1.16.4-21.el7_7.1.x86_64
sssd.conf:
[domain/example.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = host.example.com
chpass_provider = ipa
ipa_server = ipaserver.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
config_file_version = 2
services = nss, sudo, pam, ssh
domains = example.com
[nss]
homedir_substring = /home
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[secrets]
[session_recording]
openldap/ldap.conf
# File modified by ipa-client-install
TLS_CACERTDIR /etc/openldap/certs
# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON on
URI ldaps://ipaserver.example.com
BASE dc=dugeo,dc=com
TLS_CACERT /etc/ipa/ca.crt
SASL_MECH GSSAPI
krb5.conf
#File modified by ipa-client-install
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
dns_canonicalize_hostname = false
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
EXAMPLE.COM = {
kdc = ipaserver.example.com:88
master_kdc = ipaserver.example.com:88
admin_server = ipaserver.example.com:749
kpasswd_server = ipaserver.example.com:464
default_domain = example.com
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
host.example.com = EXAMPLE.COM
I am hoping there's something simple that I am missing here, something I've overlooked or managed to just suck at library skills. Thanks in advance for any help.
4 years, 1 month
How to make ipa root certificate available system wide
by Kevin Vasko
Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
4 years, 1 month
sshd.config overwriten during FIRST ipa-client-installation
by pgb205
1. Happens on RHEL/Centos only(other distros are not affected)
2. Happens only during the first attempted install of ipa-client package. If we try to reinstall the sshd.conf is not modified.3. We tried with --no-sshd flag to prevent sshd configuration
as suggested in the following ticket
[Freeipa-devel] [PATCH] 85 Add --no-ssh option to ipa-client-install to
We no longer get an messages in /var/log/ipaclientinstall.log about sshd.conf being backed up, BUT the file still gets changed.
4 years, 1 month
Netscape Portable Runtime error -5999
by Sarah PETER
Hello,
on one of our FreeIPA servers we recently got the following error messages:
[05/Feb/2020:22:51:44.078229410 +0100] - ERR - write_function - PR_Write(392) Netscape Portable Runtime error -5999 (Invalid file descriptor.)
[21/Feb/2020:08:25:39.507298208 +0100] - ERR - write_function - PR_Write(273) Netscape Portable Runtime error -5999 (Invalid file descriptor.)
On the second incident, one of the other replicas shortly lost connection to the server with the above error:
[21/Feb/2020:08:25:39.619051486 +0100] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTolPA2" (IPA2:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()
[21/Feb/2020:08:25:43.220221699 +0100] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToIPA2" (IPA2:389): Replication bind with GSSAPI auth resumed
Does anyone know what these errors mean and if there's anything we should do about them? I tried searching for them, but came up with nothing. So far it seems it hasn't affected the operation of our FreeIPA infrastructure.
Thanks in advance for your help.
Best regards,
Sarah
----
Sarah Peter
LCSB Bioinformatics Core & UL HPC Team
UNIVERSITÉ DU LUXEMBOURG
LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | Biotech II
6, avenue du Swing
L-4371 Belvaux
T +352 46 66 44 5360
sarah.peter(a)uni.lu<mailto:sarah.peter@uni.lu> http://lcsb.uni.lu<http://lcsb.uni.lu/>
-----
This message is confidential and may contain privileged information. It is intended for the named recipient only. If you receive it in error please notify me and permanently delete the original message and any copies.
-----
4 years, 1 month