On Fri, Apr 08, 2016 at 12:00:59PM +1000, Kosseck, Adam MR wrote:
UNOFFICIAL
Hi Jakub,
Problem is reliably replicatable on another server, I've attached logs at a zip file
due to the size of the raw text logs (~7MB).
Sorry for the late reply, I had some urgent packaging work on my plate
lately..
OK, I see some failures, but I'm not sure if it's "expected" failures
(ie a mistyped password) or some unexpected one.
In the logs, one is at this point in the domain log:
(Fri Apr 8 09:36:35 2016) [sssd[be[domain.subdomain.com]]] [check_wait_queue] (0x1000):
Wait queue for user [Firstname.Lastname] is empty.
(Fri Apr 8 09:36:35 2016) [sssd[be[domain.subdomain.com]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 17, <NULL>) [Success]
(Fri Apr 8 09:36:35 2016) [sssd[be[domain.subdomain.com]]] [be_pam_handler_callback]
(0x0100): Sending result [
17][domain.subdomain.com]
(Fri Apr 8 09:36:35 2016) [sssd[be[domain.subdomain.com]]] [be_pam_handler_callback]
(0x0100): Sent result [
17][domain.subdomain.com]
The corresponding krb5_child.log entry is:
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [get_and_save_tgt] (0x0400):
Attempting kinit for realm [
domain.subdomain.com]
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.572481: Getting initial credentials for
Firstname.Lastname\@domain.subdomain.com(a)domain.subdomain.com
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.572640: Sending request (268 bytes) to
domain.subdomain.com
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.577302: Sending initial UDP request to dgram 10.221.74.11:88
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.583749: Received answer from dgram 10.221.74.11:88
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.586942: Response was from master KDC
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.587015: Received error from KDC: -1765328359/Additional
pre-authentication required
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.587091: Processing preauth types: 16, 15, 19, 2
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.587148: Selected etype info: etype aes256-cts, salt
"domain.subdomain.comFirstname.Lastname", params
""
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.595249: AS key obtained for encrypted timestamp: aes256-cts/3F75
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.595342: Encrypted timestamp (for 1460072195.595307): plain
301AA011180F32303136303430373233333633355A
A105020309156B, encrypted
CD8D6091D7AAFBD97B420B58CB3AECA637D42FD03AA8F715BCF4257CBE0C8FCC66DD96041263B421DE4E4024513C7263B1D3D91BF4D1FA18
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.595397: Preauth module encrypted_timestamp (2) (flags=1) returned:
0/Success
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.595457: Produced preauth for next request: 2
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.595517: Sending request (346 bytes) to
domain.subdomain.com
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.598683: Sending initial UDP request to dgram 10.221.74.11:88
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.615505: Received answer from dgram 10.221.74.11:88
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.619074: Response was from master KDC
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.619139: Received error from KDC: -1765328360/Preauthentication failed
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [sss_child_krb5_trace_cb] (0x4000):
[17431] 1460072195.619205: Preauth tryagain input types: 16, 15, 19, 2
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [get_and_save_tgt] (0x0020): 1000:
[-1765328360][Preauthentication failed]
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [map_krb5_error] (0x0020): 1069:
[-1765328360][Preauthentication failed]
(Fri Apr 8 09:36:35 2016) [[sssd[krb5_child[17431]]]] [k5c_send_data] (0x0200): Received
error code 1432158215
As far as I know, libkrb5 reports "preauthentication failed" in case of
a wrong password. Can you please check if that could be the case? Also,
is SSSD talking to the right DC and not some other?
If there is another login failure I should look at, please point me to
the right timestamp, but in the logs, I only see these
"Preauthentication failed" messages.
The steps I followed in the attached logs are roughly as follows:
1. Login as domain user (fail)
2. Login as root
3. stop SSSD, purge logs & cache
4. start sssd
4. getent passwd username
5. id username
6. ssh username(a)127.0.0.1 (fail, retry password a couple of times) 7. stop sssd &
gather logs
Sssd.conf and krb5.conf files are similar to the last machine:
/etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm =
DOMAIN.SUBDOMAIN.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
[realms]
[domain_realm]
---
/etc/sssd/sssd.conf
[sssd]
config_file_version = 2
debug_level = 1
domains =
domain.subdomain.com
services = nss, pam, ssh, pac, sudo
# Allow login without specifying domain suffix with username default_domain_suffix =
domain.subdomain.com
[
domain/domain.subdomain.com]
debug_level = 9
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
ldap_schema = ad
# Allow cached logins
cache_credentials = true
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
#Use FQDN for logins - when multiple domains share same username
use_fully_qualified_domain_names = true
# Ignore forest root domain, but have to specify current domain SID because of RHEL bug -
see
https://fedorahosted.org/sssd/ticket/2828
# These settings can be ignored if AD firewall ports are opened to both current and
parent domain.
subdomains_provider = none
ldap_idmap_default_domain_sid = S-1-5-21-362606526-1294182622-1957402797
#Don't attempt to auto update DNS records dyndns_update = false
[ssh]
debug_level = 1
[nss]
debug_level = 9
filter_users = root,oracle,grid,mfe,postfix filter_groups = root
[pam]
debug_level = 1
pam_account_expired_message = Account expired, please call the help desk.
[sudo]
debug_level = 1
[pac]
debug_level = 1
Please let me know if you need further information.
A.
-----Original Message-----
From: Jakub Hrozek [mailto:jhrozek@redhat.com]
Sent: Thursday, 7 April 2016 19:40
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: Inconsistent SSSD function [SEC=UNOFFICIAL]
On Thu, Apr 07, 2016 at 02:10:39PM +1000, Kosseck, Adam MR wrote:
> UNOFFICIAL
>
>
> Hi Jakub,
>
> Thank you very much!! Those changes seem to have worked :) We're currently
running 1.12.4, but I think it will take several RHEL releases for the official RHEL
repositories to catch up to recent SSSD versions.
RHEL-6.8 will ship with 1.13.4 (1.13.3 with patches that would make the RPM more-or-less
equivalent to 1.13.4), but sadly we don't have a patch for #2828 and it's too late
for 6.8 at this point. I think 7.3 would have it and chances are 6.9 might as well (but
it's better to raise a support request to let RH know that some customers want this
enhancement..)
By the way, both 6.8 and 7.3 will have the fix I mentioned earlier where the trusted
domains are at least marked as disabled, but not the whole main domain. It's not
bullet-proof, though, we still need to fix issues like
https://fedorahosted.org/sssd/ticket/2976
>
> 1) Is there a way to query the SID for the domain from the command-line?
> I'd like to be able to populate the 'ldap_idmap_default_domain_sid'
attribute during the %post% section of my kickstart installs if possible.
That's a good question and I didn't know how to do it myself. I admit I mostly
look into SSSD logs. But it looks like using:
# net rpc getsid -S dc.win.trust.test where dc.win.trust.test is my test AD DC gives
the expected output. But maybe some of the developers more familiar with Samba would have
a better answer?
In SSSD we look at the attributes of the AD domain and extract the SID from its binary
form with the help of samba libraries.
>
> Also, shortly after I got SSSD working on this machine (within an hour) I ran into
the intermittent authentication failures that I mentioned earlier.
> Unfortunately after restarting SSSD with the log level turned up to 9 I've been
unable to replicate. I'll leave the log levels at 9 for a few days and send an
extract through when it recurs.
Yes, please do.
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org