July 2018 - FreeIPA-users - Fedora mailing-lists

Client authentication against trusted AD broken
by Mike Conner 12 Jul '18

12 Jul '18

I've seen similar situations in other threads, but searching for a solution hasn't proven fruitful so far; please point me in the right direction! I've configured an ipa server with a trusted AD domain and both lookups and authentication are working on the server (I can getent and id AD users, and can ssh to the server as an AD user.) On the client side, however, only lookups are working. I can getent and id AD users, but can't authenticate as one. Here's a section of the sssd_cs.domain.dom.log from an authentication attempt. The obvious red flag is: (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain cs.domain.dom is Active (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain domain.dom is Inactive But I'm unsure how to troubleshoot. LOG: (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_dispatch] (0x4000): dbus conn: 0x55911dd26920 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.pamHandler on path /org/freedesktop/sssd/dataprovider (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_pam_handler] (0x0100): Got request with the following data (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): domain: domain.dom (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): user: username(a)domain.dom (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): service: sshd (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): tty: ssh (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): ruser: (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): rhost: IP.ADDR (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): priv: 1 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): cli_pid: 1096 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): logon name: not set (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #4]: New request. Flags [0000]. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain cs.domain.dom is Active (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain domain.dom is Inactive (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_auth_queue_send] (0x1000): Wait queue of user [username(a)domain.dom] is empty, running request [0x55911dd133f0] immediately. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain cs.domain.dom is Active (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain domain.dom is Inactive (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_setup] (0x4000): No mapping for: username(a)domain.dom (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd31600 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd316c0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd31600 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd316c0 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd31600 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd2da90 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd2db50 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd2da90 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd2db50 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd2da90 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [get_server_status] (0x1000): Status of server 'ipa.cs.domain.dom' is 'working' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa.cs.domain.dom' is 'working' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [get_server_status] (0x1000): Status of server 'ipa.cs.domain.dom' is 'working' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [be_resolve_server_process] (0x0200): Found address for server ipa.cs.domain.dom: [IP.ADDR] TTL 86400 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa.cs.domain.dom' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/pubconf/.krb5info_dummy_g504pM] (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/pubconf/.krb5info_dummy_g504pM] (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain domain.dom is Inactive (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_auth_resolve_done] (0x2000): Subdomain domain.dom is inactive, will proceed offline (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [1097] (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [child_handler_setup] (0x2000): Signal handler set up for pid [1097] (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [parse_krb5_child_response] (0x1000): child response [0][3][46]. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_WORKING. Called from: ../src/providers/krb5/krb5_auth.c: krb5_auth_done: 1093 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'ipa.cs.domain.dom' as 'working' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [set_server_common_status] (0x0100): Marking server 'ipa.cs.domain.dom' as 'working' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'ipa.cs.domain.dom' as 'working' (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_mod_ccname] (0x4000): Save ccname [FILE:/tmp/krb5cc_1326822197_QIfZhR] for user [username(a)domain.dom]. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd60a00 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd12a30 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd60a00 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd12a30 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd60a00 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sysdb_set_entry_attr] (0x0200): Entry [name=username(a)domain.dom,cn=users,cn=domain.dom,cn=sysdb] has set [ts_cache] attrs. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd12af0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd12bb0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd12af0 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd12bb0 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd12af0 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd29c80 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd29d40 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd29c80 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd29d40 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd29c80 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd57ee0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd29ea0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd57ee0 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd29ea0 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd57ee0 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sysdb_cache_auth] (0x4000): Offline credentials expiration is [0] days. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [check_failed_login_attempts] (0x4000): Failed login attempts [0], allowed failed login attempts [0], failed login delay [5]. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sysdb_cache_auth] (0x0100): Cached credentials not available. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0) (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_auth_cache_creds] (0x0020): Offline authentication failed (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [check_wait_queue] (0x1000): Wait queue for user [username(a)domain.dom] is empty. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_auth_queue_done] (0x1000): krb5_auth_queue request [0x55911dd133f0] done. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #4]: Request handler finished [0]: Success (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #4]: Receiving request data. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #4]: Request removed. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_pam_reply] (0x1000): DP Request [PAM Authenticate #4]: Sending result [6][domain.dom] (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [child_sig_handler] (0x1000): Waiting for child [1097]. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [child_sig_handler] (0x0100): child [1097] finished successfully. Thanks for any help!

4 9

Apache HTTPD Service Account Override
by Ryan Slominski 12 Jul '18

12 Jul '18

Hi IPA Users, I have a custom PHP script on the same Apache HTTPD server as used by IPA and the script attempts to make a request to the IPA Server's JSON endpoint using PHP's libcurl and a custom service principal. However, the request is coming across as the IPA HTTP service principal, not my custom principal (and therefore the permissions are wrong). If I run curl from the command line it works as expected. In fact, I believe this was working before and now isn't after I upgraded to IPA 4.5.4. How do I get PHP's libcurl to use my custom service principal instead of the HTTP service principal installed by IPA? This works: kinit myservice/ipaserver.example.com -k -t /etc/myservice.keytab /usr/bin/curl -v -H referer:https://ipaserver.example.com/ipa -H "Content-Type:application/json" -H "Accept:applicaton/json" --negotiate -u : --cacert /etc/ipa/ca.crt -d '{"method":"user_mod/1","params":[["testuser"],{"userpassword": "testpassword", "version": "2.228"}],"id":0}' -X POST https://ipaserver.example.com/ipa/json And as expected the verbose response includes the attribute: "principal": "myservice/ipaserver.example.com(a)EXAMPLE.COM" Now here is what the PHP script function for the same request looks like: <?php function web_request($body) { $krbcache = tmpfile(); $KRB5CCPATH = stream_get_meta_data($krbcache)['uri']; $IPAHOSTNAME = "ipaserver.example.com"; $ref = "https://" . $IPAHOSTNAME . "/ipa"; $url = "https://" . $IPAHOSTNAME . "/ipa/json"; putenv("KRB5CCNAME=FILE:/$KRB5CCPATH"); putenv("IPAHOSTNAME=$IPAHOSTNAME"); putenv("KRB5_CLIENT_KTNAME=/etc/myservice.keytab"); putenv("KRB5_KTNAME=/etc/myservice.keytab"); $command = "kinit myservice/ipaserver.example.com -k -t /etc/myservice.keytab"; shell_exec($command); $ch = curl_init($url); $headers = array("Expect:", "Content-Type:application/json", "Accept:application/json", "referer: " . $ref); curl_setopt($ch, CURLOPT_POSTFIELDS, $body); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_GSSNEGOTIATE); curl_setopt($ch, CURLOPT_CAINFO, "/etc/ipa/ca.crt"); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_USERNAME, ":"); #DEBUG OPTS curl_setopt($ch, CURLINFO_HEADER_OUT, true); curl_setopt($ch, CURLOPT_VERBOSE, true); $result = curl_exec($ch); #START DEBUG LOGGING $info = curl_getinfo($ch); foreach($info as $key => $value) { if(!is_array($value)) { error_log($key . ': ' . $value); } } error_log('Request Body: ' . $body); error_log('Response: ' . $result); # END DEBUG LOGGING if(curl_errno($ch)) { throw new Exception("Could not send CURL request: " . curl_error($ch)); } $status = curl_getinfo($ch, CURLINFO_HTTP_CODE); if($status !== 200) { throw new Exception("Unable to authenticate to server: HTTP Return code: " . $status); } curl_close($ch); fclose($krbcache); return $result; } ?> This fails with a permissions error and I assume it has something to do with the verbose output indicating the wrong credential cache was used: "principal": "HTTP/ipaserver.example.com(a)EXAMPLE.COM" Any tips? Thanks, Ryan

2 3

Only some AD users returned from lookups
by Mike Conner 12 Jul '18

12 Jul '18

I have an issue where i've established the AD trust and am able to lookup my own account and about 30 others, but all others fail. I've compared AD attributes across accounts and can't find anything that is notably different. I've seen messages about making sure that groups can resolve, but I don't think that's what's happening. I have a user account that only has one group membership and that group resolves, but the account still is not returned on a lookup. The only common thread I can find with the accounts that succeed is that they are older accounts - they were created a long time ago - more recently created accounts fail. Where can I look to see what might be happening?

2 6

Re: Freeipa-client-install - enrolls client/host then crashes
by Miller, Jim 12 Jul '18

12 Jul '18

Hello everyone, Did I not post my question correctly? Is there more information I should have posted? Should I file a bug report? From: Miller, Jim via FreeIPA-users [mailto:freeipa-users@lists.fedorahosted.org] Sent: Wednesday, July 11, 2018 4:49 PM To: freeipa-users(a)lists.fedorahosted.org Cc: Miller, Jim <jmiller(a)tkcholdings.com> Subject: [Freeipa-users] Freeipa-client-install - enrolls client/host then crashes Hello everyone, I'm trying to add a CentOS 7 64bit host to our FreeIPA domain. Client FreeIPA is 4.5.4-10 Server FreeIPA is 4.4.0 Client FreeIPA rpms: ipa-common-4.5.4-10.el7.centos.3.noarch python-ipaddress-1.0.16-2.el7.noarch python2-ipalib-4.5.4-10.el7.centos.3.noarch ipa-client-4.5.4-10.el7.centos.3.x86_64 ipa-client-common-4.5.4-10.el7.centos.3.noarch libipa_hbac-1.16.0-19.el7_5.5.x86_64 python-iniparse-0.4-9.el7.noarch sssd-ipa-1.16.0-19.el7_5.5.x86_64 python2-ipaclient-4.5.4-10.el7.centos.3.noarch python-libipa_hbac-1.16.0-19.el7_5.5.x86_64 The basic steps to reproduce are: 1. Populate /etc/krb5.conf for IPA.GENERIC.ZONE realm 2. kinit admin # for IPA.GENERIC.ZONE 3. ipa-client-install --mkhomedir --no-ntp --ssh-trust-dns --enable-dns-updates Here's where the errors start: Enrolled in IPA realm IPA.GENERIC.ZONE Created /etc/ipa/default.conf New SSSD config will be created Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm IPA.GENERIC.ZONE trying https://sl1mmgplidm0001.ipa.generic.zone/ipa/json Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information [root@sl1aosplsecweb2 ~]# less /var/log/ipaclient-install.log File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py", line 3628, in main install(self) File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py", line 2348, in install _install(options) File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py", line 2694, in _install api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 714, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 421, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 592, in load_plugins for package in self.packages: File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 948, in packages ipaclient.remote_plugins.get_package(self), File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line 126, in get_package plugins = schema.get_package(server_info, client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 537, in get_package schema = Schema(client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 385, in __init__ fingerprint, ttl = self._fetch(client, ignore_cache=read_failed) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 397, in _fetch client.connect(verbose=False) 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/ipalib/rpc.py", line 1034, in create_connection command([], {}) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1246, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1213, in __request verbose=self.__verbose >= 3, File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in single_request self.get_auth_info() File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in get_auth_info self._handle_exception(e, service=service) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 588, in _handle_exception raise errors.KerberosError(message=unicode(e)) 2018-07-11T21:39:19Z DEBUG The ipa-client-install command failed, exception: KerberosError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS 2018-07-11T21:39:19Z ERROR Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS 2018-07-11T21:39:19Z ERROR The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information If it would help I can attach the entire ipaclient-install.log file Thank you for your help --Jim

1 0

authentication when first master is down
by Petros Triantafyllidis 12 Jul '18

12 Jul '18

Hi all, I have a small setup with two masters and several clients at one location. I have noticed that when the first master goes down for maintenance or failure, the other server is unable to authenticate users. Is there a setting that needs to be made in order to achieve this as long as the first master is off? Shouldn't this be taken care of automatically? Thanks in advance, Petros

3 2

Freeipa-client-install - enrolls client/host then crashes
by Miller, Jim 11 Jul '18

11 Jul '18

Hello everyone, I'm trying to add a CentOS 7 64bit host to our FreeIPA domain. Client FreeIPA is 4.5.4-10 Server FreeIPA is 4.4.0 Client FreeIPA rpms: ipa-common-4.5.4-10.el7.centos.3.noarch python-ipaddress-1.0.16-2.el7.noarch python2-ipalib-4.5.4-10.el7.centos.3.noarch ipa-client-4.5.4-10.el7.centos.3.x86_64 ipa-client-common-4.5.4-10.el7.centos.3.noarch libipa_hbac-1.16.0-19.el7_5.5.x86_64 python-iniparse-0.4-9.el7.noarch sssd-ipa-1.16.0-19.el7_5.5.x86_64 python2-ipaclient-4.5.4-10.el7.centos.3.noarch python-libipa_hbac-1.16.0-19.el7_5.5.x86_64 The basic steps to reproduce are: 1. Populate /etc/krb5.conf for IPA.GENERIC.ZONE realm 2. kinit admin # for IPA.GENERIC.ZONE 3. ipa-client-install --mkhomedir --no-ntp --ssh-trust-dns --enable-dns-updates Here's where the errors start: Enrolled in IPA realm IPA.GENERIC.ZONE Created /etc/ipa/default.conf New SSSD config will be created Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm IPA.GENERIC.ZONE trying https://sl1mmgplidm0001.ipa.generic.zone/ipa/json Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information [root@sl1aosplsecweb2 ~]# less /var/log/ipaclient-install.log File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py", line 3628, in main install(self) File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py", line 2348, in install _install(options) File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py", line 2694, in _install api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 714, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 421, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 592, in load_plugins for package in self.packages: File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 948, in packages ipaclient.remote_plugins.get_package(self), File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line 126, in get_package plugins = schema.get_package(server_info, client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 537, in get_package schema = Schema(client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 385, in __init__ fingerprint, ttl = self._fetch(client, ignore_cache=read_failed) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 397, in _fetch client.connect(verbose=False) 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/ipalib/rpc.py", line 1034, in create_connection command([], {}) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1246, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1213, in __request verbose=self.__verbose >= 3, File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in single_request self.get_auth_info() File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in get_auth_info self._handle_exception(e, service=service) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 588, in _handle_exception raise errors.KerberosError(message=unicode(e)) 2018-07-11T21:39:19Z DEBUG The ipa-client-install command failed, exception: KerberosError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS 2018-07-11T21:39:19Z ERROR Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS 2018-07-11T21:39:19Z ERROR The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information If it would help I can attach the entire ipaclient-install.log file Thank you for your help --Jim

1 0

"No valid Negotiate header in server response" error when trying to install
by greg＠greg-gilbert.com 11 Jul '18

11 Jul '18

Hi all, I've been having an issue recently where my servers can't install FreeIPA due to this error: Cannot connect to the server due to generic error: error marshalling data for XML-RPC transport: message: need a <type 'unicode'>; got 'No valid Negotiate header in server response' (a <type 'str'>) Installation failed. Rolling back changes. Unenrolling client from IPA server Restarting FreeIPA (ipactl stop, ipactl start) solves the solution, but not permanently. I captured the FreeIPA logs during that event, which you can see here: https://pastebin.com/WL7Cg90V Any ideas what's going wrong? One solution would be to have a cron restart FreeIPA nightly, but that's not ideal. Thanks, Greg

2 4

How to use HBAC rules on services where is used Ipsion
by SOLER SANGUESA Miguel 11 Jul '18

11 Jul '18

Hello, RHEL 7.5 with IPA server 4.5.4 RHEL 7.5 with IPA client 4.5.4 for installing Ipsilon from RHEL repositories (v1.0.0) and added manually patch: https://pagure.io/ipsilon/pull-request/44#request_diff I have configured Jira with the plugin for SAML2 (SAML Single Sign On (SSO) Jira, SAML/SSO<https://marketplace.atlassian.com/apps/1212130/saml-single-sign-on-sso-jira…>) and it works fine, when I try to login on Jira I'm redirected to Ipsilon server and when I put user/pass (using IPA user) I log in. My problem is that I don't know how to configure which users can log in on the service. Right now all users able to login on the Ipsilon server via "any service" can login. On Jira side I can create the users manually and configure that just existing users can log in, but I would prefer not to manage users on the service provider side. Also I want to add more services to Ipsilon, so not all users allowed to log in on Ipsilon should log in on all services. If I can create a pam service for any of the services managed by ipsilon, it would be perfect, as I could create HBAC rules for any service and authorization would be manage just on IPA. Can anyone explain or give some documentation about this? Thanks & Regards. ______________________________

3 6

admin account getting locked
by skrawczenko＠gmail.com 11 Jul '18

11 Jul '18

Somehow, the admin account is permanently locked just a simple reproduction sh-4.2# kinit admin kinit: Client's credentials have been revoked while getting initial credentials sh-4.2# kdestroy -A sh-4.2# kinit <another admin> Password for <another admin>@bla-bla sh-4.2# ipa user-unlock admin ------------------------ Unlocked account "admin" ------------------------ sh-4.2# kdestroy -A sh-4.2# kinit admin Password for admin@bla-bla sh-4.2# kdestroy -A sh-4.2# kinit admin kinit: Client's credentials have been revoked while getting initial credentials And this is apparently related to the previous issue which still persists https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… Nothing suspicious in the logs or i'm looking at wrong logs. Any ideas please assist, thanks.

4 7

Problem with promoting replica: missing key for auditSigningCert on CA server
by Andy Stubbs 11 Jul '18

11 Jul '18

Hi So, I have what I think seems to be a slightly odd problem. And I think I've worked out what the solution might be - but not the root cause. In any case, I wanted to run it by you all and see whether you agree or have any insight into it. The background running 6 directory servers 4.5.0-21 on CentOS 7.4.1708, 3 of which have the CA role. I've been running the directory blissfully uneventfully for 7ish months now. We have experimented a little bit with the CA features, but nothing that can't be done trivially with the web interface (on reflection I'm sure it probably is trivial to revoke your primary certificate authority with the web interface, but you know what I mean). The problem In the past few days I've had the occasion to try to create a new replica but on each attempt, the process fails around this time: [4/4]: configuring ipa-custodia to start on boot Done configuring ipa-custodia. The ipa-replica-install command failed, exception: HTTPError: 404 Client Error: Not Found 404 Client Error: Not Found The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Now, I've learned a fair amount over the past few days digging into this, like what ipa-custodia is, and how to poke it. It seems that at this point, the process is still actually actively doing things - it appears to be generating some kind of NSS certificate/key store. And that process is failing, because apparently it can't find the key for the entry "auditSigningCert cert-pki-ca" - specifically in custodiainstance.__get_keys the call to cli.fetch_key is failing for this nickname (but no others). So, more digging, and I find that yes indeed, the private key appears to be missing from the cert database on one of the directory servers (specifically the "first" directory server). I haven't quite joined the dots on how custodia is working here, but using the following command: sudo certutil -L -d /etc/pki/pki-tomcat/alias I can determine that on the first directory server, the trust attributes for this cert are ",,P" whereas on the other two CA directory servers, the trust attributes are "u,u,uP", and that indeed the key is missing from the first directory server in this database. I also note that the cert databases seem to be divergent in other ways between the CA servers. Which I find interesting. But anyway, so my next action is to copy the cert databases to another machine and to try to import the cert/key from a "good" CA db to the "bad" CA db using pk12util. This gives me a segmentation fault. So, I try with a new DB. I export all the cert/key pairs from the "bad" CA individually and import them into a new DB, replicating the trust attributes. So far so good. I also export the missing cert/key from a "good" CA and import that into the same new DB. Also apparently good. The solution? So, at this point, I feel relatively confident that I have constructed a good DB and I should be able to perform some surgery to remove the old "bad" DB and replace it with this "good" DB. My questions are: 1. Does this approach seem reasonable or am I oversimplifying? 2. If this is a reasonable approach: what's my best method for performing the surgery? ipactl stop, move bad db directory out of way, move "good" db in, don't forget the selinux stuff, then ipactl start again? 3. How could this even happen in the first place? Is it a known issue? 4. Shouldn't the CA databases basically all look the same between servers created at the same time? Why might they diverge? 5. Do you have any other comments or questions which you feel might be pertinent? Thanks in advance for any input or insights shared. Best Regards Andy -- <https://www.treatwell.com/> Andrew Stubbs, PhD Head of Technical Operations treatwell.co.uk

1 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users July 2018