LDAP error after re-initializing replica server
by Hirata, Tyler
I’m testing out IPA and wanted to see how restoring backups work. I successfully restored an older backup to my master node, but when I hop on my replica nodes and run the re-initialization command, I get an LDAP error. I was wondering if anyone has experienced this?
ipa-replica-manage re-initialize --from ipa1.domain.com
Update in progress, 15 seconds elapsed
[ldaps:// ipa1.domain.com:636] reports: Update failed! Status: [Error (49) - LDAP error: Invalid credentials - no response received]
I’ve cleared all my Kerberos cache by running kdestroy and I restarted directory services and rebooted the primary and secondary servers.
Tyler
1 year, 3 months
Ubuntu clients and su
by Ranbir
Hi Everyone,
When I try to run "sudo su - [user]" on an Ubuntu 20 or Ubuntu 22
client, I get the error "su: Permisison denied". Upon enabling
debug_level = 6 for the domain, I saw in the log the message "Access
denied by HBAC rules".
Well, that's odd since my user is in a group that is allowed to login
to any client using any service. In fact, when I try to run the same
command from a CentOS or AlmaLinux client, the su succeeds.
After adding the "su" and "su-l" HBAC Services to the group of the user
I'm trying to su to, the command worked on the Ubuntu clients.
I'm confused as to why the clients are behaving differently. I also
don't know which client is responding correctly before adding the "su"
and "su-l" HBAC Services to the user group the user is a member of.
Has anyone else run into this? Am I doing something incorrectly?
--
Ranbir
1 year, 3 months
FreeIPA CA failing to login with new admin user
by Stasiek Michalski
Hello,
I installed FreeIPA replica on 4.8.4 on CentOS 8 from 4.4.4 from Fedora
25 with `ipa-replica-install --setup-dns --auto-forwarders`, without
`--setup-ca` due to errors, which went fine. I do want to install CA
though, which failed when I did `--setup-ca` and then later
`ipa-ca-install` with the following error:
```
[4/29]: creating installation admin user
Unable to log in as uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca on ldap://freeipa.infra.opensuse.org:389
[hint] tune with replication_wait_timeout
[error] NotFound: uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca did not replicate to ldap://freeipa.infra.opensuse.org:389
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
```
Obviously I did try try extending the timeout based on that, but I don't
think that was helpful in the end, considering the logs produced by the
old server:
httpd access_log
```
192.168.47.90 - - [23/Jul/2020:00:25:36 +0000] "GET /ca/rest/account/login HTTP/1.1" 401 994
```
server process in journal
```
SSLAuthenticatorWithFallback: Authenticating with BASIC authentication
Invalid Credential.
at com.netscape.cmscore.authentication.PasswdUserDBAuthentication.authenticate(PasswdUserDBAuthentication.java:167)
at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:63)
at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:78)
at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:94)
at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:37)
at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:98)
at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:47)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:579)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:502)
at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:877)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1539)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1495)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
SSLAuthenticatorWithFallback: Fallback auth header: WWW-Authenticate=Basic realm="Certificate Authority"
SSLAuthenticatorWithFallback: Fallback auth return code: 401
SSLAuthenticatorWithFallback: Result: false
```
and from pki logs
```
Failed to authenticate as admin UID=admin-freeipa2.infra.opensuse.org. Error: netscape.ldap.LDAPException: error result (49)
```
I don't particularly know how to proceed from here, since those errors
don't mean much to me. I see however it's not just me having issues with
`ipa-ca-install` at least similar to this one (although by the looks of
it, the reason is already different ;)
Thanks in advance for trying,
LCP [Stasiek]
https://lcp.world/
1 year, 3 months
Error while reading kernel policy
by Ben Aveling
When a particular user tries to login on a particular host, we are seeing an error in the logs, something like this:
(2022-12-15 13:24:51): [selinux_child[1096]] [sss_seuser_exists] (0x0400): seuser exists: no
(2022-12-15 13:24:51): [selinux_child[1096]] [seuser_needs_update] (0x0400): The SELinux user does need an update
(2022-12-15 13:24:51): [selinux_child[1096]] [libsemanage] (0x0020): Error while reading kernel policy from /etc/selinux/targeted/active/policy.linked.
(2022-12-15 13:24:51): [selinux_child[1096]] [main] (0x0020): Cannot set SELinux login context.
(2022-12-15 13:24:51): [selinux_child[1096]] [main] (0x0020): selinux_child failed!
The file /etc/selinux/targeted/active/policy.linked existed, but was empty.
Reproducing on a lab machine, deliberately emptying that file, the problem was reproducible - for new users, though not for old users. Presumably, caching at work, somewhere.
Deleting the empty file and then trying again, policy.linked was rebuilt, and then logins started succeeding.
(2022-12-15 15:07:03): [selinux_child[3412]] [main] (0x0400): selinux_child started.
(2022-12-15 15:07:03): [selinux_child[3412]] [main] (0x0400): context initialized
(2022-12-15 15:07:03): [selinux_child[3412]] [main] (0x0400): performing selinux operations
(2022-12-15 15:07:03): [selinux_child[3412]] [sss_seuser_exists] (0x0400): seuser exists: no
(2022-12-15 15:07:03): [selinux_child[3412]] [seuser_needs_update] (0x0400): The SELinux user does need an update
(2022-12-15 15:07:14): [selinux_child[3412]] [pack_buffer] (0x0400): result [0]
(2022-12-15 15:07:14): [selinux_child[3412]] [main] (0x0400): selinux_child completed successfully
I'm hopeful that the same thing will work on the other box - will let you know if it doesn't. :-)
1 year, 3 months
Max number of users
by phiroc@free.fr
Hello,
what is the maximum number of users you can add to freeipa?
Many thanks.
Best regards,
Philippe
1 year, 3 months
Kerberos/GSSAPI dovecot auth wierdeness?
by Carlos Mogas da Silva
Hi list!
I'm migrating my server into a new REALM (INT.R3PEK.ORG) from an old one
(R3PEK.ORG). This is a completely new install and configuration, so no
leftovers exits.
The machine is correctly register into the REALM and users are able to
login without a problem.
Now, when I try to login using a Kerberos ticket, for some reason that I
can't understand, dovecot is looking for a ticket on the old REALM.
Maybe because of the email domain (which stayed the same)? This is the
error message I see on the clients:
"Failed to authenticate: Server krbtgt/R3PEK.ORG(a)INT.R3PEK.ORG"
The one it should be looking for is krbtgt/INT.R3PEK.ORG(a)INT.R3PEK.ORG,
but I can't seem to figure out where the problem is.
I've posted the same email to the dovecot mailing list, but since I'm
not sure this is a dovecot/configuration issue or something that I
should have done on the FreeIPA side, I'm posting it here too just to
have some feedback.
Thanks!
1 year, 3 months
Issues upgrading FreeIPA 4.7 -> 4.8
by Johannes Falke
After postponing the my home network FreeIPA server upgrade (FreeIPA 4.7.x/Fedora 29 -> FreeIPA 4.8.x/Fedora 30) due previously running into this error already, I am running into the same error again but now want to fix it. On FreeIPA 4.7.x/Fedora 29 my set-up was judged healthy by ipa-healthcheck.
However, `ipa-server-upgrade` fails with the message "Failed to authenticate to CA REST API".
The pki-tomcatd(a)pki-tomcat.service log (during the upgrade) looks as follows:
```
Dec 11 21:17:16 ipa.my.domain systemd[1]: Starting PKI Tomcat Server pki-tomcat...
Dec 11 21:17:16 ipa.my.domain pki-server[2405]: ----------------------------
Dec 11 21:17:16 ipa.my.domain pki-server[2405]: pki-tomcat instance migrated
Dec 11 21:17:16 ipa.my.domain pki-server[2405]: ----------------------------
Dec 11 21:17:17 ipa.my.domain systemd[1]: Started PKI Tomcat Server pki-tomcat.
Dec 11 21:17:17 ipa.my.domain server[2514]: Java virtual machine used: /usr/lib/jvm/jre-1.8.0-openjdk/bin/java
Dec 11 21:17:17 ipa.my.domain server[2514]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar
Dec 11 21:17:17 ipa.my.domain server[2514]: main class used: org.apache.catalina.startup.Bootstrap
Dec 11 21:17:17 ipa.my.domain server[2514]: flags used: -Djava.library.path=/usr/lib64/nuxwdog-jni
Dec 11 21:17:17 ipa.my.domain server[2514]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.security.manager -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy
Dec 11 21:17:17 ipa.my.domain server[2514]: arguments used: start
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Attempt to log message "/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit" to closed log file 0.main - [11/Dec/2022:21:17:22 CET] [14] [6] [AuditEvent=AUDIT_LOG_SHUTDOWN][SubjectID=$System$][Outcome=Success] audit function shutdown
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Failed to write in file: "AUDIT_LOG_SHUTDOWN", entry: Attempt to log message "/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit" to closed log file 0.main - [11/Dec/2022:21:17:22 CET] [14] [6] [AuditEvent=AUDIT_LOG_SHUTDOWN][SubjectID=$System$][Outcome=Success] audit function shutdown, error: Audit Event Failure!
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Attempt to log message "/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit" to closed log file 0.main - [11/Dec/2022:21:17:22 CET] [14] [6] [AuditEvent=AUDIT_LOG_SHUTDOWN][SubjectID=$System$][Outcome=Success] audit function shutdown
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Failed to write in file: "AUDIT_LOG_SHUTDOWN", entry: Attempt to log message "/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit" to closed log file 0.main - [11/Dec/2022:21:17:22 CET] [14] [6] [AuditEvent=AUDIT_LOG_SHUTDOWN][SubjectID=$System$][Outcome=Success] audit function shutdown, error: Audit Event Failure!
Dec 11 21:17:28 ipa.my.domain server[2514]: SEVERE: CA subsystem unavailable. Check CA debug log.
Dec 11 21:17:33 ipa.my.domain server[2514]: SEVERE: CA subsystem unavailable. Check CA debug log.
```
after which pki-tomcatd@pki-tomcat crashes.
the pki-tomcat CA debug log has the following SEVERE exceptions:
/var/log/pki/pki-tomcat/ca/debug.2022-12-11.log
```
[...]
2022-12-11 21:17:22 [main] FINE: LdapBoundConnection: Connecting to ipa.my.domain:636 with client cert auth
2022-12-11 21:17:22 [main] FINE: ldapconn/PKISocketFactory.makeSSLSocket: begins
2022-12-11 21:17:22 [main] FINE: SignedAuditLogger: event CLIENT_ACCESS_SESSION_ESTABLISH
2022-12-11 21:17:22 [main] FINE: LogFile: event type not selected: CLIENT_ACCESS_SESSION_ESTABLISH
2022-12-11 21:17:22 [main] SEVERE: Unable to create socket: java.net.ConnectException: Connection refused (Connection refused)
java.net.ConnectException: Connection refused (Connection refused)
[...traceback...]
2022-12-11 21:17:22 [main] SEVERE: LdapBoundConnFactory: Unable to connect to LDAP server: Unable to create socket: java.net.ConnectException: Connection refused (Connection refused)
[...traceback...]
2022-12-11 21:17:22 [main] SEVERE: DBSubsystem: initialization failed: Unable to connect to LDAP server: Unable to create socket: java.net.ConnectException: Connection refused (Connection refused)
[...traceback...]
2022-12-11 21:17:22 [main] SEVERE: Unable to start CMS engine: Internal Database Error encountered: Unable to connect to LDAP serve
r: Unable to create socket: java.net.ConnectException: Connection refused (Connection refused)
[...traceback...]
2022-12-11 21:17:22 [main] SEVERE: Shutting down.
2022-12-11 21:17:22 [main] INFO: Shutting down CA subsystem
[...]
```
Looking at the `journalctl` log, it seems the dirsrv(a)MY-DOMAIN.service receives a stop command during the ipa-server-upgrade script just before this error occurs.
Dec 11 21:17:19 ipa.my.domain systemd[1]: Stopping 389 Directory Server MY-DOMAIN....
Dec 11 21:17:19 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:19.575684141 +0100] - INFO - op_thread_cleanup - slapd shutting d>
Dec 11 21:17:19 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:19.581818694 +0100] - INFO - slapd_daemon - slapd shutting down ->
Dec 11 21:17:19 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:19.595175102 +0100] - INFO - slapd_daemon - slapd shutting down ->
Dec 11 21:17:20 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:20.597957402 +0100] - INFO - dblayer_pre_close - Waiting for 4 da>
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Attempt to log message "/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit" to>
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Failed to write in file: "AUDIT_LOG_SHUTDOWN", entry: Attempt to log message "/v>
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Attempt to log message "/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit" to>
Dec 11 21:17:22 ipa.my.domain server[2514]: main: Failed to write in file: "AUDIT_LOG_SHUTDOWN", entry: Attempt to log message "/v>
Dec 11 21:17:22 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:22.815909751 +0100] - INFO - dblayer_pre_close - All database thr>
Dec 11 21:17:22 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:22.831586103 +0100] - INFO - ldbm_back_instance_set_destructor - >
Dec 11 21:17:22 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:22.851949498 +0100] - INFO - connection_post_shutdown_cleanup - s>
Dec 11 21:17:22 ipa.my.domain ns-slapd[2338]: [11/Dec/2022:21:17:22.864268380 +0100] - INFO - main - slapd stopped.
Dec 11 21:17:23 ipa.my.domain systemd[1]: dirsrv(a)MY-DOMAIN.service: Succeeded.
Dec 11 21:17:23 ipa.my.domain systemd[1]: Stopped 389 Directory Server MY-DOMAIN..
Dec 11 21:17:23 ipa.my.domain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 m>
Dec 11 21:17:23 ipa.my.domain systemd[1]: Starting 389 Directory Server MY-DOMAIN....
I'm not sure how the LDAP connection is supposed to work if the LDAP server gets shut down, but since this is all handled/managed by ipa-server-upgrade, I assume this is correct...? Or is this some bug in the ipa-server-upgrade script?
Does anyone have a clue what the root cause of this error might be or how to figure it out?
1 year, 3 months
Named failing the whole time
by Francis Augusto Medeiros-Logeay
Hi,
I know this mail has very few info - will add them later - but are there common causes for named to crash randomly?
My FreeIPA réplica has been so unstable. actually, named crashes.
Any hints on where to look? Once I had the replica to blame, it lost contact with the other replicas and had to be rejoined.
Thanks in advance for any clues.
Best,
__
Francis Augusto Medeiros-Logeay
Oslo, Norway
Sent from a mobile device / Enviado a partir de dispositivo móvel
1 year, 3 months