[Freeipa-users] section 2.3.6. Installing Without a CA - then how to update expired certificates in LDAP?
I discussed this problem once before and got partial answers but I would like to finally resolve it. Scenario: 1. Install IPA without a CA, according to section 2.3.6 as of now in latest RHEL7 Linux Domain Identity, Authentication and Policy Guide. 2. Install a client and note certificates it receives from IPA LDAP. 3. Near expiration term obtain a new set of certificates (server and intermediate), note that intermediate certificate common name has changed. 4. run "ipa-server-certinstall -d -w key cert" to update all certificates. command asks for directory manager password, I suppose it should update its contents but 5. Install another client and observe that it receives original certificates and no ipa command works. 6. ipa-certupdate, when run, pulls original set from LDAP as if nothing was updated. Workaround is to manually install new intermediate certificate on all systems /etc/ipa/nssdb by certutil -d /etc/ipa/nssdb/ -A -n "StartCom Class 1 DV Server CA - StartCom Ltd." -t C,, -i /tmp/1_Intermediate.crt In LDAP under cn=certificates,cn=ipa,cn=etc,dc=example,dc=org I still see previous version of intermediate certificate with a different common name: StartCom Class 1 Primary Intermediate Server CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL Please help me replace it by any means. Best Regards, Josh. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] updating certificates
Hi Flo, looks like ipa-certupdate requires /etc/ipa/nssdb to be already updated so it seems useless if existing certificates expired. I am experimenting on another server with expired certificates. Was able to successfully update /etc/httpd/alias and /etc/dirsrv/slapd-INSTANCE but ipa command still returns with SEC_ERROR_UNTRUSTED_ISSUER even though I updated /etc/ipa/nssdb with new intermediate certificate from startcom. Am I missing something else here? Josh. On 08/10/2016 04:22 AM, Florence Blanc-Renaud wrote: Hi Josh, depending on your IPA version, you may consider using ipa-server-certinstall and ipa-certupdate. ipa-server-certinstall can be used to install a new certificate for Apache/LDAP servers, and ipa-certupdate to update the NSS DBs with the CA certificates found in the LDAP server. Flo. On 08/09/2016 05:48 PM, Josh wrote: Rob, One must also update /etc/ipa/nssdb the same way, otherwise ipa cli tool gets SEC_ERROR_UNTRUSTED_ISSUER ! It would be nice to have an IPA tool to update all certificates in all required places. Also, why would I need to add CA that already in system ca-trust to the private IPA nssdb? Josh. On 06/28/2016 10:50 AM, Rob Crittenden wrote: j...@use.startmail.com wrote: Greetings, About a year ago I installed my freeipa server with certificates from startssl using command line options --dirsrv-cert-file --http-cert-file etc. The certificate is about to expire, what is the proper way to update it in all places? It depends on whether you kept the original CSR or not. If you kept the original CSR and are just renewing the certificate(s) then when you get the new one, use certutil to add the updated cert to the appropriate NSS database like: # certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i /path/to/new.crt If you need to generate a new CSR then you can use ipa-server-certinstall to install the updated key and crt files. In either case probably worth backing up /etc/httpd/alias/*.db and /etc/dirsrv/slapd-INSTANCE/*.db. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] updating certificates
Hi Rob, I'd like to really clarify renew certificate process. I can successfully update certificates in /etc/dirsrv/slapd-domain and /etc/httpd/alias but any new ipa client gets expired certificate still present someplace in LDAP. I was trying to use ipa-server-certinstall, described in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/third-party-certs-http-ldap.html but document does not cover the case where intermediate certificate is required. Josh. On 07/11/2016 10:10 AM, Rob Crittenden wrote: j...@use.startmail.com wrote: On Tuesday, June 28, 2016 10:50 AM, Rob Crittenden wrote: j...@use.startmail.com wrote: Greetings, About a year ago I installed my freeipa server with certificates from startssl using command line options --dirsrv-cert-file --http-cert-file etc. The certificate is about to expire, what is the proper way to update it in all places? It depends on whether you kept the original CSR or not. If you kept the original CSR and are just renewing the certificate(s) then when you get the new one, use certutil to add the updated cert to the appropriate NSS database like: # certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i /path/to/new.crt Rob, Thank you, that worked just fine, except that I had to update an intermediate certificate as well. Two questions, please: 1. I noticed a strange discrepancy in behavior between /etc/httpd/alias and /etc/dirsrv/slapd-domain. In both places original intermediate certificate is listed with empty ",," trust attributes so I initially added new intermediate certificate with empty attributes as well. certutils -V showed valid certificate in /etc/httpd/alias and not trusted in /etc/dirsrv/slapd-domain so I had to modify intermediate certificate with -t "C,," Hmm, not sure. Did the CA chain change in between the issuance of the two certs? Adding a new certificate shouldn't affect the trust of any other certs so I'm not sure what happened. It could be that those subordinate CAs were loaded the first time incorrectly but weren't used so it wasn't noticed, I'm not really sure. 2. Just out of curiosity I wanted to list private keys and is prompted for a password: # certutil -K -d /etc/httpd/alias/ certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": Which one of the many provided by a user passwords is used by ipa-server-install command during NSS database initialization? In each NSS directory there is a pwdfile.txt which contains the PIN for the internal token. You can add -f /etc/httpd/alias/pwdfile.txt to your command to list the private keys. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.
On (23/12/16 10:29), Jakub Hrozek wrote: >On Thu, Dec 22, 2016 at 08:38:38PM -0500, Dan Kemp wrote: >> Hello, >> >> I recently ran an upgrade of my freeipa servers, and most of the clients to >> 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install >> and server update, I can no longer log in to update clients via ssh. Login >> to non-update clients works as before. >> >> The SSH connections fail with: >> >> Connection closed by UNKNOWN >> >> I ran sssd with debugging on a failing 4.4.0 client and got this error log: >> >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 2) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 1) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 0) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] >> [selinux_child_create_buffer] (0x4000): buffer size: 45 >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >> (0x2000): Setting up signal handler up for pid [437] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >> (0x2000): Signal handler set up for pid [437] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >> (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], >> ldap[0x560c04c32d60] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >> (0x2000): Trace: end of ldap_result list >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] >> (0x0400): All data has been sent! >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): >> selinux_child started. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): >> Running with effective IDs: [0][0]. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): >> Running with real IDs [0][0]. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): >> context initialized >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] >> (0x2000): seuser length: 12 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] >> (0x2000): seuser: unconfined_u >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] >> (0x2000): mls_range length: 14 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] >> (0x2000): mls_range: s0-s0:c0.c1023 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] >> (0x2000): username length: 7 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] >> (0x2000): username: ipauser >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): >> performing selinux operations >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] >> (0x0020): SELinux policy not managed >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser] >> (0x0020): Cannot create SELinux handle >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 >> [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: >> unknown >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] >> (0x0020): SELinux policy not managed >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser] >> (0x0020): Cannot init SELinux management >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): >> Cannot set SELinux login context. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): >> selinux_child failed! >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] >> (0x0400): EOF received, client finished >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] >> (0x0020): selinux_child_parse_response failed: [22][Invalid argument] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): >> DP Request [PAM SELinux #3]: Request handler finished [0]: Success >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] >> (0x0400): DP Request [PAM SELinux #3]: Receiving request data. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >> (0x0400): DP Request [PAM SELinux #3]: Request removed. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >> (0x0400): Number of active DP request: 0 >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] >> (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >> (0x1000): Waiting for child [437]. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >> (0x0020): child [437] failed with status [1]. >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): >> 0x55f4be11f4c0 >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispa
Re: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?
Really appreciate the high-level of insight and support on this list. Very refreshing! Alexander Bokovoy wrote: Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on the replica? krb5_child.log is totally empty (strange) as I thought I had debug_level = 10 set everywhere ldap_child.log is posted at this URL due to length: http://chrisdag.me/ldap_child.log.sanitized.txt There seem to be something weird with networking stack, because at 15:43:13 the next attempt to connect gets 'connection refused'. May be 389-ds is just warming up and there is not enough CPU or I/O to handle the load? So, sssd on the replica is able to retrieve information from the replica's LDAP server. It also is able to retrieve the trust topology information and retrieve the trusted domain objects to use against the forest root domains your deployment trusts. But at the point when it tries to contact global catalog and domain controllers from the trusted domains, it cannot access them, so it considers them offline. Can you show us your /etc/krb5.conf on this replica, content of files in /var/lib/sss/pubconf/krb5.include.d subdirectory which get included into /etc/krb5.conf, and the logs I asked above? Here is sanitized krb5.conf from the replica. The CAPATH information was provided by someone on this list to resolve a problem with the CAPATHs being wrong by default on v4.2 with our complex AD environment. We've since made an Ansible playbook to update the krb5.conf file on our client machines. We comment out the include path again based on our v4.2 issues howeve includedir /etc/krb5.conf.d/ ## Disabled due to SSSD Bug related to CA paths ## across different AD trusts # includedir /var/lib/sss/pubconf/krb5.include.d/ ## This is the manual COMPANY fix: [capaths] COMPANYAWS.ORG = { COMPANYIDM.ORG = COMPANYAWS.ORG } COMPANYIDM.ORG = { COMPANYAWS.ORG = COMPANYAWS.ORG COMPANY.ORG = COMPANY.ORG EAME.COMPANY.ORG = COMPANY.ORG APAC.COMPANY.ORG = COMPANY.ORG LATAM.COMPANY.ORG = COMPANY.ORG NAFTA.COMPANY.ORG = COMPANY.ORG } COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } EAME.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } APAC.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } LATAM.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } NAFTA.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = COMPANYIDM.ORG dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} canonicalize = true [realms] COMPANYIDM.ORG = { kdc = usaeilidmp002.COMPANYidm.org:88 master_kdc = usaeilidmp002.COMPANYidm.org:88 admin_server = usaeilidmp002.COMPANYidm.org:749 default_domain = COMPANYidm.org pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .COMPANYidm.org = COMPANYIDM.ORG COMPANYidm.org = COMPANYIDM.ORG usaeilidmp002.COMPANYidm.org = COMPANYIDM.ORG [dbmodules] COMPANYIDM.ORG = { db_library = ipadb.so } ## Also from the include path we had previously commented out [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so } Can you make sure that the replica is actually able to reach AD DCs for the trusted domains (ports tcp/3268, tcp/389, tcp/88, udp/88, udp/53 at least)? I'm going to see if I can come up with a new verification method. My normal way of "proving" connectivity in this AWS environment is to use the VPC flow logs to search for REJECT alerts between the NIC on this IPA server and the remote AD domain controller. This was very effective in proving on our master IPA that something was blocking UDP:88 to a few remote controllers. Sadly I can't find any REJECT messages for this replica server so I've been assuming connectivity was totally fine. Will try to test via other methods. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?
Oddly enough the keytab location on the replica is sort of empty ... ls -al /var/lib/sss/keytabs/ total 4 drwx--. 2 sssd sssd 32 Dec 23 13:58 . drwxr-xr-x. 9 root root 94 Dec 19 17:05 .. -rw--- 1 sssd sssd 219 Dec 20 20:40 company.org.keytab Jakub Hrozek wrote: In addition, can you also see if the keytab with the trust principal is there? Probably it would be /var/lib/sss/keytabs/shanetest.org. At15:43:11, sssd tried to fetch the keytab for this trust: (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for shanetest.org (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_send] (0x0400): Retrieving keytab forcompanyidm$@SHANETEST.ORG from usaeilidmp002.companyidm.org into /var/lib/sss/keytabs/shanetest.org.keytabRw7Iai using ccache /var/lib/sss/db/ccache_companyidm.ORG But fails: SASL Bind failed Can't contact LDAP server (-1) ! Failed to bind to server! Failed to get keytab (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_done] (0x0040): ipa-getkeytab failed with status [2304] (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_recv] (0x2000): ipa-getkeytab status 2304 (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_server_trust_1way_kt_done] (0x0080): ipa_getkeytab_recv failed: 1432158265 What I don't see in the logs, though is that if we try and re-fetch the keytab after going online (we should, though). -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Still trying to implement password expiration warnings
Hello. Earlier this year I tried to re-implement a "password expiration warning" email when using IPA 4.x. I hit a wall and ended up deciding to look at this later. Now is later :) The plan is to use ldapsearch to check for krbLastPwdChange and compare it to krbPasswordExpiration, but these attributes seem to be hidden unless one is authenticating (through Kerberos?). This is with RHEL 7 and IPA 4.2.0. I have done: # ipa service-add PWDREMIND/script.host.fqdn # ipa-getkeytab -s script.host.fqdn -k /etc/gssproxy/pwdremind.keytab -p PWDREMIND/script.host.fqdn ...and I have a file /etc/gssproxy/pwdremind.keytab I added a section to /etc/gssproxy/gssproxy.conf : [service/PWDREMIND] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/pwdremind.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U cred_usage = initiate euid = 0 debug = true In my "pwdcheck.sh" script I have the following: #!/bin/bash export GSS_USE_PROXY="yes" ldapsearch -z 500 -Y GSSAPI -h ipa.host.fqdn -b cn=users,cn=accounts,dc=example,dc=net "(&(!(nsAccountLock=TRUE))(krbLastPwdChange<=$(date +%Y%m%d --date='-1 week')00Z)(krbPasswordExpiration<=$(date +%Y%m%d --date='+1 week')00Z))" uid |grep ^uid|cut -d: -f2 |while read uid do ldapsearch -z 500 -Y GSSAPI -h ipa.host.fqdn -b cn=users,cn=accounts,dc=example,dc=net "uid=${uid}" mail|grep ^mail|cut -d: -f2 | while read mail do echo "password expires in less than a week: username=$uid mail=$mail" done done Checking the journalctl for gssproxy I get: Dec 23 11:36:35 script.host.fqdn gssproxy[26977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Dec 23 11:36:35 script.host.fqdn gssproxy[26976]: gssproxy[26977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Does anyone see where things are going wrong here or have some suggestions on what I should try? Regards Eivind Olsen -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.
On 23/12/2016 10:31, Alexander Bokovoy wrote: ipa-ca used to be a CNAME, you cannot handle CNAME via /etc/hosts. However, multiple replicas cannot me specified via CNAME, so we had to fix https://fedorahosted.org/freeipa/ticket/3547. Absolutely - I have no problem with ipa-ca being real A record(s) pointing to the server itself. All I'm saying is that at installation time, it already knew the IP address of the server - by local hostname resolution, and because ipa-server-install asks you to list the IP addresses of the server explicitly. > The ipa-ca A record is now handled as part of the server upgrade which > also should be run at the very end of a normal install. Are you are supposed to manually run "ipa-server-upgrade" even after a clean install? I've just tested that, and yes, one of the steps is: ... [Add missing CA DNS records] Updating DNS system records << pauses here >> unable to resolve host name ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete ... So you're right: that would have fixed it *if* I'd created the foo.example.com zone first, and added the host to it, which in real life I would have done (since other hosts must be able to resolve the IPA server's hostname) I already opened https://fedorahosted.org/freeipa/ticket/6579 which suggested using local resolution, e.g. via gethostent(). But feel free to close it if you don't think this is needed. Regards, Brian. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.
On pe, 23 joulu 2016, Brian Candler wrote: On 23/12/2016 09:47, Brian Candler wrote: /etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp However the installation process didn't actually create this DNS entry, so the ipa-ca hostname is not resolvable. Aside: I think this was because ipatest.foo.example.com was only in /etc/hosts, not in the DNS. Installation message: ipa : ERRORunable to resolve host name ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete But if it had used gethostent() or similar, it would have worked: # getent hosts ipatest.foo.example.com 100.64.2.3 ipatest.foo.example.com ipatest ipa-ca used to be a CNAME, you cannot handle CNAME via /etc/hosts. However, multiple replicas cannot me specified via CNAME, so we had to fix https://fedorahosted.org/freeipa/ticket/3547. The ipa-ca A record is now handled as part of the server upgrade which also should be run at the very end of a normal install. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.
On 23/12/2016 09:47, Brian Candler wrote: /etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp However the installation process didn't actually create this DNS entry, so the ipa-ca hostname is not resolvable. Aside: I think this was because ipatest.foo.example.com was only in /etc/hosts, not in the DNS. Installation message: ipa : ERRORunable to resolve host name ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete But if it had used gethostent() or similar, it would have worked: # getent hosts ipatest.foo.example.com 100.64.2.3 ipatest.foo.example.com ipatest Regards, Brian. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.
On 22/12/2016 20:53, Martin Basti wrote: (1) This introduces a concept of an "IPA Primary Domain". Is that just the DNS domain which holds the SRV records which point to the realm's kerberos/ldap servers, or does it have any other function? In other words, what other effects would there be from choosing a different IP Primary Domain? it holds SRV records, A/ records for CA LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com) No, I don't believe that's true: the LDAP tree is constructed from the *realm* not the *domain*. I just checked this by creating a Centos7 lxd container with hostname "ipa.foo.example.com", running the following command: # ipa-server-install --domain bar.example.com --realm QUX.EXAMPLE.COM --setup-dns -p Abcd1234 -a Defg5678 and accepting defaults for everything else. What I get is: *** an LDAP tree rooted at dc=qux,dc=example,dc=com => this proves the LDAP tree is constructed from the --realm, not the --domain. *** the DNS zone "bar.example.com" (in addition to the reverse zone) The bar.example.com contains both types of DNS mapping: hostname to realm and realm to servers. (1) _kerberos TXT "QUX.EXAMPLE.COM" i.e. "hosts with hostnames under domain bar.example.com belong to realm QUX.EXAMPLE.COM" (2) _kerberos._tcp SRV 0 100 88 ipatest.foo.example.com.# plus _kerberos._ldap etc => this shows the SRV records are put under the --domain *** in krb5.conf a default realm of QUX.EXAMPLE.COM, and the following realm to server mapping: [realms] QUX.EXAMPLE.COM = { kdc = ipatest.foo.example.com:88 master_kdc = ipatest.foo.example.com:88 admin_server = ipatest.foo.example.com:749 default_domain = bar.example.com pkinit_anchors = FILE:/etc/ipa/ca.crt } Aha: there is "default_domain" in there! It's a property of the realm! Checking the MIT kerberos documentation: http://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html "default_domain This tag specifies the domain used to expand hostnames when translating Kerberos 4 service principals to Kerberos 5 principals (for example, when converting rcmd.hostname to host/hostname.domain)." So it seems that's only a legacy setting for dealing with kerberos 4 :-( *** /etc/sssd/sssd.conf [domain/bar.example.com] krb5_realm = QUX.EXAMPLE.COM ipa_domain = bar.example.com [sssd] domains = bar.example.com But in sssd, "A domain is a database containing user information" - from sssd.conf(5). So really it's just a label for a group of settings, nothing to do with a DNS domain. *** CA grepping through /etc I see some other settings based on the domain, in particular the CA hostname is here: /etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp However the installation process didn't actually create this DNS entry, so the ipa-ca hostname is not resolvable. Since it has the bar.example.com master zone, maybe it should add this record? *** During the installation I get a reasonable warning: WARNING: Realm name does not match the domain name. You will not be able to estabilish trusts with Active Directory unless the realm name of the IPA server matches its domain name. But I think this also highlights confusion between "the IPA domain" and "the server's domain name". It's clear is that the *realm* is something that's common to all the IPA servers. However it's also clear that each IPA server's *hostname* can be in a different *domain*, e.g. they could be srv1.bar.com srv2.baz.com But "the IPA primary domain" (where the SRV records are stored) is an attribute of the realm collectively, not of the individual servers. So it might be clearer if it said: WARNING: Realm name does not match the domain name. You will not be able to establish trusts with Active Directory unless the IPA realm matches the IPA primary domain. Then use bar.example.com, IPA servers can have names outside the IPA domain name space. Different people wants different things, that's why the option is there. Indeed, but the "--domain" option to ipa-server-install appears to be orthogonal to the domain name of the IPA servers themselves. This is a primary source of confusion I think. Regards, Brian. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?
On Thu, Dec 22, 2016 at 11:34:01PM +0200, Alexander Bokovoy wrote: > On to, 22 joulu 2016, Chris Dagdigian wrote: > > Hi folks, > > > > Summary: Replica w/ Trust agents can't resolve AD users. Not sure which > > debug_level=log error I should focus on. Would appreciate extra eyeballs > > on this .. > > > > Have a brand new replica (v4.4) running and after installing the AD > > trust agents I still can't recognize users who exist in the trusted AD > > domains. > > > > Running at debug_level=10 for logging as usual however deleting the logs > > and doing a fresh reboot followed by trying to resolve a users still > > make 4000+ log entries so rather than include it here I've posted a > > sanitized sssd_domain.log file here: > > > > http://chrisdag.me/sssd_companyidm.org.log.txt > > > > There are two sets of messages in that massive log file that concern me > > but I don't know enough yet to figure out which one to focus on. > > > > The first set of messages show what appears to be a fatal error in > > connecting to the local ldap:// server on the replica. > > > > However - > > - dirsirv logs look fine > > - the various ldapsearch commands in the Free-IPA troublehooting page > > work to query both the replica and the remote master > > - 'ipactl status' shows directory services running > > - no firewall blocking and AWS VPC flowLogs show no REJECT traffic > > whatsoever for the NIC on the replica > Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on > the replica? > > There seem to be something weird with networking stack, because at > 15:43:13 the next attempt to connect gets 'connection refused'. May be > 389-ds is just warming up and there is not enough CPU or I/O to handle > the load? > > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [be_resolve_server_process] (0x0200): Found address for server > usaeilidmp002.companyidm.org: [10.127.66.11] TTL 7200 > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the > connection. > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for > connecting > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_connect_done] (0x0020): connect failed [111][Connection refused]. > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request > failed: [111]: Connection refused. > > this is definitely is different from the result of two seconds before: > > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [21] for the > connection. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_connect_send] (0x0020): connect failed [101][Network is > unreachable]. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for > connecting > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request > failed: [101]: Network is unreachable. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_state_destructor] (0x0400): closing socket [21] (Thu Dec > 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init request > failed: [101]: Network is unreachable. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: > [101]: Network is unreachable. > > Later, in a minute it seems to respond just well: > > > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the > connection. > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for > connecting > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to > [ldap://usaeilidmp002.companyidm.org:389/??base] with fd [27]. > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_get_rootdse_send] (0x4000): Getting rootdse > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_print_server] (0x2000): Searching 10.127.66.11:389 > ... > > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] > (0x2000): No sub-attributes for [supportedSASLMechanisms] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] > (0x2000): No sub-attributes for [defaultNamingContext] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] > (0x2000): No sub-attributes for [lastUSN] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_process_result] (0x2000): Trace: sh[0x7f4f63ace530], connected[1], > ops[0x7f4f63b283d0], ldap[0x7f4f63b28720]
Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.
On to, 22 joulu 2016, Dan Kemp wrote: Hello, I recently ran an upgrade of my freeipa servers, and most of the clients to 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install and server update, I can no longer log in to update clients via ssh. Login to non-update clients works as before. The SSH connections fail with: Connection closed by UNKNOWN I ran sssd with debugging on a failing 4.4.0 client and got this error log: (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_create_buffer] (0x4000): buffer size: 45 (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [437] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [437] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], ldap[0x560c04c32d60] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): selinux_child started. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): Running with effective IDs: [0][0]. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): Running with real IDs [0][0]. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): context initialized (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): seuser length: 12 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): seuser: unconfined_u (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): mls_range length: 14 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): username length: 7 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): username: ipauser (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): performing selinux operations (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] (0x0020): SELinux policy not managed (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser] (0x0020): Cannot create SELinux handle (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: unknown (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] (0x0020): SELinux policy not managed (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser] (0x0020): Cannot init SELinux management (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): Cannot set SELinux login context. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): selinux_child failed! (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] (0x0020): selinux_child_parse_response failed: [22][Invalid argument] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): DP Request [PAM SELinux #3]: Request handler finished [0]: Success (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] (0x0400): DP Request [PAM SELinux #3]: Receiving request data. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] (0x0400): DP Request [PAM SELinux #3]: Request removed. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] (0x1000): Waiting for child [437]. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] (0x0020): child [437] failed with status [1]. (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x55f4be11f4c0 (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x55f4be1191b0 (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][domain.local] (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: S
Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.
On Thu, Dec 22, 2016 at 08:38:38PM -0500, Dan Kemp wrote: > Hello, > > I recently ran an upgrade of my freeipa servers, and most of the clients to > 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install > and server update, I can no longer log in to update clients via ssh. Login > to non-update clients works as before. > > The SSH connections fail with: > > Connection closed by UNKNOWN > > I ran sssd with debugging on a failing 4.4.0 client and got this error log: > > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 2) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 1) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 0) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] > [selinux_child_create_buffer] (0x4000): buffer size: 45 > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] > (0x2000): Setting up signal handler up for pid [437] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] > (0x2000): Signal handler set up for pid [437] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] > (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], > ldap[0x560c04c32d60] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] > (0x2000): Trace: end of ldap_result list > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] > (0x0400): All data has been sent! > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): > selinux_child started. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): > Running with effective IDs: [0][0]. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): > Running with real IDs [0][0]. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): > context initialized > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] > (0x2000): seuser length: 12 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] > (0x2000): seuser: unconfined_u > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] > (0x2000): mls_range length: 14 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] > (0x2000): mls_range: s0-s0:c0.c1023 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] > (0x2000): username length: 7 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] > (0x2000): username: ipauser > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): > performing selinux operations > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] > (0x0020): SELinux policy not managed > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser] > (0x0020): Cannot create SELinux handle > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 > [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: > unknown > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] > (0x0020): SELinux policy not managed > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser] > (0x0020): Cannot init SELinux management > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): > Cannot set SELinux login context. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): > selinux_child failed! > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] > (0x0400): EOF received, client finished > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] > (0x0020): selinux_child_parse_response failed: [22][Invalid argument] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): > DP Request [PAM SELinux #3]: Request handler finished [0]: Success > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] > (0x0400): DP Request [PAM SELinux #3]: Receiving request data. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] > (0x0400): DP Request [PAM SELinux #3]: Request removed. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] > (0x0400): Number of active DP request: 0 > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] > (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] > (0x1000): Waiting for child [437]. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] > (0x0020): child [437] failed with status [1]. > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x55f4be11f4c0 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x55f4be1191b0 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Wed
[Freeipa-users] Upgrade to 4.4.0 Breaks login.
Hello, I recently ran an upgrade of my freeipa servers, and most of the clients to 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install and server update, I can no longer log in to update clients via ssh. Login to non-update clients works as before. The SSH connections fail with: Connection closed by UNKNOWN I ran sssd with debugging on a failing 4.4.0 client and got this error log: (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_create_buffer] (0x4000): buffer size: 45 (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [437] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [437] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], ldap[0x560c04c32d60] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): selinux_child started. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): Running with effective IDs: [0][0]. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000): Running with real IDs [0][0]. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): context initialized (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): seuser length: 12 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): seuser: unconfined_u (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): mls_range length: 14 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): username length: 7 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer] (0x2000): username: ipauser (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400): performing selinux operations (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] (0x0020): SELinux policy not managed (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser] (0x0020): Cannot create SELinux handle (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: unknown (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init] (0x0020): SELinux policy not managed (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser] (0x0020): Cannot init SELinux management (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): Cannot set SELinux login context. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020): selinux_child failed! (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] (0x0020): selinux_child_parse_response failed: [22][Invalid argument] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): DP Request [PAM SELinux #3]: Request handler finished [0]: Success (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] (0x0400): DP Request [PAM SELinux #3]: Receiving request data. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] (0x0400): DP Request [PAM SELinux #3]: Request removed. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] (0x1000): Waiting for child [437]. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] (0x0020): child [437] failed with status [1]. (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x55f4be11f4c0 (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x55f4be1191b0 (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][domain.local] (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Wed Dec 20 20:38:13 2016)