Lightdm and the fail whale
by JOHE (John Hearns)
Is anyone else using lighdm with sssd?
Specifically on Ubuntu Xenial. I have sssd working, as I can ssh into the workstation using an account and password.
The display manager is very flaky indeed, and takes a lot to get it to open a desktop session.
I see this in the lightdm logs:
[+296.15s] DEBUG: Authenticate result for user johe: Success
[+296.15s] DEBUG: User johe authorized, but no account of that name exists
I have seen one report of this problem, and the only fix seems to be a restart of the lightdm service. Or a reboot.
Also in the syslog I see
May 23 11:08:31 ibis lightdm[7408]: ** (process:7673): WARNING **: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
May 23 11:08:31 ibis lightdm[7408]: Failed to write utmpx: No such file or directory
May 23 11:08:36 ibis gnome-session-binary[8547]: CRITICAL: We failed, but the fail whale is dead. Sorry....
May 23 11:08:37 ibis lightdm[7408]: Failed to write utmpx: No such file or directory
Has anyone seen similar output?
5 years, 11 months
managing RHEL5 sssd clients without functional ldap_id_mapping?
by James Ralston
We have a small development Active Directory domain where we have
several RHEL7 hosts.
We never extended our AD schema with the RFC2307 attributes
(uidNumber, gidNumber, et. al.). Instead, we just configured sssd
with ldap_id_mapping = true. It works fantastically well!
BUT: now we need to add several RHEL5 hosts to the domain.
The problem is that the RHEL5 version of sssd is 1.5.1, which is too
old to support ldap_id_mapping.
We looked briefly at what would be required to backport a more recent
version of sssd to RHEL5, and quickly abandoned that idea: we would
have to update multiple core system libraries to more recent versions
as well.
But we don't want to have to manually manage all accounts on the RHEL5
hosts. That would be extraordinarily tedious and error-prone.
We've kicked around a few ideas:
1. Add the RFC2307 attributes to Active Directory. Set the
(uidNumber, gidNumber) attributes by logging in to one of the RHEL7
hosts and observing what values sssd has mapped.
2. On one of our RHEL7 hosts, create a list of passwd/group entries
for users/groups we care about, and then distribute that list of
users/groups to the RHEL5 hosts.
We're leaning towards #1, because while it adds an additional step for
user/group creations in AD, it keeps all account management in AD, and
seems like the solution with the least amount of overhead. (Only a
handful of people need to be able to login to the RHEL5 systems, so we
could probably get away with only creating the (uidNumber, gidNumber)
attributes for the users/groups which need to be visible on those
systems.
Does anyone have any other suggestions on how to wrangle both RHEL5
and RHEL7 hosts with sssd?
5 years, 11 months
Samba + sssd + Active Directory integration approach
by Vincenzo De Sanctis
I have been doing research on the internet for several days but I have not
yet found the best way to proceed to meet these specific needs:
I work in a company with about 1000 employees where my predecessor unix
system administrator had configured samba 3 in the best way to meet the
needs of the company at that time without Active Directory, but now
unfortunately or fortunately , the management of the network is on my
hands, alone. I never managed Active Directory, samba was enough at that
time.
The current installed Samba 3 uses the simple smbpasswd as passwd backend,
nis (without openldap and without kerberos), automount (to mount homes and
folder group from other linux) and to manage the users and group folders it
uses the simple standard posix managed by chmod behind samba (not ACL
through setfacl).
But recently we have to connect to a AD root domain in a forest and it's
mandatory by company policy, so I have to introduce Active Directory too.
Straight up, the ideal target is to add AD as a single sign-on, users will
join to the AD domain and mount the shared linux resources from samba 4
keeping the actual directory structure shared (home users, directory
groups), this is because we want to migrate to the two domains gradually
and not in one shot. I know users have to be recreated on AD :(
The online documentations that I found say howto join from linux to AD
using winbind and sssd, but it's not clear how to map gid to the existing
uid on linux (keeping the linux current users), and even if possible how to
override the access posix behind samba (I mean chmod/chown on files not on
smb.conf)?
My idea is to install a new linux server like centos 7.2, setup samba4 and
mount through autofs the resources, join samba4 to AD, remap folders from
gpo and continue to use samba 3 for the old domain and samba4+AD for the
new domain on the two but same samba's shared resources....is it possible!?
Users save on the same map network folder keeping the same data. What is
the best way to combine samba to AD keeping the same shared resources
structure managed on samba3?
I would appreciate your advice on approach! Thank you.
--
Vincenzo De Sanctis
5 years, 11 months
status of sssd bug 1432982
by Spike White
All,
Is sssd bug 1432982 still existing?
https://bugzilla.redhat.com/show_bug.cgi?id=1432982
I’m testing on RHEL7.x , sssd RPM version 1.16.0-19.el7.x86_64. I seem to
be hitting this bug.
Only the primary group is being returned.
Just as in the bug notes, if I set ldap_use_tokengroups = false, then I
see all expected groups for a user. That leads me to believe this RPM
version has this bug.
Honestly, it’s not a big deal for us; we don’t rely on nested subgroups in
AD. So this bug work-around is perfectly fine for us.
Just mainly curious as to current status of bug – if fixed in newer SSSD
versions.
Spike White
5 years, 11 months
Segfault in COPR sssd 1.16.1-2 after upgrade to CentOS 7.5 from 7.4
by Lachlan Musicman
Hola,
As per subject. Running COPR SSSD 1.16.1-2 happily on CentOS 7.4
Upgrade underlying to CentOS 7.5
SSSD segfaults
May 11 15:15:03 papr-res-compute34 systemd: Starting System Security
Services Daemon...
May 11 15:15:03 papr-res-compute34 sssd: Starting up
May 11 15:15:03 papr-res-compute34 kernel: sssd[10076]: segfault at
7ff7a3452d58 ip 00007ff7a3452d58 sp 00007ffe9a5aaca8 error 15 in
memberof.so[7ff7a3452000+1000]
May 11 15:15:03 papr-res-compute34 systemd: sssd.service: main process
exited, code=killed, status=11/SEGV
May 11 15:15:03 papr-res-compute34 systemd: Failed to start System Security
Services Daemon.
May 11 15:15:03 papr-res-compute34 systemd: Unit sssd.service entered
failed state.
May 11 15:15:03 papr-res-compute34 systemd: sssd.service failed.
That's all I get in the logs
Cheers
L.
5 years, 11 months
Help with AD password
by JOHE (John Hearns)
I recently posted to this list regarding a very slow response when getting the groups for a user.
The fix was to set
ldap_schema = rfc2307bis
Now 'groups' and 'id' return very quickly. As an aside, is there an easy way to tell if rfc30172 or rfc3072bis are in operation on a given AD domain?
The problem is now that my account cannot log in... My account is valid, and I can do 'id johe' and 'getent passwd johe' where johe is my account name. I just can't log in with my password.
I am almost 100% sure my password is valid, as I can LDAP bind to the AD controller and perform ldap searches.
Any help on debugging this issue is welcome.
BTW my sAMAccountName is JOHE but I think this is not case sensitive, from what I can see in the sssd logs.
5 years, 11 months
failed to fetch machine password
by shacky
Hi.
I joined a fileserver system with Samba version 4.5.12-Debian (fileserv) in
an Active Directory domain managed by a Samba 4.6.7-Ubuntu installed on
another system using "realm discover" and sssd.
The Samba fileserver is correctly joined into the domain and I can
correctly browse AD users:
root@fileserv:/# getent passwd john.doe
john.doe:*:1616401116:1616400513:John Doe:/home/domain.
com/users/john.doe:/bin/bash
The keytab file is correctly created:
root@fileserv:/# ls -l /etc/krb5.*
-rw-r--r-- 1 root root 2794 May 11 17:32 /etc/krb5.conf
-rw------- 1 root root 2208 May 11 16:18 /etc/krb5.keytab
The problem is that I cannot browse my Samba server from a Windows 10
client joined in the same Active Directory domain with a valid user.
When I try to access to \\fileserv from the Windows client I get these
errors on the Samba server:
========== 8< ==========
May 15 17:23:41 fileserv smbd[13001]: [2018/05/15 17:23:41.610956, 2]
../source3/librpc/crypto/gse_krb5.c:229(fill_mem_keytab_from_secrets)
May 15 17:23:41 fileserv smbd[13001]:
../source3/librpc/crypto/gse_krb5.c:229: failed to fetch machine password
May 15 17:23:41 fileserv smbd[13001]: [2018/05/15 17:23:41.617631, 2]
../source3/librpc/crypto/gse_krb5.c:229(fill_mem_keytab_from_secrets)
May 15 17:23:41 fileserv smbd[13001]:
../source3/librpc/crypto/gse_krb5.c:229: failed to fetch machine password
May 15 17:23:41 fileserv smbd[13001]: [2018/05/15 17:23:41.652613, 0]
../source3/auth/pampass.c:589(smb_pam_account)
May 15 17:23:41 fileserv smbd[13001]: smb_pam_account: PAM: UNKNOWN PAM
ERROR (4) during Account Management for User: john.doe
May 15 17:23:41 fileserv smbd[13001]: [2018/05/15 17:23:41.652658, 2]
../source3/auth/pampass.c:89(smb_pam_error_handler)
May 15 17:23:41 fileserv smbd[13001]: smb_pam_error_handler: PAM: Account
Check Failed : System error
May 15 17:23:41 fileserv smbd[13001]: [2018/05/15 17:23:41.652690, 0]
../source3/auth/pampass.c:797(smb_pam_accountcheck)
May 15 17:23:41 fileserv smbd[13001]: smb_pam_accountcheck: PAM: Account
Validation Failed - Rejecting User john.doe!
May 15 17:23:41 fileserv smbd[13001]: [2018/05/15 17:23:41.653190, 1]
../source3/auth/user_krb5.c:142(get_user_from_kerberos_info)
May 15 17:23:41 fileserv smbd[13001]: PAM account restrictions prevent
user [john.doe] login
May 15 17:23:41 fileserv smbd[13002]: [2018/05/15 17:23:41.668010, 2]
../source3/librpc/crypto/gse_krb5.c:229(fill_mem_keytab_from_secrets)
May 15 17:23:41 fileserv smbd[13002]:
../source3/librpc/crypto/gse_krb5.c:229: failed to fetch machine password
May 15 17:23:41 fileserv smbd[13002]: [2018/05/15 17:23:41.674384, 2]
../source3/librpc/crypto/gse_krb5.c:229(fill_mem_keytab_from_secrets)
May 15 17:23:41 fileserv smbd[13002]:
../source3/librpc/crypto/gse_krb5.c:229: failed to fetch machine password
May 15 17:23:41 fileserv smbd[13002]: [2018/05/15 17:23:41.696605, 0]
../source3/auth/pampass.c:589(smb_pam_account)
May 15 17:23:41 fileserv smbd[13002]: smb_pam_account: PAM: UNKNOWN PAM
ERROR (4) during Account Management for User: john.doe
May 15 17:23:41 fileserv smbd[13002]: [2018/05/15 17:23:41.697795, 2]
../source3/auth/pampass.c:89(smb_pam_error_handler)
May 15 17:23:41 fileserv smbd[13002]: smb_pam_error_handler: PAM: Account
Check Failed : System error
May 15 17:23:41 fileserv smbd[13002]: [2018/05/15 17:23:41.698882, 0]
../source3/auth/pampass.c:797(smb_pam_accountcheck)
May 15 17:23:41 fileserv smbd[13002]: smb_pam_accountcheck: PAM: Account
Validation Failed - Rejecting User john.doe!
May 15 17:23:41 fileserv smbd[13002]: [2018/05/15 17:23:41.700591, 1]
../source3/auth/user_krb5.c:142(get_user_from_kerberos_info)
May 15 17:23:41 fileserv smbd[13002]: PAM account restrictions prevent
user [john.doe] login
========== 8< ==========
This is my Samba server configuration:
========== 8< ==========
#======================= Global Settings =======================
[global]
workgroup = DOMAIN
server string = File Server
dns proxy = no
log level = 3
syslog = 3
log file = /var/log/samba/log.%m
max log size = 1000
syslog only = yes
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = no
unix password sync = no
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:*
%n\n *password\supdated\ssuccessfully* .
pam password change = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
guest account = nobody
load printers = no
disable spoolss = yes
printing = bsd
printcap name = /dev/null
unix extensions = yes
wide links = no
create mask = 0777
directory mask = 0777
use sendfile = yes
aio read size = 16384
aio write size = 16384
local master = yes
time server = no
wins support = no
password server = *
realm = DOMAIN.COM <http://domain.com/>
dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab
security = ads
allow trusted domains = yes
template shell = /bin/bash
template homedir = /home/domain.com/users/%U
# Performance improvements
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
client ntlmv2 auth = yes
========== 8< ==========
Could you help me please?
Thank you very much!
Bye
5 years, 11 months
SSSD for one-way trusted AD domain
by Ondrej Valousek
Hi List,
Question, we have joined machine into AD domain B. This domain has one way trust to domain A. No direct connection from domain B network to DCs in domain A is possible.
Can we use SSSD to authenticate members in domain A.
In windows, this works - but can't get it working in Linux via SSSD (Fedora 25, used realmd for AD join).
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
5 years, 11 months
How to do cross-subdomain user authentication by short name (among trusted AD subdomains) since sssd-ad 1.15.3?
by Spike White
Sssd aficionados,
It is with great interest that I read the announcement of SSSD version
1.15.3.
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Among the new features is this:
In a setup where an IPA domain trusts an Active Directory domain, it is now
possible to define the domain resolution order (see
http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names). Starting
with this version, SSSD is able to read and honor the domain resolution
order, providing a way to resolve Active Directory users by just their
short name. SSSD also supports a new option "domain_resolution_order"
applicable in the "[sssd]" section that allows to configure short names for
AD users in setup with "id_provider=ad" or in a setup with an older IPA
server that doesn't support the "ipa config-mod --domain-resolution-order"
configuration option. Also, it is now possible to use
"use_fully_qualified_names=False" in a subdomain configuration, but please
note that the user and group output from trusted domains will always be
qualified to avoid conflicts.
This corresponds exactly to a use case we have. In fact this design doc (
https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html)
has excellent verbiage describing our use case:
Use cases
Allow the Administrator of an IdM deployment in a trust relationship with
an AD forest to configure its IdM servers and associated IdM clients to
allow user & group resolution and user authentication in all domains (or a
subset of the domains) to be possible by using only the short names without
the domain component, as it’s done by some 3rd party solutions.
That’s our exact situation. We have a parent AD domain – company.com. We
have 3 AD subdomains: amer.company.com, euro.company.com and
asia.company.com. All 3 AD subdomains have a transitive trust with the
parent domain. Meaning all 4 domains fully trust each other. All user
and groups are in the 3 subdomains; none in the parent domain.
We do not have an IPA server, not would our company’s AD administrators
tolerate such – they don’t even allow trusts to Kerberos realms. (They’re
very security-conscious – and windows-centric).
We are currently using a 3rd party software product for our Linux AD
integration. (actually, 2 products -- in different parts of the
company). They’re
currently doing user authentication from all 3 AD subdomains by short
account name. They’re doing it by domain resolution order (always looking
in the local domain first).
In these products, I join the local AD sub-domain by creating a machine
account under my OU.
I have evaluated sssd-ad on RHEL7 as a potential replacement. There are
some obscure dusty corners where sssd-ad may not be able to do what these 3
rd party products do. But outside of that handful of use cases, sssd-ad (&
maybe a couple of companion PAM modules) seem like it’ll accomplish
everything we need for AD-based Linux authentication.
Except for cross-subdomain user authentication by short name.
I’m able to login by short name in the local subdomain. Using:
[domain/amer.company.com]
use_fully_qualified_names = False
Starting with version 1.15.3, I’m supposed to be able to add:
domain_resolution_order = amer.company.com, euro.company.com,
asia.company.com
to the [sssd] section in /etc/sssd/sssd.conf. Then I’m supposed to change
my current subdomain section:
[domain/amer.company.com]
use_fully_qualified_names = False
To:
[domain/amer.company.com/euro.company.com/asia.company.com]
use_fully_qualified_names = False
?
How does that work?
To join the amer.company.com subdomain, ‘realm join’ on my test server
created a machine account under my OU. Namely,
spikerealmd01(a)AMER.COMPANY.COM. (Realm join also properly created the
Kerberos creds in the /etc/krb5.keytab file.)
Thus for [domain/amer.company.com], I had to set up ldap_sasl_authid as so:
ldap_sasl_authid = spikerealmd01(a)AMER.COMPANY.COM
And the other AD subdomains wouldn’t know about this machine account.
I actually tried this recommended syntax (see
https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html ):
[domain/amer.company.com/euro.company.com/asia.company.com]
And I caught a syntax error in /var/log/sssd/sssd.log on startup:
(Sun May 13 15:11:07:070656 2018) [sssd] [sss_ini_call_validators]
(0x0020): [rule/allowed_sections]: Section [domain/
amer.company.com/euro.company.com/asia.company.com] is not allowed. Check
for typos.
(Sun May 13 15:11:07:083115 2018) [sssd] [confdb_get_domain_internal]
(0x0010): Unknown domain [amer.company.com]
(Sun May 13 15:11:07:083247 2018) [sssd] [confdb_get_domains] (0x0010):
Error (2 [No such file or directory]) retrieving domain [amer.company.com],
skipping!
Prior to sssd 1.15.3, in order to authenticate from the various AD
subdomains with sssd-ad even by fully-qualified name, you had to join each
subdomain.
Is that still the case? I have to create a machine account in each
subdomain for a given computer? Then create 3 separate sections in
/etc/sssd/sssd.conf file? Like so:
[sssd]
…
domain_resolution_order = amer.company.com, euro.company.com,
asia.company.com
domains = amer.company.com, euro.company.com, asia.company.com
…
[domain/amer.company.com]
use_fully_qualified_names = False
…
ldap_sasl_authid = spikerealmd01(a)AMER.COMPANY.COM
[domain/euro.company.com]
use_fully_qualified_names = False
…
ldap_sasl_authid = spikerealmd01(a)EURO.COMPANY.COM
[domain/apac.company.com]
use_fully_qualified_names = False
…
ldap_sasl_authid = spikerealmd01(a)APAC.COMPANY.COM
and then I’d have to consolidate the 3 /etc/krb5.keytab files created by
'realm join' into one grand & glorious keytab file with all the above
principals?
After that, I'd be able to user authenticate from the various subdomains by
short name?
Spike White
PS Since I’m testing on RHEL7, actually I’m testing version
sssd-ad-1.16.0-19.el7.x86_64
5 years, 11 months
-1765328360/Preauthentication failed
by TomK
Hey Guy's,
I've the following scenario:
1) srv-remote01 is behind a firewall. We typically use adcli to add
hosts to AD but in this case port 464 is blocked so we can't use adcli
on srv-remote01 since it errors out on the blocked port. Other ports
are open however so normal sssd function can work once connection is
established and krb5.keytab is generated .
2) Since we can't get through port 464, we run the adcli on another
machine within the same domain (MYDOM.ABC) to generate a keytab and copy
over to the target machine srv-remote01.
3) Computer object in AD is called ad-srv-remote01 . The command we use
is below. Note, --computer-name is set to the AD attribute type
sAMAccountName.
adcli join --host-fqdn=srv-remote01 --domain=mdom.abc
--computer-name=AD-SRV-REMOTE01 --login-user=adsrvacct01 -v -S
rem-addc-01.mdom.abc --domain-ou="OU=Linux,OU=Servers
Group,OU=Servers,OU=MDOM,DC=MDOM,DC=abc" --os-name="CentOS7"
--os-version="6.7" --show-details --show-password
So we try to use another host ( ie srv-local01 ) on the same domain to
create a keytab while ensuring KVNO numbers match. But there's an issue
with that as well. When we run the above, the entries in the
krb5.keytab begin with AD-SRV-REMOTE01.
So we manually use ktutil and addent to add the corresponding
SRV-REMOTE01(a)MDOM.ABC entries etc. Using the same 120 character password
adcli returns ( due to --show-password ) above ensuring our objects in
the keytab all have the same password. All this because when SSSD talks
to AD, it tries to find the true host by using SRV-REMOTE01 not the AD
computer object name AD-SRV-REMOTE01 .
However, when we try to use this keytab, we get the below set of errors.
Tried with SSSD 1.12 and SSSD 1.15. Same result. Assume opening up the
firewall right now is not an option.
Anyway around this? Other then that message, there's very little more
that's printed indicating the real cause of the failure. Is there a way
to print more info around the -1765328360/Preauthentication failed
error? It could be due to a number of things but it's not indicated.
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
[sssd[be[MDOM]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14
[Preauthentication failed], expired on [0]
[sssd[be[MDOM]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad
address]
[sssd[be[MDOM]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret
[1432158226](Authentication Failed)
[sssd[be[MDOM]]] [sdap_cli_connect_recv] (0x0040): Unable to establish
connection [13]: Permission denied
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [main] (0x0400):
ldap_child started.
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [main] (0x2000):
context initialized
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x1000): total buffer size: 41
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x1000): realm_str size: 9
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x1000): got realm_str: MDOM.ABC
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x1000): princ_str size: 8
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x1000): got princ_str: SRV-REMOTE01$
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x1000): keytab_name size: 0
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x1000): lifetime: 86400
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [unpack_buffer]
(0x0200): Will run as [0][0].
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[privileged_krb5_setup] (0x2000): Kerberos context initialized
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [main] (0x2000):
Kerberos context initialized
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [become_user]
(0x0200): Trying to become user [0][0].
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [become_user]
(0x0200): Already user [0].
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [main] (0x2000):
Running as [0][0].
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [main] (0x2000):
getting TGT sync
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[ldap_child_get_tgt_sync] (0x2000): got realm_name: [MDOM.ABC]
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[ldap_child_get_tgt_sync] (0x0100): Principal name is:
[SRV-REMOTE01$(a)MDOM.ABC]
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.803319: Getting
initial credentials for SRV-REMOTE01$(a)MDOM.ABC
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.803467: Looked up
etypes in keytab: aes256-cts
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.803508: Sending
request (171 bytes) to MDOM.ABC
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.803735:
Initiating TCP connection to stream 123.123.123.123:88
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.805585: Sending
TCP request to stream 123.123.123.123:88
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809430: Received
answer from stream 123.123.123.123:88
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809554: Response
was from master KDC
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809607: Received
error from KDC: -1765328359/Additional pre-authentication required
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809681:
Processing preauth types: 11, 19, 2, 16, 15
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809710: Selected
etype info: etype rc4-hmac, salt "", params ""
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809755: Selected
etype info: etype rc4-hmac, salt "", params ""
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809799:
Retrieving SRV-REMOTE01$(a)MDOM.ABC from MEMORY:/etc/krb5.keytab (vno 0,
enctype rc4-hmac) with result: 0/Success
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809842: AS key
obtained for encrypted timestamp: rc4-hmac/7361
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809932: Encrypted
timestamp (for 1525932937.809866): plain
301AA011180F32303138303531303036313533375AA10502030C5B8A, encrypted
E38D66FB781CE178E10659E2F3770F5109454EE5808B5929B17D113D2621E30DF3C79F819517A1AED46BD734F55092F36B343BCD
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809958: Preauth
module encrypted_timestamp (2) (flags=1) returned: 0/Success
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.809974: Produced
preauth for next request: 2
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.810004: Sending
request (245 bytes) to MDOM.ABC
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.810100:
Initiating TCP connection to stream 123.123.123.123:88
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.811915: Sending
TCP request to stream 123.123.123.123:88
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.819955: Received
answer from stream 123.123.123.123:88
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.820056: Response
was from master KDC
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.820086: Received
error from KDC: -1765328360/Preauthentication failed
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[sss_child_krb5_trace_cb] (0x4000): [14068] 1525932937.820121: Preauth
tryagain input types: 11, 19, 2, 16, 15
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[ldap_child_get_tgt_sync] (0x0010): Failed to init credentials:
Preauthentication failed
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[unique_filename_destructor] (0x2000): Unlinking
[/var/lib/sss/db/ccache_MDOM.ABC_1KdDyX]
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [main] (0x0020):
ldap_child_get_tgt_sync failed.
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]]
[prepare_response] (0x0400): Building response for result [-1765328360]
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [pack_buffer]
(0x2000): response size: 44
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [pack_buffer]
(0x1000): result [14] krberr [-1765328360] msgsize [24] msg
[Preauthentication failed]
(Thu May 10 02:15:37 2018) [[sssd[ldap_child[14068]]]] [main] (0x0400):
ldap_child completed successfully
5 years, 11 months
