session management by sssd (when using LDAP as an authentication and authorization server)
by Hristina Marosevic
Hello,
I installed and configured SSSD with LDAP server OUD (Oracle Unified Directory). Everything works fine so far, except for one thing which I consider as a vulnerability.
I just found out that there is a potential security hole which is the old session of a user who lost his authorization.
Generic example:
User1 has to belong to the LDAP group sshUsers which is configured as an access filter on the SSSD client in order to be authorized (after the successfull authentication) for access to the remote linux machine, where the SSSD client is installed.
User1 is a member of the LDAP group sshUsers and logs in to the remote linux machine.
After the successfull login of the User1 to the remote linux machine, its membership in the LDAP group sshUsers is removed i.e. User1 looses it authorization to access the remote linux machine.
What happens as a result is:
1. The active ssh connection od User1 to the remote linux machine which was established before he lost his authorization is still active!!
2. User1 (after he lost his authorization) can not login to the remote linux machine anymore - this is okay.
Security hole - explained in 1.
Can you please explain to me if there is a possiblity for SSSD to manage the sessions, how to do that? If this is not possible (whn using OUD) should it be proposed as a bug?
Other than that, how is session managed on the OS layer?
Thank you!
BR,
Hristina
4 years, 2 months
- 4
- 5
Restricted access to MemberOf attribute in AD
by Eugene Vilensky
Greetings,
My company restricts which AD entities have access to a Domain User's
MemberOf attribute. This is done precisely as described by this
institution here:
https://itconnect.uw.edu/wares/msinf/design/arch/group-member-privacy/
Self can read own MemberOf.
We've never seen an impact on Windows clients.
However for SSSD the effect is obvious: "Domain Users" is the only Group
returned. It appears to be that SSSD uses the permissions of the Computer
account for this operation.
Is there any configurable alternative to use the User's own permissions to
resolve MemberOf on a user?
Regards,
Eugene
4 years, 2 months
- 2
- 1
SSSD / PAM / LDAP problem.
by Mark London
Hi all - Recently, about once a week, SSSD will stop working on our mail
server (version 1.16.4, Redhat 7) will stop properly authenticating. I
set the debug logging to 6, and here are the lines in our domain log
(domain=PSFC), after which nothing else in that log appears, until SSSD
is restarted:
(Wed Feb 19 14:03:57 2020) [sssd[be[PSFC]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'LDAP'
(Wed Feb 19 14:03:57 2020) [sssd[be[PSFC]]] [be_resolve_server_process]
(0x0200): Found address for server psfcdc2.psfc.mit.edu:
[198.125.180.133] TTL 708
(Wed Feb 19 14:03:57 2020) [sssd[be[PSFC]]] [sdap_uri_callback]
(0x0400): Constructed uri 'ldaps://psfcdc2.psfc.mit.edu'
(Wed Feb 19 14:03:57 2020) [sssd[be[PSFC]]]
[sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for
connecting
Normally, the following lines should follow:
(Wed Feb 19 14:02:54 2020) [sssd[be[PSFC]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(objectclass=*)][].
(Wed Feb 19 14:02:54 2020) [sssd[be[PSFC]]]
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
errmsg set
(Wed Feb 19 14:02:54 2020) [sssd[be[PSFC]]]
[sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
level to [6]
(Wed Feb 19 14:02:54 2020) [sssd[be[PSFC]]]
[sdap_get_server_opts_from_rootdse] (0x0100): Will look for schema at
[CN=Schema,CN=Configurati\
on,DC=psfc,DC=mit,DC=edu]
Any idea why it stopped at that point? Would it help to increase the
debug level? (As an aside, sssd_nss.log and sssd_pam.log, do continue
to output lines, so SSSD hasn't crashed). Here is my SSSD.CONF file.
Thanks! - Mark
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = PSFC
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
debug_level = 6
[pam]
reconnection_retries = 3
debug_level = 6
[domain/PSFC]
description = LDAP domain with AD server
enumerate = false
min_id = 501
cache_credentials = true
debug_level = 6
ldap_purge_cache_timeout = 0
ldap_enumeration_refresh_timeout = 300
ldap_referrals = false
id_provider = ldap
chpass_provider = none
auth_provider = ldap
ldap_tls_reqcert = allow
ldap_uri =
ldaps://psfcdc1.psfc.mit.edu,ldaps://psfcdc2.psfc.mit.edu,ldaps://psfcdc3...
ldap_schema = rfc2307bis
ldap_search_base = dc=psfc,dc=mit,dc=edu
ldap_user_search_base = dc=psfc,dc=mit,dc=edu
ldap_group_search_base = dc=psfc,dc=mit,dc=edu
ldap_default_bind_dn = CN=ADldapreadonly,OU=Computer Group,OU=PSFC
Users,DC=psfc,DC=mit,DC=edu
ldap_default_authtok_type = password
ldap_default_authtok = ldapread
ldap_user_object_class = person
ldap_user_name = sAMAccountName
ldap_user_uid_number = msSFU30UidNumber
ldap_user_gid_number = msSFU30GidNumber
ldap_user_home_directory = msSFU30HomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_member = msSFU30PosixMember
ldap_user_member_of = msSFU30PosixMemberOf
ldap_group_name = name
ldap_group_gid_number = msSFU30GidNumber
ldap_force_upper_case_realm = True
4 years, 2 months
- 2
- 1
Proper support for Hostbased Authentication
by Vinícius Ferrão
Hello,
4 months ago I’ve opened an RFE on pagure about proper support for SSH HBA with SSSD fetching hostkeys from LDAP, it’s described here: https://pagure.io/SSSD/sssd/issue/4106
Since there’s no updates on the RFE I would like to bring the discussion to the list.
I came across another issue regarding SSH HBA on RHEL7, that’s reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1801459 and this motivated me to bring the discussion to here.
At this moment I’m working around the issue sharing the same SSH Host Keys between all the servers that should use SSH Hostbased Authentication, which is extremely bad and I really don’t want to continue in this path.
So is anyone out there having the same issues with Hostbased Authentication with SSSD + IPA?
Thanks,
4 years, 2 months
- 2
- 2
Re: sssd 1.16.4. ADV190023.
by Sumit Bose
On Fri, Feb 14, 2020 at 02:46:34PM +0000, Mote, Todd wrote:
> I saw the same results in the traces I sent Sumit yesterday. What I'm coming to believe, is that this chart:
>
>
>
> [cid:image001.png@01D5E30D.278BEFE0]
>
>
>
> From here https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/l...
>
>
>
> Seems to show that regardless of how the domain is set, i.e. requiring signing or not, if you’re employing local encryption, via GSSAPI, or SSL, the connection will succeed. And is technically encrypted, so satisfies the security requirements, but Microsoft still logs on the domain that the connection was made without signing.
>
>
>
> Admittedly, that’s not what, I think, everybody expected to happen when you “Require signing” on the domain and you don’t sign on the client. I would have expected connections to fail at that point. But given that GSS-SPNEGO is only available on RHEL 7.2ish + and not on RHEL 6, and likely similarly aged distros, requiring signing, and not allowing that 5th option would have basically broken an entire operating system, or more. I also suspect that Macs are in a similar state. Using the -ssl switch on the dsconfigad utility sets it to “line 4” in the chart, but requires, just like it would for RHEL additional certificates be made available to every install. I have seen similar commands for dsconfigad like, dsconfigad -packetsign require, but it’s only available in 10.5 and later, which is probably about the time GSS-SPNEGO was added to RHEL 7, I suspect.
>
>
>
> So when I look in splunk and have it count the number of unsigned binds in the last 24 hours and see a number like 2,518,239. I can’t assume that all those are insecure. What I can’t tell from that is how many of those are using GSSAPI or SSL, because they are logged as unsigned whether they use it or not.
Hi,
thank you both for the traces. I did similar tests locally and got the
same results.
I agree there is something odd with GSSAPI because even if both channel
binding and LDAP signing is enforced the GSSAPI requests work as
expected but you get the event log message as well.
You can force to make GSSAPI fail by lowering the SSF, since LDAP
signing (integrity) is already available with SSF 1 you have to set it
to 0:
# LDAPSASL_SECPROPS=maxssf=1 ldapsearch -H ldap://ad1.win2016.test -Y GSSAPI -b 'DC=win2016,DC=test' samaccountname=Administrator DN -LLL
SASL/GSSAPI authentication started
SASL username: Administrator(a)WIN2016.TEST
SASL SSF: 1
SASL data security layer installed.
dn: CN=Administrator,CN=Users,DC=win2016,DC=test
# refldap://ForestDnsZones.win2016.test/DC=ForestDnsZones,DC=win2016,DC=test
# refldap://sub1.win2016.test/DC=sub1,DC=win2016,DC=test
# refldap://DomainDnsZones.win2016.test/DC=DomainDnsZones,DC=win2016,DC=test
# refldap://win2016.test/CN=Configuration,DC=win2016,DC=test
# LDAPSASL_SECPROPS=maxssf=0 ldapsearch -H ldap://ad1.win2016.test -Y GSSAPI -b 'DC=win2016,DC=test' samaccountname=Administrator DN -LLL
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Strong(er) authentication required (8)
additional info: 00002028: LdapErr: DSID-0C090200, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839
So if there is really no LDAP signing/integrity the request is rejected
by AD as expected.
I have see you took part in the discussion at
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/l...
so maybe Microsoft can shed some light on this.
I'm inspecting the network packets in the GSSAPI case with a co-worker
and he was able to spot a flag in one of the packets send by the AD DC
during the SASL/GSSAPI handshake which looked odd. We are trying to
investigate further in this direction.
bye,
Sumit
>
>
>
> Awesome.
>
>
>
> Todd
>
>
>
>
>
>
>
> -----Original Message-----
> From: James Ralston <ralston(a)pobox.com>
> Sent: Thursday, February 13, 2020 3:50 PM
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
>
>
>
> On Thu, Feb 13, 2020 at 10:24 AM Mote, Todd <moter(a)austin.utexas.edu<mailto:moter@austin.utexas.edu>> wrote:
>
>
>
> > Only using GSSAPI causes the unsigned SASL event.
>
> >
>
> > root@anti-test:~ # ldapsearch -H ldap://dc01a.ADTEST.domain.com -Y
>
> > GSSAPI -b '' -s base SASL/GSSAPI authentication started SASL username:
>
> > ANTI-TEST$(a)ADTEST.domain.com<mailto:ANTI-TEST$@ADTEST.domain.com> SASL SSF: 256 SASL data security layer
>
> > installed.
>
> > # extended LDIF
>
> > #
>
> > # LDAPv3
>
> > # base <> with scope baseObject
>
> > # filter: (objectclass=*)
>
> > # requesting: ALL
>
> >
>
> > GSS-SPNEGO looks the same, and does not trigger the unsigned event.
>
> >
>
> > root@anti-test:~ # ldapsearch -H ldap://dc01a.ADTEST.domain.com -Y
>
> > GSS-SPNEGO -b '' -s base SASL/GSS-SPNEGO authentication started SASL
>
> > username: ANTI-TEST$(a)ADTEST.domain.com<mailto:ANTI-TEST$@ADTEST.domain.com> SASL SSF: 256 SASL data
>
> > security layer installed.
>
> > # extended LDIF
>
> > #
>
> > # LDAPv3
>
> > # base <> with scope baseObject
>
> > # filter: (objectclass=*)
>
> > # requesting: ALL
>
>
>
> We see the exact same thing on our RHEL7 hosts.
>
>
>
> Looking at the packet traces of "-Y GSSAPI" and "-Y GSS-SPNEGO", both connections issue the query under SASL GSS-API Privacy. But with GSSAPI, it takes 3 steps to complete the bind request and activate SASL GSS-API Privacy:
>
>
>
> bindRequest(1) "<ROOT>" sasl
>
> bindResponse(1) saslBindInProgress
>
> bindRequest(2) "<ROOT>" sasl
>
> bindResponse(2) saslBindInProgress
>
> bindRequest(3) "<ROOT>" sasl
>
> bindResponse(3) success
>
> SASL GSS-API Privacy: payload (148 bytes)
>
> SASL GSS-API Privacy: payload (160 bytes)
>
> SASL GSS-API Privacy: payload (7 bytes)
>
>
>
> With GSS-SPNEGO, it takes only one step:
>
>
>
> bindRequest(1) "<ROOT>" sasl
>
> bindResponse(1) success
>
> SASL GSS-API Privacy: payload (148 bytes)
>
> SASL GSS-API Privacy: payload (160 bytes)
>
> SASL GSS-API Privacy: payload (7 bytes)
>
>
>
> Our Windows admins confirm that the GSSAPI query triggers this warning:
>
>
>
> The following client performed a SASL
>
> (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting
>
> signing (integrity verification), or performed a simple bind over
>
> a clear text (non-SSL/TLS-encrypted) LDAP connection.
>
>
>
> …but the GSS-SPNEGO query does not.
>
>
>
> Sumit, in a moment I'll reply just to you, and include the packet traces.
>
> _______________________________________________
>
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.fedorahosted.org>
>
> Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
>
> List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
>
> List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>
> >> This message is from an external sender. Learn more about why this <<
>
> >> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
4 years, 2 months
- 1
- 0
Re: sssd 1.16.4. ADV190023.
by James Ralston
On Thu, Feb 13, 2020 at 10:24 AM Mote, Todd <moter(a)austin.utexas.edu> wrote:
> Only using GSSAPI causes the unsigned SASL event.
>
> root@anti-test:~ # ldapsearch -H ldap://dc01a.ADTEST.domain.com -Y GSSAPI -b '' -s base
> SASL/GSSAPI authentication started
> SASL username: ANTI-TEST$(a)ADTEST.domain.com
> SASL SSF: 256
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope baseObject
> # filter: (objectclass=*)
> # requesting: ALL
>
> GSS-SPNEGO looks the same, and does not trigger the unsigned event.
>
> root@anti-test:~ # ldapsearch -H ldap://dc01a.ADTEST.domain.com -Y GSS-SPNEGO -b '' -s base
> SASL/GSS-SPNEGO authentication started
> SASL username: ANTI-TEST$(a)ADTEST.domain.com
> SASL SSF: 256
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope baseObject
> # filter: (objectclass=*)
> # requesting: ALL
We see the exact same thing on our RHEL7 hosts.
Looking at the packet traces of "-Y GSSAPI" and "-Y GSS-SPNEGO", both
connections issue the query under SASL GSS-API Privacy. But with
GSSAPI, it takes 3 steps to complete the bind request and activate
SASL GSS-API Privacy:
bindRequest(1) "<ROOT>" sasl
bindResponse(1) saslBindInProgress
bindRequest(2) "<ROOT>" sasl
bindResponse(2) saslBindInProgress
bindRequest(3) "<ROOT>" sasl
bindResponse(3) success
SASL GSS-API Privacy: payload (148 bytes)
SASL GSS-API Privacy: payload (160 bytes)
SASL GSS-API Privacy: payload (7 bytes)
With GSS-SPNEGO, it takes only one step:
bindRequest(1) "<ROOT>" sasl
bindResponse(1) success
SASL GSS-API Privacy: payload (148 bytes)
SASL GSS-API Privacy: payload (160 bytes)
SASL GSS-API Privacy: payload (7 bytes)
Our Windows admins confirm that the GSSAPI query triggers this warning:
The following client performed a SASL
(Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting
signing (integrity verification), or performed a simple bind over
a clear text (non-SSL/TLS-encrypted) LDAP connection.
…but the GSS-SPNEGO query does not.
Sumit, in a moment I'll reply just to you, and include the packet
traces.
4 years, 2 months
- 2
- 1
sssd 1.16.4. ADV190023.
by David David
Hello,
i guess that you probably heard about ADV190023. Our AD admin told me that linux servers which are under my responsibility send an unsigned request to AD, what could be a problem related to this incomming Ad patch: https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-bindin....
I am using sssd in "sssd-ad mode." The communication between a linux servers and our AD is crypted by kerberos, so this should be ok.
I found only one kind of request which could result in potential failure. After mentioned patching implementation. See please below:
(Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_execute] (0x0400): Task [AD machine account password renewal]: executing task, timeout 60 seconds
(Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_done] (0x0400): Task [AD machine account password renewal]: finished successfully
(Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_schedule] (0x0400): Task [AD machine account password renewal]: scheduling task 86400 seconds from last
Everytime, this task is executed, our AD write into its log that an unsighned request came from my linux server. I tried to set ldap_tls_cert and ldap_tls_key into sssd.conf which point to the cert and key generated by our AD, but without success.
I tried to find a proper solution how to sign the request that AD stop complaining, but nothing usefull found.
My question is. Should I be affraid that after the patching, our AD will stop to communicate with my linux servers?
Really thanks in advance for your answer. I really appreciate your effort.
4 years, 2 months
- 3
- 2
Re: sssd 1.16.4. ADV190023.
by Sumit Bose
On Thu, Feb 13, 2020 at 03:26:38PM +0000, Mote, Todd wrote:
> Hmm.. will have to come up with something else for those hosts then... upgrade to 7+ I guess since EOL is Nov... maybe MS will wait until Nov to push the patch that turns on ldap signing? One can hope I guess.
Hi,
the alternatve would be to use 'id_provider = ldap' and 'ldap_uri =
ldaps://your_ad_dc.your.domain ...' to use LDAPS to connect to the AD
DC.
Additionally you have to set some other options to get a similar
behavior than 'id_provider = ad'. They are documented in the sssd-ad man
page of recent SSSD version in the 'MODIFIED DEFAULT OPTIONS' section.
For easier reference I list it here:
"""
MODIFIED DEFAULT OPTIONS
Certain option defaults do not match their respective backend
provider defaults, these option names and AD provider-specific defaults
are listed below:
KRB5 Provider
o krb5_validate = true
o krb5_use_enterprise_principal = true
LDAP Provider
o ldap_schema = ad
o ldap_force_upper_case_realm = true
o ldap_id_mapping = true
o ldap_sasl_mech = gssapi
o ldap_referrals = false
o ldap_account_expire_policy = ad
o ldap_use_tokengroups = true
"""
Finally some user and group attribute mappings must be changed. I think
this is not listed in a man page but you can find the needed option by
comparing the ldap default
https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ldap/ldap_opts.c#...
with the ad version
https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ad/ad_opts.c#_193
bye,
Sumit
>
> Todd
>
> -----Original Message-----
> From: Sumit Bose <sbose(a)redhat.com>
> Sent: Thursday, February 13, 2020 9:17 AM
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
>
> On Thu, Feb 13, 2020 at 03:10:31PM +0000, Mote, Todd wrote:
> > Tangentially, GSS-SPNEGO isn't available on RHEL 6, correct?
>
> Hi,
>
> not not available in RHEL-6, iirc it was added in RHEL-7.2 or RHEL-7.3.
>
> bye,
> Sumit
>
> >
> > Todd
> >
> > -----Original Message-----
> > From: Sumit Bose <sbose(a)redhat.com>
> > Sent: Thursday, February 13, 2020 8:51 AM
> > To: End-user discussions about the System Security Services Daemon
> > <sssd-users(a)lists.fedorahosted.org>
> > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> >
> > On Thu, Feb 13, 2020 at 01:42:33PM +0000, Mote, Todd wrote:
> > > I'll work on getting that today. This is what I know so far.
> > >
> > >
> > >
> > > Test system updated through our Satellite, so nothing special or different. Yum updated everything:
> > >
> > > RHEL 7.7
> > >
> > > sssd-1.16.4-21.el7_7.1.x86_64
> > >
> > > adcli-0.8.1-9.el7.x86_64
> > >
> > >
> > >
> > > Domain:
> > >
> > > Windows Server 2016
> > >
> > > regkey ldapserverintegrity=2
> > >
> > > regkey ldapenforcechannelbinding=1
> > >
> > >
> > >
> > > we splunk our domain logs and my coworker wrote a dashboard to display the entries when either simple binds or unsigned sasl occur. Over the last 24 hours my test host triggered the unsigned sasl entry 13 times. Each entry corresponds precisely to the adcli check password attempt in the logs. It doesn't log an unsigned sasl event every hour, and a couple of times not at all for several hours. I'm not sure what's behind that. Times here are UTC -6. I’m in the 7:00 hour here. The most recent entry is below. I’ll work to get a trace running by the next hour, in case it logs it again.
> >
> > Hi,
> >
> > can you try to run the following ldapsearch commands and check which one causes a message in the event log?
> >
> > ldapsearch -H cldap://ad-server.ADTEST.domain.com -b '' -s base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon
> >
> > ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s
> > base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon
> >
> > ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s
> > base
> >
> > kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM'
> > ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSSAPI -b ''
> > -s base
> >
> > kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM'
> > ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSS-SPNEGO -b
> > '' -s base
> >
> > bye,
> > Sumit
> >
> > >
> > >
> > >
> > > This behavior also happens with RHEL 8, sssd 2.2 and adcli 0.8.2. I see the same entries logged in both the sssd log on the device and the domain.
> > >
> > >
> > > Timestamp<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-mo
> > > ni
> > > toring/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%2
> > > 0s
> > > ource%3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%2
> > > 0%
> > > 7C%20rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5
> > > Cs
> > > *Client%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3C
> > > Po
> > > rt%3E%5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authent
> > > ic
> > > ate%20as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(
> > > %3
> > > F%3CBindingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_t
> > > im
> > > e%2C%20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20d
> > > ns
> > > lookup%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%
> > > 20
> > > FQDN%20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.
> > > 22
> > > 6%20%7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsig
> > > ne
> > > d%20SASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Tim
> > > es
> > > tamp%20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Addres
> > > s%
> > > 22%2CUserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Bindi
> > > ng
> > > %20Type%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2
> > > CF
> > > QDN%2C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.m
> > > od
> > > e=smart&dispatch.sample_ratio=1&display.page.search.tab=statistics&d
> > > is
> > > play.general.type=statistics&display.statistics.sortColumn=Timestamp
> > > &d
> > > isplay.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-
> > > 01
> > > FA-4F7E-929B-F56DE7E31D3B> User
> > > Name<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitor
> > > in
> > > g/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20sour
> > > ce
> > > %3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%7C%
> > > 20
> > > rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs*Cl
> > > ie
> > > nt%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPort%
> > > 3E
> > > %5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authenticate
> > > %2
> > > 0as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3F%3
> > > CB
> > > indingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_time%2
> > > C%
> > > 20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dnsloo
> > > ku
> > > p%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20FQD
> > > N%
> > > 20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.226%2
> > > 0%
> > > 7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigned%2
> > > 0S
> > > ASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Timestam
> > > p%
> > > 20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%22%
> > > 2C
> > > UserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding%20
> > > Ty
> > > pe%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CFQDN
> > > %2
> > > C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mode=s
> > > ma
> > > rt&dispatch.sample_ratio=1&display.page.search.tab=statistics&display.
> > > general.type=statistics&display.statistics.sortColumn=Timestamp&disp
> > > la
> > > y.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01FA-
> > > 4F
> > > 7E-929B-F56DE7E31D3B> Binding
> > > Type<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitor
> > > in
> > > g/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20sour
> > > ce
> > > %3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%7C%
> > > 20
> > > rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs*Cl
> > > ie
> > > nt%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPort%
> > > 3E
> > > %5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authenticate
> > > %2
> > > 0as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3F%3
> > > CB
> > > indingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_time%2
> > > C%
> > > 20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dnsloo
> > > ku
> > > p%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20FQD
> > > N%
> > > 20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.226%2
> > > 0%
> > > 7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigned%2
> > > 0S
> > > ASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Timestam
> > > p%
> > > 20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%22%
> > > 2C
> > > UserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding%20
> > > Ty
> > > pe%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CFQDN
> > > %2
> > > C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mode=s
> > > ma
> > > rt&dispatch.sample_ratio=1&display.page.search.tab=statistics&display.
> > > general.type=statistics&display.statistics.sortColumn=Timestamp&disp
> > > la
> > > y.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01FA-
> > > 4F
> > > 7E-929B-F56DE7E31D3B>
> > > 02-13-2020 07:12:33
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-13-2020 05:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-13-2020 03:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-13-2020 02:12:35
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-13-2020 01:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 23:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 22:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 19:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 17:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 14:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 13:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 09:12:35
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > > 02-12-2020 08:12:34
> > > ADTEST\ANTI-TEST$
> > > Unsigned SASL
> > >
> > >
> > >
> > >
> > >
> > > (Thu Feb 13 07:12:33 2020) [sssd[be[adtest.domain.com]]]
> > > [ad_machine_account_password_renewal_done] (0x1000): --- adcli
> > > output
> > > start---
> > >
> > > * Found realm in keytab: ADTEST.domain.com
> > >
> > > * Found computer name in keytab: ANTI-TEST
> > >
> > > * Found service principal in keytab: host/ANTI-TEST
> > >
> > > * Found service principal in keytab:
> > > host/anti-test.adtest.domain.com
> > >
> > > * Found host qualified name in keytab: anti-test.adtest.domain.com
> > >
> > > * Found service principal in keytab: RestrictedKrbHost/ANTI-TEST
> > >
> > > * Found service principal in keytab:
> > > RestrictedKrbHost/anti-test.adtest.domain.com
> > >
> > > * Using fully qualified name: anti-test.adtest.domain.com
> > >
> > > * Using domain name: adtest.domain.com
> > >
> > > * Calculated computer account name from fqdn: ANTI-TEST
> > >
> > > * Using domain realm: adtest.domain.com
> > >
> > > * Sending netlogon pings to domain controller: cldap://
> > > xxx.xxx.xxx.xxx
> > >
> > > * Received NetLogon info from: dc01a.adtest.domain.com
> > >
> > > * Wrote out krb5.conf snippet to
> > > /tmp/adcli-krb5-RCmgmC/krb5.d/adcli-krb5-conf-vPdhBf
> > >
> > > * Authenticated as default/reset computer account: ANTI-TEST
> > >
> > > * Looked up short domain name: ADTEST
> > >
> > > * Looked up domain SID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx
> > >
> > > * Using fully qualified name: anti-test.adtest.domain.com
> > >
> > > * Using domain name: adtest.domain.com
> > >
> > > * Using computer account name: ANTI-TEST
> > >
> > > * Using domain realm: adtest.domain.com
> > >
> > > * Using fully qualified name: anti-test.adtest.domain.com
> > >
> > > * Enrolling computer name: ANTI-TEST
> > >
> > > * Generated 120 character computer password
> > >
> > > * Using keytab: FILE:/etc/krb5.keytab
> > >
> > > * Found computer account for ANTI-TEST$ at:
> > > CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Depar
> > > tm
> > > ents,DC=adtest,DC=domain,DC=com
> > >
> > > * Retrieved kvno '6' for computer account in directory:
> > > CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Depar
> > > tm
> > > ents,DC=adtest,DC=domain,DC=com
> > >
> > > * Password not too old, no change needed
> > >
> > > * Sending netlogon pings to domain controller:
> > > cldap://xxx.xxx.xxx.xxx
> > >
> > > * Received NetLogon info from: dc01a.adtest.domain.com
> > >
> > > * Checking RestrictedKrbHost/anti-test.adtest.domain.com
> > >
> > > * Added RestrictedKrbHost/anti-test.adtest.domain.com
> > >
> > > * Checking host/anti-test.adtest.domain.com
> > >
> > > * Added host/anti-test.adtest.domain.com
> > >
> > > * Checking RestrictedKrbHost/ANTI-TEST
> > >
> > > * Added RestrictedKrbHost/ANTI-TEST
> > >
> > > * Checking host/ANTI-TEST
> > >
> > > * Added host/ANTI-TEST
> > >
> > > ---adcli output end---
> > >
> > >
> > >
> > > Todd
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Sumit Bose <sbose(a)redhat.com>
> > > Sent: Thursday, February 13, 2020 1:36 AM
> > > To: sssd-users(a)lists.fedorahosted.org
> > > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> > >
> > >
> > >
> > > On Wed, Feb 12, 2020 at 01:11:14PM +0000, Mote, Todd wrote:
> > >
> > > > Sumit
> > >
> > > >
> > >
> > > > Any idea on when your SASL/GSS-SPNEGO patch for adcli might make it downstream? It seems that adcli is checking once an hour on the age of the password and is the only thing left on my test hosts that is triggering the Unsigned SASL event on our domain controllers. I have tinkered with the GSSAPI and other settings in ldap.conf, so none of the connections are simple, just unsigned, which isn't terrible, but it'd be nice to eliminate them altogether, ya know?
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > >
> > > they are planned for the next RHEL releases and I'm about to prepare Fedora packages.
> > >
> > >
> > >
> > > I did some tests with older RHEL7 versions and didn't come across issues even with only SASL/GSSAPI when I enforce channel binding and LDAP signing on AD. Would it be possible to send a network trace which covers the connection attempt of adcli which causes the issue?
> > >
> > >
> > >
> > > bye,
> > >
> > > Sumit
> > >
> > >
> > >
> > > >
> > >
> > > > Todd
> > >
> > > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: Sumit Bose <sbose(a)redhat.com<mailto:sbose@redhat.com>>
> > >
> > > > Sent: Thursday, February 6, 2020 10:18 AM
> > >
> > > > To:
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > st
> > > > ed.org>
> > >
> > > > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> > >
> > > >
> > >
> > > > On Thu, Feb 06, 2020 at 03:05:13PM +0000, Ondrej Valousek wrote:
> > >
> > > > > did you try refreshing the machine password in AD?Looks like it's too old.
> > >
> > > > > O.
> > >
> > > > > ________________________________
> > >
> > > > > From: David David <modrik(a)seznam.cz<mailto:modrik@seznam.cz>>
> > >
> > > > > Sent: Thursday, February 6, 2020 12:09 PM
> > >
> > > > > To:
> > > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedora
> > > > > ho
> > > > > sted.org>
> > >
> > > > > <sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedor
> > > > > ah
> > > > > osted.org>>
> > >
> > > > > Subject: [SSSD-users] sssd 1.16.4. ADV190023.
> > >
> > > > >
> > >
> > > > > Hello,
> > >
> > > > > i guess that you probably heard about ADV190023. Our AD admin told me that linux servers which are under my responsibility send an unsigned request to AD, what could be a problem related to this incomming Ad patch: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport....
> > >
> > > > >
> > >
> > > > > I am using sssd in "sssd-ad mode." The communication between a linux servers and our AD is crypted by kerberos, so this should be ok.
> > >
> > > > >
> > >
> > > > > I found only one kind of request which could result in potential failure. After mentioned patching implementation. See please below:
> > >
> > > > >
> > >
> > > > > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_execute] (0x0400):
> > >
> > > > > Task [AD machine account password renewal]: executing task,
> > > > > timeout
> > >
> > > > > 60 seconds (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]]
> > > > > [be_ptask_done]
> > >
> > > > > (0x0400): Task [AD machine account password renewal]: finished
> > >
> > > > > successfully (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]]
> > >
> > > > > [be_ptask_schedule] (0x0400): Task [AD machine account password
> > >
> > > > > renewal]: scheduling task 86400 seconds from last
> > >
> > > >
> > >
> > > > Hi,
> > >
> > > >
> > >
> > > > Ondrej is right, those messages are related to adcli trying to
> > > > update
> > >
> > > > the machine account password if it is too old. To check when the
> > >
> > > > password was last updated adcli uses LDAP with SASL/GSSAPI. I've
> > > > added
> > >
> > > > a patch so that SASL/GSS-SPNEGO is used when it is available in
> > > > the AD
> > >
> > > > DC side
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > gi
> > > > tl
> > >
> > > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2Fa6f795ba3d6048b32d7
> > > > 86
> > > > 34
> > >
> > > > 68688bf7f42b2cafd&data=02%7C01%7Cmoter%40austin.utexas.edu%7C8
> > > > 77
> > > > 19
> > >
> > > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1
> > > > %7
> > > > C1
> > >
> > > > %7C637171761658405405&sdata=rPcG9mknHufVZUy6ege6n2vx%2B1Hy5XQh
> > > > Dn
> > > > 7H
> > >
> > > > 8ugqlzA%3D&reserved=0 With SASL/GSS-SPNEGO all requirements
> > > > are
> > >
> > > > negotiated automatically and signing should be switched on if required.
> > >
> > > >
> > >
> > > > With SASL/GSSAPI you might be able to tune this manually, see e.g. the SASL and GSSAPI options in man ldap.conf for details.
> > >
> > > >
> > >
> > > > There is also a patch for adcli which tells adcli to use ldaps
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > gi
> > > > tl
> > >
> > > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2F85097245b57f1903372
> > > > 25
> > > > db
> > >
> > > > dbf6e33b58616c092&data=02%7C01%7Cmoter%40austin.utexas.edu%7C8
> > > > 77
> > > > 19
> > >
> > > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1
> > > > %7
> > > > C1
> > >
> > > > %7C637171761658405405&sdata=9dY6eOGTKimEYqydWbRFROldOTNRM16t1c
> > > > ae
> > > > Uh
> > >
> > > > bBTiY%3D&reserved=0 but this is currently not used by SSSD.
> > > > And in
> > >
> > > > general I think using GSS-SPNEGO is sufficient since there is no requirement to switch to ldaps (if I read the advisory correctly) and AD does not enable ldaps by default as well.
> > >
> > > >
> > >
> > > > bye,
> > >
> > > > Sumit
> > >
> > > >
> > >
> > > > >
> > >
> > > > > Everytime, this task is executed, our AD write into its log that an unsighned request came from my linux server. I tried to set ldap_tls_cert and ldap_tls_key into sssd.conf which point to the cert and key generated by our AD, but without success.
> > >
> > > > >
> > >
> > > > > I tried to find a proper solution how to sign the request that AD stop complaining, but nothing usefull found.
> > >
> > > > >
> > >
> > > > > My question is. Should I be affraid that after the patching, our AD will stop to communicate with my linux servers?
> > >
> > > > >
> > >
> > > > > Really thanks in advance for your answer. I really appreciate your effort.
> > >
> > > > > _______________________________________________
> > >
> > > > > sssd-users mailing list --
> > > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedora
> > > > > ho
> > > > > sted.org> To
> > >
> > > > > unsubscribe send an email to
> > > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@
> > > > > li
> > > > > sts.fedorahosted.org>
> > >
> > > > > Fedora Code of Conduct:
> > >
> > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2F
> > > > > do
> > >
> > > > > cs
> > >
> > > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&da
> > > > > ta
> > > > > =0
> > >
> > > > > 2%
> > >
> > > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204
> > > > > bc
> > > > > 2%
> > >
> > > > > 7C
> > >
> > > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&am
> > > > > p;
> > > > > sd
> > >
> > > > > at
> > >
> > > > > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%3D&reserved=0
> > >
> > > > > List Guidelines:
> > >
> > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2F
> > > > > fe
> > >
> > > > > do
> > >
> > > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%
> > > > > 7C
> > > > > mo
> > >
> > > > > te
> > >
> > > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e
> > > > > 2a
> > > > > 5b
> > >
> > > > > dd
> > >
> > > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdata=QUg
> > > > > cp
> > > > > i8
> > >
> > > > > 2T
> > >
> > > > > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%3D&reserved=0
> > >
> > > > > List Archives:
> > >
> > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2F
> > > > > li
> > >
> > > > > st
> > >
> > > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedora
> > > > > ho
> > > > > st
> > >
> > > > > ed
> > >
> > > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d
> > > > > 42
> > > > > c2
> > >
> > > > > ae
> > >
> > > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371
> > > > > 66
> > > > > 02
> > >
> > > > > 75
> > >
> > > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2B
> > > > > x4
> > > > > %3
> > >
> > > > > D&
> > >
> > > > > amp;reserved=0
> > >
> > > >
> > >
> > > > > _______________________________________________
> > >
> > > > > sssd-users mailing list --
> > > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedora
> > > > > ho
> > > > > sted.org> To
> > >
> > > > > unsubscribe send an email to
> > > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@
> > > > > li
> > > > > sts.fedorahosted.org>
> > >
> > > > > Fedora Code of Conduct:
> > >
> > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2F
> > > > > do
> > >
> > > > > cs
> > >
> > > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&da
> > > > > ta
> > > > > =0
> > >
> > > > > 2%
> > >
> > > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204
> > > > > bc
> > > > > 2%
> > >
> > > > > 7C
> > >
> > > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&am
> > > > > p;
> > > > > sd
> > >
> > > > > at
> > >
> > > > > a=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%3D&reserve
> > > > > d=
> > > > > 0
> > >
> > > > > List Guidelines:
> > >
> > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2F
> > > > > fe
> > >
> > > > > do
> > >
> > > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%
> > > > > 7C
> > > > > mo
> > >
> > > > > te
> > >
> > > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e
> > > > > 2a
> > > > > 5b
> > >
> > > > > dd
> > >
> > > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdata=CIJ
> > > > > al
> > > > > 5z
> > >
> > > > > 4E
> > >
> > > > > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%3D&reserved=0
> > >
> > > > > List Archives:
> > >
> > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2F
> > > > > li
> > >
> > > > > st
> > >
> > > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedora
> > > > > ho
> > > > > st
> > >
> > > > > ed
> > >
> > > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d
> > > > > 42
> > > > > c2
> > >
> > > > > ae
> > >
> > > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371
> > > > > 66
> > > > > 02
> > >
> > > > > 75
> > >
> > > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2B
> > > > > x4
> > > > > %3
> > >
> > > > > D&
> > >
> > > > > amp;reserved=0
> > >
> > > > _______________________________________________
> > >
> > > > sssd-users mailing list --
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > st
> > > > ed.org> To
> > >
> > > > unsubscribe send an email to
> > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@li
> > > > st
> > > > s.fedorahosted.org>
> > >
> > > > Fedora Code of Conduct:
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> > > > cs
> > >
> > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data
> > > > =0
> > > > 2%
> > >
> > > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b057603
> > > > 3%
> > > > 7C
> > >
> > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&
> > > > sd
> > > > at
> > >
> > > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0
> > >
> > > > List Guidelines:
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > fe
> > > > do
> > >
> > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C
> > > > mo
> > > > te
> > >
> > > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a
> > > > 5b
> > > > dd
> > >
> > > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkG
> > > > T3
> > > > GV
> > >
> > > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0
> > >
> > > > List Archives:
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > li
> > > > st
> > >
> > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedoraho
> > > > st
> > > > ed
> > >
> > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad5446
> > > > 7f
> > > > f9
> > >
> > > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171
> > > > 76
> > > > 16
> > >
> > > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3
> > > > D&
> > > > am
> > >
> > > > p;reserved=0
> > >
> > > > >> This message is from an external sender. Learn more about why
> > > > >> this <<
> > >
> > > > >> matters at https://links.utexas.edu/rtyclf. <<
> > >
> > > > _______________________________________________
> > >
> > > > sssd-users mailing list --
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > st
> > > > ed.org> To
> > >
> > > > unsubscribe send an email to
> > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@li
> > > > st
> > > > s.fedorahosted.org>
> > >
> > > > Fedora Code of Conduct:
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> > > > cs
> > >
> > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data
> > > > =0
> > > > 2%
> > >
> > > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b057603
> > > > 3%
> > > > 7C
> > >
> > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&
> > > > sd
> > > > at
> > >
> > > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0
> > >
> > > > List Guidelines:
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > fe
> > > > do
> > >
> > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C
> > > > mo
> > > > te
> > >
> > > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a
> > > > 5b
> > > > dd
> > >
> > > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkG
> > > > T3
> > > > GV
> > >
> > > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0
> > >
> > > > List Archives:
> > >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > li
> > > > st
> > >
> > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedoraho
> > > > st
> > > > ed
> > >
> > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad5446
> > > > 7f
> > > > f9
> > >
> > > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171
> > > > 76
> > > > 16
> > >
> > > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3
> > > > D&
> > > > am
> > >
> > > > p;reserved=0
> > >
> > > _______________________________________________
> > >
> > > sssd-users mailing list --
> > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahost
> > > ed .org> To unsubscribe send an email to
> > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.
> > > fedorahosted.org>
> > >
> > > Fedora Code of Conduct:
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > > cs
> > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > > 2%
> > > 7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%
> > > 7C
> > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172023246950934&sd
> > > at
> > > a=vSoy%2BB6PumDUGbPgpbIip%2F4NVQSev5zeLn5q6czf7Iw%3D&reserved=0
> > >
> > > List Guidelines:
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > > do
> > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo
> > > te
> > > r%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C31d7e2a5b
> > > dd
> > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172023246960925&sdata=zH1dfRZ
> > > EX
> > > 1IkkAWUBORT62TbdyCptLfFTR0LXj6YKAo%3D&reserved=0
> > >
> > > List Archives:
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > > ed
> > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b124220
> > > 0e
> > > 5908d7b0944929%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C63717202
> > > 32
> > > 46960925&sdata=9TGUHFXcI%2F%2B%2F8mbnbSrdiYYlghMPkddrwQ3jS%2FB%2
> > > BJ
> > > 1g%3D&reserved=0
> > >
> > > >> This message is from an external sender. Learn more about why
> > > >> this <<
> > >
> > > >> matters at https://links.utexas.edu/rtyclf. <<
> >
> > > _______________________________________________
> > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > > Fedora Code of Conduct:
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > > cs
> > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > > 2%
> > > 7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%
> > > 7C
> > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172023246960925&sd
> > > at
> > > a=9uSFPFkpIr5qK0W13Hes8pno8hu3WC0E1jqGkcCLTrQ%3D&reserved=0
> > > List Guidelines:
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > > do
> > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo
> > > te
> > > r%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C31d7e2a5b
> > > dd
> > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172023246960925&sdata=zH1dfRZ
> > > EX
> > > 1IkkAWUBORT62TbdyCptLfFTR0LXj6YKAo%3D&reserved=0
> > > List Archives:
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > > ed
> > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b124220
> > > 0e
> > > 5908d7b0944929%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C63717202
> > > 32
> > > 46960925&sdata=9TGUHFXcI%2F%2B%2F8mbnbSrdiYYlghMPkddrwQ3jS%2FB%2
> > > BJ
> > > 1g%3D&reserved=0
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7C1f2c72cd1e634f20436e08d7b097e7ed%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172038795857934&sdat
> > a=xsP01ReHvU%2Bb4iYB9RK9CUF%2FonjBnTHJVj8GWg04IcU%3D&reserved=0
> > List Guidelines:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7C1f2c72cd1e634f20436e08d7b097e7ed%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172038795857934&sdata=4z4neBp82
> > Pt0qXho9s8iV6z%2BHbor5Mk2YQKrKlLPI9s%3D&reserved=0
> > List Archives:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C1f2c72cd1e634f2043
> > 6e08d7b097e7ed%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371720387
> > 95857934&sdata=mRu15iYSrZKagsJs77178vKxa3A6aVq%2FIFzJIZo1jEE%3D&am
> > p;reserved=0
> > >> This message is from an external sender. Learn more about why this <<
> > >> matters at https://links.utexas.edu/rtyclf. <<
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7C1f2c72cd1e634f20436e08d7b097e7ed%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172038795857934&sdat
> > a=xsP01ReHvU%2Bb4iYB9RK9CUF%2FonjBnTHJVj8GWg04IcU%3D&reserved=0
> > List Guidelines:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7C1f2c72cd1e634f20436e08d7b097e7ed%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172038795857934&sdata=4z4neBp82
> > Pt0qXho9s8iV6z%2BHbor5Mk2YQKrKlLPI9s%3D&reserved=0
> > List Archives:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C1f2c72cd1e634f2043
> > 6e08d7b097e7ed%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371720387
> > 95867924&sdata=kZP%2BErxE13OEJzn7KkUeH%2B4kPR5j3%2B8E9iquHNJ8nb4%3
> > D&reserved=0
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
> List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
4 years, 2 months
- 1
- 0
Re: sssd 1.16.4. ADV190023.
by Sumit Bose
On Thu, Feb 13, 2020 at 03:10:31PM +0000, Mote, Todd wrote:
> Tangentially, GSS-SPNEGO isn't available on RHEL 6, correct?
Hi,
not not available in RHEL-6, iirc it was added in RHEL-7.2 or RHEL-7.3.
bye,
Sumit
>
> Todd
>
> -----Original Message-----
> From: Sumit Bose <sbose(a)redhat.com>
> Sent: Thursday, February 13, 2020 8:51 AM
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
>
> On Thu, Feb 13, 2020 at 01:42:33PM +0000, Mote, Todd wrote:
> > I'll work on getting that today. This is what I know so far.
> >
> >
> >
> > Test system updated through our Satellite, so nothing special or different. Yum updated everything:
> >
> > RHEL 7.7
> >
> > sssd-1.16.4-21.el7_7.1.x86_64
> >
> > adcli-0.8.1-9.el7.x86_64
> >
> >
> >
> > Domain:
> >
> > Windows Server 2016
> >
> > regkey ldapserverintegrity=2
> >
> > regkey ldapenforcechannelbinding=1
> >
> >
> >
> > we splunk our domain logs and my coworker wrote a dashboard to display the entries when either simple binds or unsigned sasl occur. Over the last 24 hours my test host triggered the unsigned sasl entry 13 times. Each entry corresponds precisely to the adcli check password attempt in the logs. It doesn't log an unsigned sasl event every hour, and a couple of times not at all for several hours. I'm not sure what's behind that. Times here are UTC -6. I’m in the 7:00 hour here. The most recent entry is below. I’ll work to get a trace running by the next hour, in case it logs it again.
>
> Hi,
>
> can you try to run the following ldapsearch commands and check which one causes a message in the event log?
>
> ldapsearch -H cldap://ad-server.ADTEST.domain.com -b '' -s base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon
>
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon
>
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s base
>
> kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM'
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSSAPI -b '' -s base
>
> kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM'
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSS-SPNEGO -b '' -s base
>
> bye,
> Sumit
>
> >
> >
> >
> > This behavior also happens with RHEL 8, sssd 2.2 and adcli 0.8.2. I see the same entries logged in both the sssd log on the device and the domain.
> >
> >
> > Timestamp<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-moni
> > toring/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20s
> > ource%3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%
> > 7C%20rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs
> > *Client%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPo
> > rt%3E%5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authentic
> > ate%20as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3
> > F%3CBindingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_tim
> > e%2C%20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dns
> > lookup%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20
> > FQDN%20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.22
> > 6%20%7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigne
> > d%20SASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Times
> > tamp%20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%
> > 22%2CUserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding
> > %20Type%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CF
> > QDN%2C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mod
> > e=smart&dispatch.sample_ratio=1&display.page.search.tab=statistics&dis
> > play.general.type=statistics&display.statistics.sortColumn=Timestamp&d
> > isplay.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01
> > FA-4F7E-929B-F56DE7E31D3B> User
> > Name<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitorin
> > g/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20source
> > %3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%7C%20
> > rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs*Clie
> > nt%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPort%3E
> > %5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authenticate%2
> > 0as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3F%3CB
> > indingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_time%2C%
> > 20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dnslooku
> > p%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20FQDN%
> > 20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.226%20%
> > 7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigned%20S
> > ASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Timestamp%
> > 20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%22%2C
> > UserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding%20Ty
> > pe%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CFQDN%2
> > C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mode=sma
> > rt&dispatch.sample_ratio=1&display.page.search.tab=statistics&display.
> > general.type=statistics&display.statistics.sortColumn=Timestamp&displa
> > y.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01FA-4F
> > 7E-929B-F56DE7E31D3B> Binding
> > Type<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitorin
> > g/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20source
> > %3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%7C%20
> > rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs*Clie
> > nt%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPort%3E
> > %5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authenticate%2
> > 0as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3F%3CB
> > indingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_time%2C%
> > 20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dnslooku
> > p%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20FQDN%
> > 20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.226%20%
> > 7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigned%20S
> > ASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Timestamp%
> > 20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%22%2C
> > UserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding%20Ty
> > pe%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CFQDN%2
> > C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mode=sma
> > rt&dispatch.sample_ratio=1&display.page.search.tab=statistics&display.
> > general.type=statistics&display.statistics.sortColumn=Timestamp&displa
> > y.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01FA-4F
> > 7E-929B-F56DE7E31D3B>
> > 02-13-2020 07:12:33
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 05:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 03:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 02:12:35
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 01:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 23:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 22:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 19:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 17:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 14:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 13:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 09:12:35
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 08:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> >
> >
> >
> >
> >
> > (Thu Feb 13 07:12:33 2020) [sssd[be[adtest.domain.com]]]
> > [ad_machine_account_password_renewal_done] (0x1000): --- adcli output
> > start---
> >
> > * Found realm in keytab: ADTEST.domain.com
> >
> > * Found computer name in keytab: ANTI-TEST
> >
> > * Found service principal in keytab: host/ANTI-TEST
> >
> > * Found service principal in keytab: host/anti-test.adtest.domain.com
> >
> > * Found host qualified name in keytab: anti-test.adtest.domain.com
> >
> > * Found service principal in keytab: RestrictedKrbHost/ANTI-TEST
> >
> > * Found service principal in keytab:
> > RestrictedKrbHost/anti-test.adtest.domain.com
> >
> > * Using fully qualified name: anti-test.adtest.domain.com
> >
> > * Using domain name: adtest.domain.com
> >
> > * Calculated computer account name from fqdn: ANTI-TEST
> >
> > * Using domain realm: adtest.domain.com
> >
> > * Sending netlogon pings to domain controller: cldap://
> > xxx.xxx.xxx.xxx
> >
> > * Received NetLogon info from: dc01a.adtest.domain.com
> >
> > * Wrote out krb5.conf snippet to
> > /tmp/adcli-krb5-RCmgmC/krb5.d/adcli-krb5-conf-vPdhBf
> >
> > * Authenticated as default/reset computer account: ANTI-TEST
> >
> > * Looked up short domain name: ADTEST
> >
> > * Looked up domain SID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx
> >
> > * Using fully qualified name: anti-test.adtest.domain.com
> >
> > * Using domain name: adtest.domain.com
> >
> > * Using computer account name: ANTI-TEST
> >
> > * Using domain realm: adtest.domain.com
> >
> > * Using fully qualified name: anti-test.adtest.domain.com
> >
> > * Enrolling computer name: ANTI-TEST
> >
> > * Generated 120 character computer password
> >
> > * Using keytab: FILE:/etc/krb5.keytab
> >
> > * Found computer account for ANTI-TEST$ at:
> > CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Departm
> > ents,DC=adtest,DC=domain,DC=com
> >
> > * Retrieved kvno '6' for computer account in directory:
> > CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Departm
> > ents,DC=adtest,DC=domain,DC=com
> >
> > * Password not too old, no change needed
> >
> > * Sending netlogon pings to domain controller: cldap://xxx.xxx.xxx.xxx
> >
> > * Received NetLogon info from: dc01a.adtest.domain.com
> >
> > * Checking RestrictedKrbHost/anti-test.adtest.domain.com
> >
> > * Added RestrictedKrbHost/anti-test.adtest.domain.com
> >
> > * Checking host/anti-test.adtest.domain.com
> >
> > * Added host/anti-test.adtest.domain.com
> >
> > * Checking RestrictedKrbHost/ANTI-TEST
> >
> > * Added RestrictedKrbHost/ANTI-TEST
> >
> > * Checking host/ANTI-TEST
> >
> > * Added host/ANTI-TEST
> >
> > ---adcli output end---
> >
> >
> >
> > Todd
> >
> >
> >
> > -----Original Message-----
> > From: Sumit Bose <sbose(a)redhat.com>
> > Sent: Thursday, February 13, 2020 1:36 AM
> > To: sssd-users(a)lists.fedorahosted.org
> > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> >
> >
> >
> > On Wed, Feb 12, 2020 at 01:11:14PM +0000, Mote, Todd wrote:
> >
> > > Sumit
> >
> > >
> >
> > > Any idea on when your SASL/GSS-SPNEGO patch for adcli might make it downstream? It seems that adcli is checking once an hour on the age of the password and is the only thing left on my test hosts that is triggering the Unsigned SASL event on our domain controllers. I have tinkered with the GSSAPI and other settings in ldap.conf, so none of the connections are simple, just unsigned, which isn't terrible, but it'd be nice to eliminate them altogether, ya know?
> >
> >
> >
> > Hi,
> >
> >
> >
> > they are planned for the next RHEL releases and I'm about to prepare Fedora packages.
> >
> >
> >
> > I did some tests with older RHEL7 versions and didn't come across issues even with only SASL/GSSAPI when I enforce channel binding and LDAP signing on AD. Would it be possible to send a network trace which covers the connection attempt of adcli which causes the issue?
> >
> >
> >
> > bye,
> >
> > Sumit
> >
> >
> >
> > >
> >
> > > Todd
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: Sumit Bose <sbose(a)redhat.com<mailto:sbose@redhat.com>>
> >
> > > Sent: Thursday, February 6, 2020 10:18 AM
> >
> > > To:
> > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahost
> > > ed.org>
> >
> > > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> >
> > >
> >
> > > On Thu, Feb 06, 2020 at 03:05:13PM +0000, Ondrej Valousek wrote:
> >
> > > > did you try refreshing the machine password in AD?Looks like it's too old.
> >
> > > > O.
> >
> > > > ________________________________
> >
> > > > From: David David <modrik(a)seznam.cz<mailto:modrik@seznam.cz>>
> >
> > > > Sent: Thursday, February 6, 2020 12:09 PM
> >
> > > > To:
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > sted.org>
> >
> > > > <sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorah
> > > > osted.org>>
> >
> > > > Subject: [SSSD-users] sssd 1.16.4. ADV190023.
> >
> > > >
> >
> > > > Hello,
> >
> > > > i guess that you probably heard about ADV190023. Our AD admin told me that linux servers which are under my responsibility send an unsigned request to AD, what could be a problem related to this incomming Ad patch: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport....
> >
> > > >
> >
> > > > I am using sssd in "sssd-ad mode." The communication between a linux servers and our AD is crypted by kerberos, so this should be ok.
> >
> > > >
> >
> > > > I found only one kind of request which could result in potential failure. After mentioned patching implementation. See please below:
> >
> > > >
> >
> > > > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_execute] (0x0400):
> >
> > > > Task [AD machine account password renewal]: executing task,
> > > > timeout
> >
> > > > 60 seconds (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]]
> > > > [be_ptask_done]
> >
> > > > (0x0400): Task [AD machine account password renewal]: finished
> >
> > > > successfully (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]]
> >
> > > > [be_ptask_schedule] (0x0400): Task [AD machine account password
> >
> > > > renewal]: scheduling task 86400 seconds from last
> >
> > >
> >
> > > Hi,
> >
> > >
> >
> > > Ondrej is right, those messages are related to adcli trying to
> > > update
> >
> > > the machine account password if it is too old. To check when the
> >
> > > password was last updated adcli uses LDAP with SASL/GSSAPI. I've
> > > added
> >
> > > a patch so that SASL/GSS-SPNEGO is used when it is available in the
> > > AD
> >
> > > DC side
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > tl
> >
> > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2Fa6f795ba3d6048b32d786
> > > 34
> >
> > > 68688bf7f42b2cafd&data=02%7C01%7Cmoter%40austin.utexas.edu%7C877
> > > 19
> >
> > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7
> > > C1
> >
> > > %7C637171761658405405&sdata=rPcG9mknHufVZUy6ege6n2vx%2B1Hy5XQhDn
> > > 7H
> >
> > > 8ugqlzA%3D&reserved=0 With SASL/GSS-SPNEGO all requirements are
> >
> > > negotiated automatically and signing should be switched on if required.
> >
> > >
> >
> > > With SASL/GSSAPI you might be able to tune this manually, see e.g. the SASL and GSSAPI options in man ldap.conf for details.
> >
> > >
> >
> > > There is also a patch for adcli which tells adcli to use ldaps
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > tl
> >
> > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2F85097245b57f190337225
> > > db
> >
> > > dbf6e33b58616c092&data=02%7C01%7Cmoter%40austin.utexas.edu%7C877
> > > 19
> >
> > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7
> > > C1
> >
> > > %7C637171761658405405&sdata=9dY6eOGTKimEYqydWbRFROldOTNRM16t1cae
> > > Uh
> >
> > > bBTiY%3D&reserved=0 but this is currently not used by SSSD. And
> > > in
> >
> > > general I think using GSS-SPNEGO is sufficient since there is no requirement to switch to ldaps (if I read the advisory correctly) and AD does not enable ldaps by default as well.
> >
> > >
> >
> > > bye,
> >
> > > Sumit
> >
> > >
> >
> > > >
> >
> > > > Everytime, this task is executed, our AD write into its log that an unsighned request came from my linux server. I tried to set ldap_tls_cert and ldap_tls_key into sssd.conf which point to the cert and key generated by our AD, but without success.
> >
> > > >
> >
> > > > I tried to find a proper solution how to sign the request that AD stop complaining, but nothing usefull found.
> >
> > > >
> >
> > > > My question is. Should I be affraid that after the patching, our AD will stop to communicate with my linux servers?
> >
> > > >
> >
> > > > Really thanks in advance for your answer. I really appreciate your effort.
> >
> > > > _______________________________________________
> >
> > > > sssd-users mailing list --
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > sted.org> To
> >
> > > > unsubscribe send an email to
> > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@li
> > > > sts.fedorahosted.org>
> >
> > > > Fedora Code of Conduct:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> >
> > > > cs
> >
> > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data
> > > > =0
> >
> > > > 2%
> >
> > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc
> > > > 2%
> >
> > > > 7C
> >
> > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&
> > > > sd
> >
> > > > at
> >
> > > > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%3D&reserved=0
> >
> > > > List Guidelines:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > fe
> >
> > > > do
> >
> > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C
> > > > mo
> >
> > > > te
> >
> > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a
> > > > 5b
> >
> > > > dd
> >
> > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdata=QUgcp
> > > > i8
> >
> > > > 2T
> >
> > > > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%3D&reserved=0
> >
> > > > List Archives:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > li
> >
> > > > st
> >
> > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedoraho
> > > > st
> >
> > > > ed
> >
> > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42
> > > > c2
> >
> > > > ae
> >
> > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166
> > > > 02
> >
> > > > 75
> >
> > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4
> > > > %3
> >
> > > > D&
> >
> > > > amp;reserved=0
> >
> > >
> >
> > > > _______________________________________________
> >
> > > > sssd-users mailing list --
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > sted.org> To
> >
> > > > unsubscribe send an email to
> > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@li
> > > > sts.fedorahosted.org>
> >
> > > > Fedora Code of Conduct:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> >
> > > > cs
> >
> > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data
> > > > =0
> >
> > > > 2%
> >
> > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc
> > > > 2%
> >
> > > > 7C
> >
> > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&
> > > > sd
> >
> > > > at
> >
> > > > a=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%3D&reserved=
> > > > 0
> >
> > > > List Guidelines:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > fe
> >
> > > > do
> >
> > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C
> > > > mo
> >
> > > > te
> >
> > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a
> > > > 5b
> >
> > > > dd
> >
> > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdata=CIJal
> > > > 5z
> >
> > > > 4E
> >
> > > > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%3D&reserved=0
> >
> > > > List Archives:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > li
> >
> > > > st
> >
> > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedoraho
> > > > st
> >
> > > > ed
> >
> > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42
> > > > c2
> >
> > > > ae
> >
> > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166
> > > > 02
> >
> > > > 75
> >
> > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4
> > > > %3
> >
> > > > D&
> >
> > > > amp;reserved=0
> >
> > > _______________________________________________
> >
> > > sssd-users mailing list --
> > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahost
> > > ed.org> To
> >
> > > unsubscribe send an email to
> > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@list
> > > s.fedorahosted.org>
> >
> > > Fedora Code of Conduct:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > > cs
> >
> > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > > 2%
> >
> > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%
> > > 7C
> >
> > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sd
> > > at
> >
> > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0
> >
> > > List Guidelines:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > > do
> >
> > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo
> > > te
> >
> > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5b
> > > dd
> >
> > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3
> > > GV
> >
> > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0
> >
> > > List Archives:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> >
> > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > > ed
> >
> > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467f
> > > f9
> >
> > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C63717176
> > > 16
> >
> > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3D&
> > > am
> >
> > > p;reserved=0
> >
> > > >> This message is from an external sender. Learn more about why
> > > >> this <<
> >
> > > >> matters at https://links.utexas.edu/rtyclf. <<
> >
> > > _______________________________________________
> >
> > > sssd-users mailing list --
> > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahost
> > > ed.org> To
> >
> > > unsubscribe send an email to
> > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@list
> > > s.fedorahosted.org>
> >
> > > Fedora Code of Conduct:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > > cs
> >
> > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > > 2%
> >
> > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%
> > > 7C
> >
> > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sd
> > > at
> >
> > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0
> >
> > > List Guidelines:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > > do
> >
> > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo
> > > te
> >
> > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5b
> > > dd
> >
> > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3
> > > GV
> >
> > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0
> >
> > > List Archives:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> >
> > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > > ed
> >
> > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467f
> > > f9
> >
> > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C63717176
> > > 16
> >
> > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3D&
> > > am
> >
> > > p;reserved=0
> >
> > _______________________________________________
> >
> > sssd-users mailing list --
> > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted
> > .org> To unsubscribe send an email to
> > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.
> > fedorahosted.org>
> >
> > Fedora Code of Conduct:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172023246950934&sdat
> > a=vSoy%2BB6PumDUGbPgpbIip%2F4NVQSev5zeLn5q6czf7Iw%3D&reserved=0
> >
> > List Guidelines:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172023246960925&sdata=zH1dfRZEX
> > 1IkkAWUBORT62TbdyCptLfFTR0LXj6YKAo%3D&reserved=0
> >
> > List Archives:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e
> > 5908d7b0944929%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371720232
> > 46960925&sdata=9TGUHFXcI%2F%2B%2F8mbnbSrdiYYlghMPkddrwQ3jS%2FB%2BJ
> > 1g%3D&reserved=0
> >
> > >> This message is from an external sender. Learn more about why this
> > >> <<
> >
> > >> matters at https://links.utexas.edu/rtyclf. <<
>
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172023246960925&sdat
> > a=9uSFPFkpIr5qK0W13Hes8pno8hu3WC0E1jqGkcCLTrQ%3D&reserved=0
> > List Guidelines:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172023246960925&sdata=zH1dfRZEX
> > 1IkkAWUBORT62TbdyCptLfFTR0LXj6YKAo%3D&reserved=0
> > List Archives:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e
> > 5908d7b0944929%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371720232
> > 46960925&sdata=9TGUHFXcI%2F%2B%2F8mbnbSrdiYYlghMPkddrwQ3jS%2FB%2BJ
> > 1g%3D&reserved=0
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
> List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
4 years, 2 months
- 2
- 1
Re: sssd 1.16.4. ADV190023.
by Sumit Bose
On Thu, Feb 13, 2020 at 03:02:59PM +0000, Mote, Todd wrote:
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSSAPI -b '' -s base
Hi,
all the other ldapsearch commands caused no message?
What is the number shown after 'SASL SSF:' in the output of the
ldapsearch from above?
Can you send a network trace covering the ldapsearch from above?
bye,
Sumit
>
> causes this event
>
> 02/13/2020 08:59:28 AM
> LogName=Directory Service
> SourceName=Microsoft-Windows-ActiveDirectory_DomainService
> EventCode=2889
> EventType=4
> Type=Information
> ComputerName=dc.adtest.domain.com
> User=ANONYMOUS LOGON
> Sid=S-1-5-7
> SidType=5
> TaskCategory=LDAP Interface
> OpCode=The operation completed successfully.
> RecordNumber=247387
> Keywords=Classic
> Message=The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.
>
> Client IP address:
> xxx.xxx.xxx.xxx:47824
> Identity the client attempted to authenticate as:
> ADTEST\ANTI-TEST$
> Binding Type:
> 0
>
> -----Original Message-----
> From: Sumit Bose <sbose(a)redhat.com>
> Sent: Thursday, February 13, 2020 8:51 AM
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
>
> On Thu, Feb 13, 2020 at 01:42:33PM +0000, Mote, Todd wrote:
> > I'll work on getting that today. This is what I know so far.
> >
> >
> >
> > Test system updated through our Satellite, so nothing special or different. Yum updated everything:
> >
> > RHEL 7.7
> >
> > sssd-1.16.4-21.el7_7.1.x86_64
> >
> > adcli-0.8.1-9.el7.x86_64
> >
> >
> >
> > Domain:
> >
> > Windows Server 2016
> >
> > regkey ldapserverintegrity=2
> >
> > regkey ldapenforcechannelbinding=1
> >
> >
> >
> > we splunk our domain logs and my coworker wrote a dashboard to display the entries when either simple binds or unsigned sasl occur. Over the last 24 hours my test host triggered the unsigned sasl entry 13 times. Each entry corresponds precisely to the adcli check password attempt in the logs. It doesn't log an unsigned sasl event every hour, and a couple of times not at all for several hours. I'm not sure what's behind that. Times here are UTC -6. I’m in the 7:00 hour here. The most recent entry is below. I’ll work to get a trace running by the next hour, in case it logs it again.
>
> Hi,
>
> can you try to run the following ldapsearch commands and check which one causes a message in the event log?
>
> ldapsearch -H cldap://ad-server.ADTEST.domain.com -b '' -s base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon
>
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon
>
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s base
>
> kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM'
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSSAPI -b '' -s base
>
> kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM'
> ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSS-SPNEGO -b '' -s base
>
> bye,
> Sumit
>
> >
> >
> >
> > This behavior also happens with RHEL 8, sssd 2.2 and adcli 0.8.2. I see the same entries logged in both the sssd log on the device and the domain.
> >
> >
> > Timestamp<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-moni
> > toring/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20s
> > ource%3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%
> > 7C%20rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs
> > *Client%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPo
> > rt%3E%5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authentic
> > ate%20as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3
> > F%3CBindingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_tim
> > e%2C%20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dns
> > lookup%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20
> > FQDN%20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.22
> > 6%20%7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigne
> > d%20SASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Times
> > tamp%20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%
> > 22%2CUserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding
> > %20Type%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CF
> > QDN%2C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mod
> > e=smart&dispatch.sample_ratio=1&display.page.search.tab=statistics&dis
> > play.general.type=statistics&display.statistics.sortColumn=Timestamp&d
> > isplay.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01
> > FA-4F7E-929B-F56DE7E31D3B> User
> > Name<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitorin
> > g/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20source
> > %3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%7C%20
> > rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs*Clie
> > nt%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPort%3E
> > %5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authenticate%2
> > 0as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3F%3CB
> > indingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_time%2C%
> > 20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dnslooku
> > p%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20FQDN%
> > 20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.226%20%
> > 7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigned%20S
> > ASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Timestamp%
> > 20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%22%2C
> > UserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding%20Ty
> > pe%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CFQDN%2
> > C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mode=sma
> > rt&dispatch.sample_ratio=1&display.page.search.tab=statistics&display.
> > general.type=statistics&display.statistics.sortColumn=Timestamp&displa
> > y.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01FA-4F
> > 7E-929B-F56DE7E31D3B> Binding
> > Type<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitorin
> > g/search?earliest=-24h%40h&latest=now&q=search%20%60ADlogs%60%20source
> > %3D%22WinEventLog%3ADirectory%20Service%22%20EventCode%3D2889%20%7C%20
> > rex%20field%3DMessage%20%22(%3Fs)%5E(%3F%3CeMessage%3E.*%5C.)%5Cs*Clie
> > nt%20IP%20address%3A%5Cs*(%3F%3CClientIPAddress%3E.*)%3A(%3F%3CPort%3E
> > %5Cd%2B)%5Cs*Identity%20the%20client%20attempted%20to%20authenticate%2
> > 0as%3A%5Cs*(%3F%3CUserName%3E%5CS*)%5Cs*Binding%20Type%3A%5Cs*(%3F%3CB
> > indingType%3E%5Cd)%24%22%20%7C%20eval%20Timestamp%3Dstrftime(_time%2C%
> > 20%22%25m-%25d-%25Y%20%25H%3A%25M%3A%25S%22)%20%7C%20lookup%20dnslooku
> > p%20clientip%20as%20ClientIPAddress%20OUTPUT%20clienthost%20as%20FQDN%
> > 20%7C%20search%20BindingType%3D*%20ClientIPAddress%3D146.6.182.226%20%
> > 7C%20%20eval%20BindingType%3Dcase(BindingType%3D%3D0%2C%22Unsigned%20S
> > ASL%22%2CBindingType%3D%3D1%2C%22Simple%22)%20%7C%20sort%20-Timestamp%
> > 20%7C%20rename%20ClientIPAddress%20as%20%22Client%20IP%20Address%22%2C
> > UserName%20as%20%22User%20Name%22%2CBindingType%20as%20%22Binding%20Ty
> > pe%22%20%7C%20table%20Timestamp%2C%22Client%20IP%20Address%22%2CFQDN%2
> > C%22User%20Name%22%2C%22Binding%20Type%22&display.page.search.mode=sma
> > rt&dispatch.sample_ratio=1&display.page.search.tab=statistics&display.
> > general.type=statistics&display.statistics.sortColumn=Timestamp&displa
> > y.statistics.sortDirection=desc&sid=1581600147.468973_8220FB8F-01FA-4F
> > 7E-929B-F56DE7E31D3B>
> > 02-13-2020 07:12:33
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 05:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 03:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 02:12:35
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-13-2020 01:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 23:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 22:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 19:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 17:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 14:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 13:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 09:12:35
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> > 02-12-2020 08:12:34
> > ADTEST\ANTI-TEST$
> > Unsigned SASL
> >
> >
> >
> >
> >
> > (Thu Feb 13 07:12:33 2020) [sssd[be[adtest.domain.com]]]
> > [ad_machine_account_password_renewal_done] (0x1000): --- adcli output
> > start---
> >
> > * Found realm in keytab: ADTEST.domain.com
> >
> > * Found computer name in keytab: ANTI-TEST
> >
> > * Found service principal in keytab: host/ANTI-TEST
> >
> > * Found service principal in keytab: host/anti-test.adtest.domain.com
> >
> > * Found host qualified name in keytab: anti-test.adtest.domain.com
> >
> > * Found service principal in keytab: RestrictedKrbHost/ANTI-TEST
> >
> > * Found service principal in keytab:
> > RestrictedKrbHost/anti-test.adtest.domain.com
> >
> > * Using fully qualified name: anti-test.adtest.domain.com
> >
> > * Using domain name: adtest.domain.com
> >
> > * Calculated computer account name from fqdn: ANTI-TEST
> >
> > * Using domain realm: adtest.domain.com
> >
> > * Sending netlogon pings to domain controller: cldap://
> > xxx.xxx.xxx.xxx
> >
> > * Received NetLogon info from: dc01a.adtest.domain.com
> >
> > * Wrote out krb5.conf snippet to
> > /tmp/adcli-krb5-RCmgmC/krb5.d/adcli-krb5-conf-vPdhBf
> >
> > * Authenticated as default/reset computer account: ANTI-TEST
> >
> > * Looked up short domain name: ADTEST
> >
> > * Looked up domain SID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx
> >
> > * Using fully qualified name: anti-test.adtest.domain.com
> >
> > * Using domain name: adtest.domain.com
> >
> > * Using computer account name: ANTI-TEST
> >
> > * Using domain realm: adtest.domain.com
> >
> > * Using fully qualified name: anti-test.adtest.domain.com
> >
> > * Enrolling computer name: ANTI-TEST
> >
> > * Generated 120 character computer password
> >
> > * Using keytab: FILE:/etc/krb5.keytab
> >
> > * Found computer account for ANTI-TEST$ at:
> > CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Departm
> > ents,DC=adtest,DC=domain,DC=com
> >
> > * Retrieved kvno '6' for computer account in directory:
> > CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Departm
> > ents,DC=adtest,DC=domain,DC=com
> >
> > * Password not too old, no change needed
> >
> > * Sending netlogon pings to domain controller: cldap://xxx.xxx.xxx.xxx
> >
> > * Received NetLogon info from: dc01a.adtest.domain.com
> >
> > * Checking RestrictedKrbHost/anti-test.adtest.domain.com
> >
> > * Added RestrictedKrbHost/anti-test.adtest.domain.com
> >
> > * Checking host/anti-test.adtest.domain.com
> >
> > * Added host/anti-test.adtest.domain.com
> >
> > * Checking RestrictedKrbHost/ANTI-TEST
> >
> > * Added RestrictedKrbHost/ANTI-TEST
> >
> > * Checking host/ANTI-TEST
> >
> > * Added host/ANTI-TEST
> >
> > ---adcli output end---
> >
> >
> >
> > Todd
> >
> >
> >
> > -----Original Message-----
> > From: Sumit Bose <sbose(a)redhat.com>
> > Sent: Thursday, February 13, 2020 1:36 AM
> > To: sssd-users(a)lists.fedorahosted.org
> > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> >
> >
> >
> > On Wed, Feb 12, 2020 at 01:11:14PM +0000, Mote, Todd wrote:
> >
> > > Sumit
> >
> > >
> >
> > > Any idea on when your SASL/GSS-SPNEGO patch for adcli might make it downstream? It seems that adcli is checking once an hour on the age of the password and is the only thing left on my test hosts that is triggering the Unsigned SASL event on our domain controllers. I have tinkered with the GSSAPI and other settings in ldap.conf, so none of the connections are simple, just unsigned, which isn't terrible, but it'd be nice to eliminate them altogether, ya know?
> >
> >
> >
> > Hi,
> >
> >
> >
> > they are planned for the next RHEL releases and I'm about to prepare Fedora packages.
> >
> >
> >
> > I did some tests with older RHEL7 versions and didn't come across issues even with only SASL/GSSAPI when I enforce channel binding and LDAP signing on AD. Would it be possible to send a network trace which covers the connection attempt of adcli which causes the issue?
> >
> >
> >
> > bye,
> >
> > Sumit
> >
> >
> >
> > >
> >
> > > Todd
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: Sumit Bose <sbose(a)redhat.com<mailto:sbose@redhat.com>>
> >
> > > Sent: Thursday, February 6, 2020 10:18 AM
> >
> > > To:
> > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahost
> > > ed.org>
> >
> > > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
> >
> > >
> >
> > > On Thu, Feb 06, 2020 at 03:05:13PM +0000, Ondrej Valousek wrote:
> >
> > > > did you try refreshing the machine password in AD?Looks like it's too old.
> >
> > > > O.
> >
> > > > ________________________________
> >
> > > > From: David David <modrik(a)seznam.cz<mailto:modrik@seznam.cz>>
> >
> > > > Sent: Thursday, February 6, 2020 12:09 PM
> >
> > > > To:
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > sted.org>
> >
> > > > <sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorah
> > > > osted.org>>
> >
> > > > Subject: [SSSD-users] sssd 1.16.4. ADV190023.
> >
> > > >
> >
> > > > Hello,
> >
> > > > i guess that you probably heard about ADV190023. Our AD admin told me that linux servers which are under my responsibility send an unsigned request to AD, what could be a problem related to this incomming Ad patch: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport....
> >
> > > >
> >
> > > > I am using sssd in "sssd-ad mode." The communication between a linux servers and our AD is crypted by kerberos, so this should be ok.
> >
> > > >
> >
> > > > I found only one kind of request which could result in potential failure. After mentioned patching implementation. See please below:
> >
> > > >
> >
> > > > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_execute] (0x0400):
> >
> > > > Task [AD machine account password renewal]: executing task,
> > > > timeout
> >
> > > > 60 seconds (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]]
> > > > [be_ptask_done]
> >
> > > > (0x0400): Task [AD machine account password renewal]: finished
> >
> > > > successfully (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]]
> >
> > > > [be_ptask_schedule] (0x0400): Task [AD machine account password
> >
> > > > renewal]: scheduling task 86400 seconds from last
> >
> > >
> >
> > > Hi,
> >
> > >
> >
> > > Ondrej is right, those messages are related to adcli trying to
> > > update
> >
> > > the machine account password if it is too old. To check when the
> >
> > > password was last updated adcli uses LDAP with SASL/GSSAPI. I've
> > > added
> >
> > > a patch so that SASL/GSS-SPNEGO is used when it is available in the
> > > AD
> >
> > > DC side
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > tl
> >
> > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2Fa6f795ba3d6048b32d786
> > > 34
> >
> > > 68688bf7f42b2cafd&data=02%7C01%7Cmoter%40austin.utexas.edu%7C877
> > > 19
> >
> > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7
> > > C1
> >
> > > %7C637171761658405405&sdata=rPcG9mknHufVZUy6ege6n2vx%2B1Hy5XQhDn
> > > 7H
> >
> > > 8ugqlzA%3D&reserved=0 With SASL/GSS-SPNEGO all requirements are
> >
> > > negotiated automatically and signing should be switched on if required.
> >
> > >
> >
> > > With SASL/GSSAPI you might be able to tune this manually, see e.g. the SASL and GSSAPI options in man ldap.conf for details.
> >
> > >
> >
> > > There is also a patch for adcli which tells adcli to use ldaps
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > tl
> >
> > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2F85097245b57f190337225
> > > db
> >
> > > dbf6e33b58616c092&data=02%7C01%7Cmoter%40austin.utexas.edu%7C877
> > > 19
> >
> > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7
> > > C1
> >
> > > %7C637171761658405405&sdata=9dY6eOGTKimEYqydWbRFROldOTNRM16t1cae
> > > Uh
> >
> > > bBTiY%3D&reserved=0 but this is currently not used by SSSD. And
> > > in
> >
> > > general I think using GSS-SPNEGO is sufficient since there is no requirement to switch to ldaps (if I read the advisory correctly) and AD does not enable ldaps by default as well.
> >
> > >
> >
> > > bye,
> >
> > > Sumit
> >
> > >
> >
> > > >
> >
> > > > Everytime, this task is executed, our AD write into its log that an unsighned request came from my linux server. I tried to set ldap_tls_cert and ldap_tls_key into sssd.conf which point to the cert and key generated by our AD, but without success.
> >
> > > >
> >
> > > > I tried to find a proper solution how to sign the request that AD stop complaining, but nothing usefull found.
> >
> > > >
> >
> > > > My question is. Should I be affraid that after the patching, our AD will stop to communicate with my linux servers?
> >
> > > >
> >
> > > > Really thanks in advance for your answer. I really appreciate your effort.
> >
> > > > _______________________________________________
> >
> > > > sssd-users mailing list --
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > sted.org> To
> >
> > > > unsubscribe send an email to
> > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@li
> > > > sts.fedorahosted.org>
> >
> > > > Fedora Code of Conduct:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> >
> > > > cs
> >
> > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data
> > > > =0
> >
> > > > 2%
> >
> > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc
> > > > 2%
> >
> > > > 7C
> >
> > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&
> > > > sd
> >
> > > > at
> >
> > > > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%3D&reserved=0
> >
> > > > List Guidelines:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > fe
> >
> > > > do
> >
> > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C
> > > > mo
> >
> > > > te
> >
> > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a
> > > > 5b
> >
> > > > dd
> >
> > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdata=QUgcp
> > > > i8
> >
> > > > 2T
> >
> > > > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%3D&reserved=0
> >
> > > > List Archives:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > li
> >
> > > > st
> >
> > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedoraho
> > > > st
> >
> > > > ed
> >
> > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42
> > > > c2
> >
> > > > ae
> >
> > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166
> > > > 02
> >
> > > > 75
> >
> > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4
> > > > %3
> >
> > > > D&
> >
> > > > amp;reserved=0
> >
> > >
> >
> > > > _______________________________________________
> >
> > > > sssd-users mailing list --
> > > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedoraho
> > > > sted.org> To
> >
> > > > unsubscribe send an email to
> > > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@li
> > > > sts.fedorahosted.org>
> >
> > > > Fedora Code of Conduct:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> >
> > > > cs
> >
> > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data
> > > > =0
> >
> > > > 2%
> >
> > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc
> > > > 2%
> >
> > > > 7C
> >
> > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&
> > > > sd
> >
> > > > at
> >
> > > > a=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%3D&reserved=
> > > > 0
> >
> > > > List Guidelines:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > fe
> >
> > > > do
> >
> > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C
> > > > mo
> >
> > > > te
> >
> > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a
> > > > 5b
> >
> > > > dd
> >
> > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdata=CIJal
> > > > 5z
> >
> > > > 4E
> >
> > > > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%3D&reserved=0
> >
> > > > List Archives:
> >
> > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > li
> >
> > > > st
> >
> > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedoraho
> > > > st
> >
> > > > ed
> >
> > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42
> > > > c2
> >
> > > > ae
> >
> > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166
> > > > 02
> >
> > > > 75
> >
> > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4
> > > > %3
> >
> > > > D&
> >
> > > > amp;reserved=0
> >
> > > _______________________________________________
> >
> > > sssd-users mailing list --
> > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahost
> > > ed.org> To
> >
> > > unsubscribe send an email to
> > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@list
> > > s.fedorahosted.org>
> >
> > > Fedora Code of Conduct:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > > cs
> >
> > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > > 2%
> >
> > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%
> > > 7C
> >
> > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sd
> > > at
> >
> > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0
> >
> > > List Guidelines:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > > do
> >
> > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo
> > > te
> >
> > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5b
> > > dd
> >
> > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3
> > > GV
> >
> > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0
> >
> > > List Archives:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> >
> > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > > ed
> >
> > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467f
> > > f9
> >
> > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C63717176
> > > 16
> >
> > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3D&
> > > am
> >
> > > p;reserved=0
> >
> > > >> This message is from an external sender. Learn more about why
> > > >> this <<
> >
> > > >> matters at https://links.utexas.edu/rtyclf. <<
> >
> > > _______________________________________________
> >
> > > sssd-users mailing list --
> > > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahost
> > > ed.org> To
> >
> > > unsubscribe send an email to
> > > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@list
> > > s.fedorahosted.org>
> >
> > > Fedora Code of Conduct:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > > cs
> >
> > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > > 2%
> >
> > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%
> > > 7C
> >
> > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sd
> > > at
> >
> > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0
> >
> > > List Guidelines:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > > do
> >
> > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo
> > > te
> >
> > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5b
> > > dd
> >
> > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3
> > > GV
> >
> > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0
> >
> > > List Archives:
> >
> > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> >
> > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > > ed
> >
> > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467f
> > > f9
> >
> > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C63717176
> > > 16
> >
> > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3D&
> > > am
> >
> > > p;reserved=0
> >
> > _______________________________________________
> >
> > sssd-users mailing list --
> > sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted
> > .org> To unsubscribe send an email to
> > sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.
> > fedorahosted.org>
> >
> > Fedora Code of Conduct:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172023246950934&sdat
> > a=vSoy%2BB6PumDUGbPgpbIip%2F4NVQSev5zeLn5q6czf7Iw%3D&reserved=0
> >
> > List Guidelines:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172023246960925&sdata=zH1dfRZEX
> > 1IkkAWUBORT62TbdyCptLfFTR0LXj6YKAo%3D&reserved=0
> >
> > List Archives:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e
> > 5908d7b0944929%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371720232
> > 46960925&sdata=9TGUHFXcI%2F%2B%2F8mbnbSrdiYYlghMPkddrwQ3jS%2FB%2BJ
> > 1g%3D&reserved=0
> >
> > >> This message is from an external sender. Learn more about why this
> > >> <<
> >
> > >> matters at https://links.utexas.edu/rtyclf. <<
>
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172023246960925&sdat
> > a=9uSFPFkpIr5qK0W13Hes8pno8hu3WC0E1jqGkcCLTrQ%3D&reserved=0
> > List Guidelines:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7C282ee4414b1242200e5908d7b0944929%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C1%7C637172023246960925&sdata=zH1dfRZEX
> > 1IkkAWUBORT62TbdyCptLfFTR0LXj6YKAo%3D&reserved=0
> > List Archives:
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C282ee4414b1242200e
> > 5908d7b0944929%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371720232
> > 46960925&sdata=9TGUHFXcI%2F%2B%2F8mbnbSrdiYYlghMPkddrwQ3jS%2FB%2BJ
> > 1g%3D&reserved=0
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
> List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
4 years, 2 months
- 2
- 1