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).
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