tomcatd - Could not connect to LDAP server host
by Jack Henschel
Hello,
we ran into an issue after an upgrade to FreeIPA 4.6.4, API_VERSION:
2.229 (using the current Docker Image Fedora 27)
The ipa-upgrade ran without issues, but pki-tomcatd is causing trouble
after the upgrade.
The tomcatd system log:
0.localhost-startStop-1 - [05/Nov/2018:08:44:41 UTC] [8] [3] In Ldap
(bound) connection pool to host ipa port 636, Cannot connect to LDAP
server. Error: netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
Tomcat Debug log:
java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
Could not connect to LDAP server host ipa port 636 Error
netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
Internal Database Error encountered: Could not connect to LDAP
server host ipa port 636 Error netscape.ldap.LDAPException: Unable to
create socket: java.net.ConnectException: Connection refused (Connection
refused) (-1)
at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:689)
However, the dirsrv starts just seconds afterwards:
Nov 05 08:44:45 ipa ns-slapd[90]: [05/Nov/2018:08:44:45.159306972
+0000] - INFO - slapd_daemon - slapd started. Listening on All
Interfaces port 389 for LDAP requests
Nov 05 08:44:45 ipa ns-slapd[90]: [05/Nov/2018:08:44:45.162543716
+0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for
LDAPS requests
Nov 05 08:44:45 ipa systemd[1]: Started 389 Directory Server
Then, certmonger fails to start (probably trying to reach tomcatd, I
assume):
Nov 05 08:45:41 ipa systemd[1]: certmonger.service: Start-post
operation timed out. Stopping.
Nov 05 08:45:50 ipa server[231]: WARNING: Exception processing
realm com.netscape.cms.tomcat.ProxyRealm@3b86a3a1 background process
Nov 05 08:45:50 ipa server[231]:
javax.ws.rs.ServiceUnavailableException: Subsystem unavailable
Nov 05 08:45:50 ipa server[231]: at
com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:130)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1156)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5740)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:
1379)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:
1383)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1351)
Nov 05 08:45:50 ipa server[231]: at
java.lang.Thread.run(Thread.java:748)
Nov 05 08:45:56 ipa systemd[1]: Failed to start Certificate
monitoring and PKI enrollment.
Nov 05 08:45:56 ipa systemd[1]: certmonger.service: Unit entered
failed state.
Nov 05 08:45:56 ipa systemd[1]: certmonger.service: Failed with
result 'timeout'.
After that, IPA shuts down after 300 sec.
Nov 05 08:50:01 ipa systemd[1]: Stopping Kerberos 5 KDC...
Nov 05 08:50:01 ipa systemd[1]: Stopped Kerberos 5 KDC.
Nov 05 08:50:01 ipa systemd[1]: Stopping Kerberos 5
Password-changing and Administration...
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Main process
exited, code=exited, status=2/INVALIDARGUMENT
Nov 05 08:50:01 ipa systemd[1]: Stopped Kerberos 5
Password-changing and Administration.
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Unit entered failed
state.
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Failed with result
'exit-code'.
Nov 05 08:50:02 ipa systemd[1]: Stopping The Apache HTTP Server...
Nov 05 08:50:03 ipa systemd[1]: Stopped The Apache HTTP Server.
Nov 05 08:50:03 ipa systemd[1]: Stopping IPA Custodia Service...
Nov 05 08:50:03 ipa systemd[1]: Stopped IPA Custodia Service.
Nov 05 08:50:03 ipa ntpd[73]: ntpd exiting on signal 15 (Terminated)
Nov 05 08:50:03 ipa ntpd[73]: 127.127.1.0 local addr 127.0.0.1 ->
Nov 05 08:50:03 ipa systemd[1]: Stopping Network Time Service...
Nov 05 08:50:03 ipa systemd[1]: Stopped Network Time Service.
Nov 05 08:50:03 ipa systemd[1]: Stopped target PKI Tomcat Server.
Nov 05 08:50:03 ipa systemd[1]: Stopping PKI Tomcat Server
pki-tomcat...
The error is consistent enough, it seems LDAP only comes up seconds
after tomcat tries to reach it.
Nov 05 09:34:57 ipa server[231]: Internal Database Error
encountered: Could not connect to LDAP server host ipa port 636 E rror
netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.793590657
+0000] - INFO - slapd_daemon - slapd started. Listening on All
Interfaces port 389 for LDAP requests
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.812565603
+0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for
LDAPS requests
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.814451330
+0000] - INFO - slapd_daemon - Listening on
/var/run/slapd-VISION-FHG-DE.socket for LDAPI requests
Since it's not an Authentication Error, as described here:
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tom...
I don't think this is an issue with the certificates. Nonetheless, I
checked them and it seems fine.
When starting FreeIPA via ipactl start, however, the system starts -
certmonger remains failed though. The system isn't fully functional though.
This is how we start the Container:
/usr/bin/docker run \
-h 'ipa' --net bridge -m 0b -e IPA_SERVER_IP=192.168.2.15 \
-e IPA_SERVER_HOSTNAME=ipa \
-p 80:80 \
-p 443:443 \
-p 88:88/tcp \
-p 88:88/udp \
-p 389:389 \
-p 636:636 \
-p 7389:7389 \
-p 464:464/tcp \
-p 464:464/udp \
-p 123:123 \
-p 9443:9443 \
-p 9444:9444 \
-p 9445:9445 \
-v /data/ipa:/data:Z \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
--tmpfs /tmp --tmpfs /run --sysctl net.ipv6.conf.all.disable_ipv6=0
--cap-add=SYS_ADMIN --cap-add SYS_TIME \
--name freeipa \
freeipa/freeipa-server:fedora-27 \
Any idea what might cause this, or how we can futher debug it?
5 years, 5 months
IPA server upgrade fails with KDC error
by Johannes Brandstetter
Hi,
I'm trying to upgrade FreeIPA through ipa-server-upgrade from 4.4 to 4.5. The command fails with an "ACIError: Insufficient access:" . I find in the kdc log that it complains about " Database module does not match KDC version - while initializing database for realm..."
Does anybody know how to fix this?
Some more info:
$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
$ tail /var/log/krb5kdc.log
krb5kdc: Server error - while fetching master key K/M for realm XXX
krb5kdc: Database module does not match KDC version - while initializing database for realm XXX
$ sudo less /var/log/ipaupgrade.log
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG duration: 0 seconds
2017-10-16T13:04:13Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2017-10-16T13:04:14Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run
server.upgrade()
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1896, in upgrade
data_upgrade.create_instance()
File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 124, in create_instance
runtime=90)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 504, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 494, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 96, in __start
api.Backend.ldap2.connect()
File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect
conn = self.create_connection(*args, **kw)
File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 190, in create_connection
client_controls=clientctrls)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1111, in external_bind
'', auth_tokens, server_controls, client_controls)
File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
self.gen.throw(type, value, traceback)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1007, in error_handler
raise errors.ACIError(info=info)
2017-10-16T13:04:14Z DEBUG The ipa-server-upgrade command failed, exception: ACIError: Insufficient access:
2017-10-16T13:04:14Z ERROR Insufficient access:
2017-10-16T13:04:14Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information
$ sudo less /var/log/yum.log
Oct 16 05:36:02 Updated: ipa-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:02 Updated: ipa-client-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:25 Updated: libipa_hbac-1.15.2-50.el7_4.2.x86_64
Oct 16 05:36:53 Updated: python-libipa_hbac-1.15.2-50.el7_4.2.x86_64
Oct 16 05:36:55 Updated: python2-ipalib-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:55 Updated: python2-ipaclient-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:37:23 Updated: ipa-python-compat-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:43 Updated: ipa-server-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:44 Updated: python2-ipaserver-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:44 Updated: sssd-ipa-1.15.2-50.el7_4.2.x86_64
Oct 16 05:39:01 Installed: ipa-client-4.5.0-21.el7.centos.1.2.x86_64
Oct 16 05:39:28 Updated: ipsilon-tools-ipa-2.0.2-5.el7.centos.noarch
Oct 16 05:39:29 Updated: ipa-server-4.5.0-21.el7.centos.1.2.x86_64
Oct 16 05:40:48 Erased: ipa-admintools-4.4.0-14.el7.centos.7.noarch
Oct 16 05:19:30 Updated: krb5-libs-1.15.1-8.el7.x86_64
Oct 16 05:19:30 Updated: krb5-workstation-1.15.1-8.el7.x86_64
Oct 16 05:19:31 Updated: krb5-server-1.15.1-8.el7.x86_64
Oct 16 05:19:31 Updated: krb5-pkinit-1.15.1-8.el7.x86_64
Oct 16 05:38:22 Updated: sssd-krb5-common-1.15.2-50.el7_4.2.x86_64
Oct 16 05:38:57 Updated: sssd-krb5-1.15.2-50.el7_4.2.x86_64
Cheers,
Johannes
5 years, 6 months
RSA using FreeIPA as an identity source
by Angus Clarke
Hi all
Excuse my ignorance, can anyone give me some pointers on getting RSA
Authentication Manager 8 to use FreeIPA 4.5 as an identity source over
LDAPS?
Many thanks
Angus
5 years, 6 months
Migration from Test to Production
by Ronald Wimmer
Hi,
we have been evaluating FreeIPA for quite a while now on our test setup
(1 IPA server, 1 Replica) and are planning to move towards production.
Can the whole setup be migrated from an ipa test to an ipa production
server? (the ipa 'linux.ourdomain.at' domain should stay the same) Or
would it be easier to use both test servers for production (and just
adding additional replicas)?
Cheers,
Ronald
5 years, 6 months
Can OTP use as other datasource other than LDAP?
by luckydog xf
when I deploy freeipa with build-in LDAP( 389 DS), and create user with OTP password enabled, I can integrate into freeradius with LDAP module to authenticate against Network Access Service( Switch.etc) with user's password and OTP password.
My question is that, our vpn only supports MSchap authenticaion, while I want to use MS Active Directory as freeipa datastore ( Don't use 389 DS) , if OTP works as well, it's great.
yet judging from https://www.freeipa.org/page/V4/OTP, it's only applicable to LDAP.
5 years, 6 months
New clients doesn't allow to use AD users with shortnames and showing the users/groups also with short names
by SOLER SANGUESA Miguel
I've been working for 1 year with a configuration that allow us to use AD users with short names for login on RHEL 6 clients and also the information on the client was showed with shortnames. Example:
ssh AD_user(a)IDM_client1.mydomain.com
PASSWORD:
[AD_user@IDM_client1 ~]$ ls -la
total 60
drwxr-x--- 5 AD_user AD_group 4096 Nov 21 08:53 .
drwxr-xr-x. 40 root root 4096 Oct 29 09:12 ..
-rw------- 1 AD_user AD_group 281 Jul 27 00:13 .bash_history
-rw-r----- 1 AD_user AD_group 18 Oct 8 2015 .bash_logout
-rw-r----- 1 AD_user AD_group 176 Oct 8 2015 .bash_profile
-rw-r----- 1 AD_user AD_group 124 Oct 8 2015 .bashrc
[AD_user@IDM_client1 ~]$ id
uid=1156200001(AD_user) gid=1156200014(AD_group) groups=1156200014(AD_group),10001(AD_group2),20001(IDM_group1),1156200000(admins)...
My sssd configuration is (marked lines added for this configuration):
[domain/ipa.mydomain.com]
krb5_auth_timeout = 90
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.mydomain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = IDM_client1.mydomain.com
chpass_provider = ipa
ipa_server = _srv_, IDM_server1.ipa.mydomain.com, IDM_server2.ipa.mydomain.com
dns_discovery_domain = ipa.mydomain.com
use_fully_qualified_names = true <------------------------
subdomain_homedir=%o
[sssd]
config_file_version = 2
services = nss, sudo, pam, ssh
domains = ipa.mydomain.com
default_domain_suffix = AD_domain.mydomain.com <------------------------
full_name_format = %1$s <------------------------
[nss]
filter_groups = root
filter_users = root,iccsecure,tomcat,oracle
reconnection_retries = 3
[pam]
reconnection_retries = 3
[sudo]
[ssh]
But I have realized that new RHEL 6 clients are not working like that anymore. Using the SAME configuration I can not login with short name (doesn't match HABC rule because don't show IDM_groups of the user, logs at the bottom). On the console I can see that my user (short name) just have the main group of the AD, all other groups have disappeared:
[AD_user@IDM_client2 ~]$ id
uid=1156200001(AD_user) gid=1156200014(AD_group) groups=1156200014(AD_group)
So I have commented the line on sssd.conf as workaround:
#full_name_format = %1$s
But now I have long names showed on the client server and it is very annoying:
[AD_user@IDM_client2 ~]$ ls -la
total 20
drwxr-x--- 3 AD_user(a)AD_domain.mydomain.com AD_group(a)AD_domain.mydomain.com 4096 Nov 21 08:20 .
drwxr-xr-x 20 root root 4096 Mar 6 2018 ..
-rw------- 1 AD_user(a)AD_domain.mydomain.com AD_group(a)AD_domain.mydomain.com 110 Nov 21 08:07 .bash_history
drwx------ 2 AD_user(a)AD_domain.mydomain.com AD_group(a)AD_domain.mydomain.com 4096 Dec 14 2017 .ssh
-rw------- 1 AD_user(a)AD_domain.mydomain.com AD_group(a)AD_domain.mydomain.com 138 Nov 21 08:20 .Xauthority
On the servers were is working fine if I erased sssd cache and restarted sssd, then it has the problem.
So should be something that has change on the latests updates and we didn't realized because we were using the cache for login. And now that we have added new servers to IDM we have discovered the problem.
Can you please let me know how to configure nowadays sssd for having short names on the login for AD users and short names showed on the machine?
#### versions I'm using:#######
--- IDM SERVERS - RHEL 7.5: ---
ipa-common-4.5.4-10.el7_5.4.4.noarch
ipa-python-compat-4.5.4-10.el7_5.4.4.noarch
ipa-server-4.5.4-10.el7_5.4.4.x86_64
ipa-server-common-4.5.4-10.el7_5.4.4.noarch
ipa-server-dns-4.5.4-10.el7_5.4.4.noarch
ipa-server-trust-ad-4.5.4-10.el7_5.4.4.x86_64
libipa_hbac-1.16.0-19.el7_5.8.x86_64
sssd-1.16.0-19.el7_5.8.x86_64
sssd-ad-1.16.0-19.el7_5.8.x86_64
sssd-client-1.16.0-19.el7_5.8.x86_64
sssd-common-1.16.0-19.el7_5.8.x86_64
sssd-common-pac-1.16.0-19.el7_5.8.x86_64
sssd-dbus-1.16.0-19.el7_5.8.x86_64
sssd-ipa-1.16.0-19.el7_5.8.x86_64
sssd-krb5-1.16.0-19.el7_5.8.x86_64
sssd-krb5-common-1.16.0-19.el7_5.8.x86_64
sssd-ldap-1.16.0-19.el7_5.8.x86_64
sssd-proxy-1.16.0-19.el7_5.8.x86_64
sssd-tools-1.16.0-19.el7_5.8.x86_64
--- IDM CLIENTS - RHEL 6.10: ---
ipa-admintools-3.0.0-51.el6.x86_64
ipa-client-3.0.0-51.el6.x86_64
ipa-python-3.0.0-51.el6.x86_64
libipa_hbac-1.13.3-60.el6.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
python-libipa_hbac-1.13.3-60.el6.x86_64
python-sssdconfig-1.13.3-60.el6.noarch
sssd-1.13.3-60.el6.x86_64
sssd-ad-1.13.3-60.el6.x86_64
sssd-client-1.13.3-60.el6.x86_64
sssd-common-1.13.3-60.el6.x86_64
sssd-common-pac-1.13.3-60.el6.x86_64
sssd-ipa-1.13.3-60.el6.x86_64
sssd-krb5-1.13.3-60.el6.x86_64
sssd-krb5-common-1.13.3-60.el6.x86_64
sssd-ldap-1.13.3-60.el6.x86_64
sssd-proxy-1.13.3-60.el6.x86_64
sssd-tools-1.13.3-60.el6.x86_64
##### LOGS #####
* /var/log/sssd/sssd_ipa.mydomain.com.log (debug_level = 8):
...
[sssd[be[ipa.mydomain.com]]] [get_groups_dns] (0x0400): Root domain uses fully-qualified names, objects might not be correctly added to groups with short names.
[sssd[be[ipa.mydomain.com]]] [get_groups_dns] (0x0400): Root domain uses fully-qualified names, objects might not be correctly added to groups with short names.
[sssd[be[ipa.mydomain.com]]] [ipa_s2n_save_objects] (0x2000): Updating memberships for AD_user
[sssd[be[ipa.mydomain.com]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [Attribute or value exists](20)[attribute 'member': value #0 on 'name=IDM_group1,cn=groups,cn=ipa.mydomain.com,cn=sysdb' already exists]
[sssd[be[ipa.mydomain.com]]] [sysdb_mod_group_member] (0x0400): Error: 17 (File exists)
[sssd[be[ipa.mydomain.com]]] [sysdb_update_members_ex] (0x0020): Could not add member [AD_user] to group [name=IDM_group1,cn=groups,cn=ipa.mydomain.com,cn=sysdb]. Skipping.
----- (repeated with all IDM_groups) -----
....
----- the request -----
[sssd[be[ipa.mydomain.com]]] [be_pam_handler] (0x0100): Got request with the following data
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): domain: AD_domain.mydomain.com
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): user: AD_user
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): service: sshd
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): tty: ssh
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): ruser:
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): rhost: 10.XX.XX.XX
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): authtok type: 0
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): newauthtok type: 0
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): priv: 1
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): cli_pid: 54232
[sssd[be[ipa.mydomain.com]]] [pam_print_data] (0x0100): logon name: not set
[sssd[be[ipa.mydomain.com]]] [sdap_access_send] (0x0400): Performing access check for user [AD_user]
[sssd[be[ipa.mydomain.com]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [AD_user]
----- result (doesn't find any group for the user) -----
[sssd[be[ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [All server access]
[sssd[be[ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x2000): Source hosts disabled, setting ALL
[sssd[be[ipa.mydomain.com]]] [hbac_eval_user_element] (0x1000): No groups for [AD_user] <-----------------------------------------------
[sssd[be[ipa.mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
[sssd[be[ipa.mydomain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, <NULL>) [Success]
[sssd[be[ipa.mydomain.com]]] [be_pam_handler_callback] (0x0100): Sending result [6][AD_domain.mydomain.com]
[sssd[be[ipa.mydomain.com]]] [be_pam_handler_callback] (0x0100): Sent result [6][AD_domain.mydomain.com]
[sssd[be[ipa.mydomain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xc4a3c0], connected[1], ops[(nil)], ldap[0xc4f480]
[sssd[be[ipa.mydomain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc60100/0xc5ccf0
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc60100/0xc61480
[sssd[be[ipa.mydomain.com]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
[sssd[be[ipa.mydomain.com]]] [be_client_destructor] (0x0400): Removed PAC client
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc4c890/0xc4b5e0
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc4c890/0xc4b4a0
[sssd[be[ipa.mydomain.com]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
[sssd[be[ipa.mydomain.com]]] [be_client_destructor] (0x0400): Removed SSH client
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc475d0/0xc45780
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc475d0/0xc45730
[sssd[be[ipa.mydomain.com]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
[sssd[be[ipa.mydomain.com]]] [be_client_destructor] (0x0400): Removed PAM client
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc4ed40/0xc4c9e0
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc4ed40/0xc4c990
[sssd[be[ipa.mydomain.com]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
[sssd[be[ipa.mydomain.com]]] [be_client_destructor] (0x0400): Removed SUDO client
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc42380/0xc3e080
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc42380/0xc21350
[sssd[be[ipa.mydomain.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.IPA.MYDOMAIN.ORG], [2][No such file or directory]
[sssd[be[ipa.mydomain.com]]] [be_ptask_destructor] (0x0400): Terminating periodic task [SUDO Smart Refresh]
[sssd[be[ipa.mydomain.com]]] [be_ptask_destructor] (0x0400): Terminating periodic task [SUDO Full Refresh]
[sssd[be[ipa.mydomain.com]]] [sdap_handle_release] (0x2000): Trace: sh[0xc4a3c0], connected[1], ops[(nil)], ldap[0xc4f480], destructor_lock[0], release_memory[0]
[sssd[be[ipa.mydomain.com]]] [sbus_remove_watch] (0x2000): 0xc24320/0xc248e0
On the contrary on other IPA client without removing cache and same configuration it founds 13 groups:
[sssd[be[ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [All server access]
[sssd[be[ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x2000): Source hosts disabled, setting ALL
[sssd[be[ipa.mydomain.com]]] [hbac_eval_user_element] (0x1000): [13] groups for [AD_user] <----------------------------------------------
[sssd[be[ipa.mydomain.com]]] [hbac_eval_user_element] (0x1000): Added group [IDM_group1] for user [AD_user]
------ 12 groups more ------
[sssd[be[ipa.mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [Full ssh for admins]
[sssd[be[ipa.mydomain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success]
[sssd[be[ipa.mydomain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x1f72630], connected[1], ops[(nil)], ldap[0x1f75390]
[sssd[be[ipa.mydomain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
Thanks & Regards.
5 years, 6 months
Is the admins group special?
by Remco Kranenburg
Hi all,
We received a question from one of our auditors about who has the
permission to do certain actions in FreeIPA itself. This is managed by
the RBAC system: you can for example configure that certain groups are
allowed to manage certain parts of FreeIPA.
We currently only have two roles: normal users and admins. Normal users
have the default self-service permissions, and admins can do anything
within FreeIPA. However, for that last part we cannot figure out how
this is specified within FreeIPA. There is no RBAC role that gives
admins all permissions.
Is the admins group maybe special, in that it is hardcoded to be able
to change anything within FreeIPA?
--
Remco Kranenburg
5 years, 6 months