[Freeipa-users] section 2.3.6. Installing Without a CA - then how to update expired certificates in LDAP?

[Josh]

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

[Josh]

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

[Josh]

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.

[Lukas Slebodnik]

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]] 

Re: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

[Chris Dagdigian]

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?

[Chris Dagdigian]

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

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

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.

[Alexander Bokovoy]

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.

[Brian Candler]

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.

[Brian Candler]

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?

[Jakub Hrozek]

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.

[Alexander Bokovoy]

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]: 

Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.

[Jakub Hrozek]

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.

[Dan Kemp]

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)