February 2020 - sssd-users - Fedora mailing-lists

SSSD.Service not starting
by Manjot Singh 12 Feb '25

12 Feb '25

● sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2020-01-29 14:12:32 EST; 9s ago Process: 23217 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4) Main PID: 23217 (code=exited, status=4) Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Service RestartSec=100ms expired, scheduling restart. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Scheduled restart job, restart counter is at 5. Jan 29 14:12:32 pop-os systemd[1]: Stopped System Security Services Daemon. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Start request repeated too quickly. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Failed with result 'exit-code'. Jan 29 14:12:32 pop-os systemd[1]: Failed to start System Security Services Daemon.

3 2

sssd performance on large domains
by zfnoctis＠gmail.com 03 Feb '22

03 Feb '22

Hi, I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases. Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment. Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows. Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems. I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways. Thanks for your time.

6 29

ID Views for IPA ID Views for AD users inconsistent resolution
by Louis Abel 01 Aug '21

01 Aug '21

I didn't get a response in #sssd, so I figured I'll try here at the mail list. # rpm -q sssd ipa-server sssd-1.16.0-19.el7_5.5.x86_64 ipa-server-4.5.4-10.el7_5.3.x86_64 I've been scratching my head trying to resolve this particular issue. I'm having issues with AD users where when they login, they'll get the UID/GID assigned in the ID views correctly, but only some of the time. Other times, they won't get the id view assigned to them. This is all done in the default trust view. What makes this issue even more interesting is that out of my 6 domain controllers, sometimes it'll be one server out of the six that does it, sometimes it's two. But it's never the same ones, so it's difficult to track the particular issue down. What's even more interesting is this is not occurring with some users (like my own). I have yet to see it occur with my account or even the rest of my team's accounts. One of the things I tried to do is delete the ID views of the offending users and recreate them to no avail. I put SSSD into debug mode on the IPA servers and tried to get some relevant logs and such to try and figure this out. Below is my SSSD configuration, ldb info, and debug logs (removing private information where possible). I'm trying to determine if this is either a bug within SSSD or if this is a misconfiguration on my part. $ ldbsearch -H cache_ipa.example.com.ldb name=user.name(a)ad.example.com originalADuidNumber uidNumber originalADgidNumber gidNumber asq: Unable to register control with rootdse! # record 1 dn: name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb originalADuidNumber: 55616902 originalADgidNumber: 55616902 uidNumber: 55616902 gidNumber: 55616902 $ ipa idoverrideuser-show "Default Trust View" user.name(a)ad.example.com Anchor to override: user.name(a)ad.example.com UID: 40001 GID: 40001 Home directory: /home/user.name Login shell: /bin/bash $ ldbsearch -H timestamps_ipa.example.com.ldb | less dn: name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb objectCategory: user originalModifyTimestamp: 20180823172515.0Z entryUSN: 92632390 initgrExpireTimestamp: 1535133621 lastUpdate: 1535128235 dataExpireTimestamp: 1535133635 distinguishedName: name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb ## DEBUG LOGS (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_set_entry_attr] (0x0200): Entry [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] has set [ts_cache] attrs. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-16902))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_print_server] (0x2000): Searching 172.20.23.190:389 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-16902))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=chotel,dc=com]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 32 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 32 timeout 6 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1080], connected[1], ops[(nil)], ldap[0x55f30a5d0f90] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a645310], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [ipaanchoruuid=:SID:S-1-5-21-922099545-2851689246-2917073205-16902,cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=chotel,dc=com]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [loginShell] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uidNumber] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [homeDirectory] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaOriginalUid] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a645310], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 32 finished (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_done] (0x4000): Found override for object with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-16902))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [uidNumber] with [40001] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x0080): Override attribute for [gidNumber] has more [2] than one value, using only the first. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [gidNumber] with [40001] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [homeDirectory] with [/home/user.name] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [loginShell] with [/bin/bash] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a6819a0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a681a60 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a6819a0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a681a60 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a6819a0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [safe_original_attributes] (0x4000): Original object does not have [sshPublicKey] set. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a683c50 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a683d10 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a683c50 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a683d10 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a683c50 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [uidNumber] of entry [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a68d1c0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a68d280 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a68d1c0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a68d280 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a68d1c0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_set_entry_attr] (0x0200): Entry [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] has set [cache, ts_cache] attrs. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a68d330 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a688900 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a68d330 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a689320 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a6893e0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a688900 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a68d330 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a689320 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a634920 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a6349e0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a6893e0 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a689320 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a634920 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a6349e0 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a634920 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_initgr_get_overrides_step] (0x1000): Processing group 0/1 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_initgr_get_overrides_step] (0x1000): Fetching group S-1-5-21-922099545-2851689246-2917073205-20676 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-20676))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_print_server] (0x2000): Searching 172.20.23.190:389 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-20676))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=chotel,dc=com]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 33 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 33 timeout 6 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a63f270], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a63f270], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 33 finished (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-20676))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_initgr_get_overrides_step] (0x1000): Processing group 1/1 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_memberships_send] (0x0400): External group information still valid. ## /etc/sssd/sssd.conf [domain/ipa.example.com] cache_credentials = True krb5_store_password_if_offline = True # krb5_realm = IPA.EXAMPLE.COM ipa_domain = ipa.example.com ipa_hostname = entl01.ipa.example.com # Server Specific Settings ipa_server = entl01.ipa.example.com ipa_server_mode = True subdomain_homedir = %o fallback_homedir = /home/%u default_shell = /bin/bash id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh domains = ipa.example.com [nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd,tomcat,activemq,informix,oracle,xdba,grid,dbadmin,weblogic,operator,postgres,devolog memcache_timeout = 600 homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp]

2 1

sssd-krb5, krb5_ccachedir, DIR-cache-store...
by Jostein Fossheim 15 Dec '20

15 Dec '20

We are working with several kerberos-REALMS and are trying to get our clients to store their kerberos tickets in a DIRECTORY. This seems to work nicely for clients not authenticating at login, with the following configuration set in /etc/krb5.conf. ... [libdefaults] ... default_ccache_name = DIR:/tmp/krb5cc_%{uid} ... user@server:~$ klist Ticket cache: DIR::/tmp/krb5cc_888/tkt Default principal: user@REALM Valid starting Expires Service principal 09/22/19 17:35:50 09/23/19 17:35:48 krbtgt/user@REALM Each ticket is stored in a separate file. For clients using sssd for login, I want to set up the same behavior. But when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here the directory don't get the excutable bit set (that is the directory get 0600-permission), and the login fails. In the man-page from Debian-buster (sssd-version: 1.16.3), there are to settings that seems to regulate this behaviour : krb5_ccachedir (string) Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700. Default: /tmp krb5_ccname_template (string) Location of the user's credential cache. Three credential cache types are currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be specified either as TYPE:RESIDUAL, or as an absolute path, which implies the "FILE" type. In the template, the following sequences are substituted: [...] If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way. When using KEYRING types, the only supported mechanism is "KEYRING:persistent:%U", which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method. The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf. NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD. Default: (from libkrb5) ... I have tried to both set and unset, the two parameters in question like this: krb5_ccachedir = /tmp/krb5cc_%U krb5_ccname_template = DIR: %d krb5_ccname_template = DIR:%d/krb5cc_%U_XXXXXX But the configuration-options seems to be ignored, no matter what I do, and I have the same behavior: A non-executable directory is created and the user is unable to login. If I set the +x bit on the directory manually as the root-user, everything works.

4 5

sssd with samba
by Edouard Guigné 20 Nov '20

20 Nov '20

Dear sssd users, I would like to get informations about the use of sssd with samba (centos 7, samba 4.8.3). I need it because I configured a samba share, accessible with sssd. The authentication is against a windows AD. My /etc/nsswitch.cnf is configured only with sssd : /passwd: files sss// //shadow: files sss// //group: files sss/ For an other purpose, I set an sftpd access also configured with sssd against the AD. I followed some discussions on the samba user list about samba + sssd. I would like to understand if there are some issues with sssd and samba 4.8.3 on centos 7 ? Or is it with next RHEL 8 ? /The RHEL 8 documentation states this: // //// //"Red Hat only supports running Samba as a server with the winbindd // //service to provide domain users and groups to the local system. Due to // //certain limitations, such as missing Windows access control list (ACL) // //support and NT LAN Manager (NTLM) fallback, SSSD is not supported." // //// //https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers//// //// //What's confusing is that the RHEL 7 documentation says: // //// //"Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this // //functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer // //need to run Winbind and SSSD in parallel to access SMB shares. For // //example, accessing the Access Control Lists (ACLs) no longer requires // //Winbind on SSSD clients." // //// //and // //// //"4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares // //For most SSSD clients, using SSSD is recommended:" // //// //and most worrisome, in my use case: // //// //"In environments with direct Active Directory integration where the // //clients use SSSD for general Active Directory user mappings, using // //Winbind for the SMB ID mapping instead of SSSD can result in // //inconsistent mapping." / In my case, running samba 4.8.3 with SSSD on centos 7 do I need to : - enable and start winbind service , in conjunction to sssd ? - or only sssd is enough with samba ? - Do I have to fear issues in next release of sssd for the support of samba ? especially for acls support ?/ / A nsswitch.conf like : passwd: files sss winbind shadow: files sss winbind group: files sss winbind or passwd: files winbind sss shadow: files winbind sss group: files winbind sss Does not seem to work... I test and this is not stable. Best Regards, Edouard

5 6

SSSD and PKI: capability of checking trust/validation/revocation
by Hristina Marosevic 30 Mar '20

30 Mar '20

Hello, I am using SSSD with LDAP directory which provides public keys for each user entry to SSSD. I am not sure if it is possible to configure SSSD not just to accept the private key (provided by the user during the login) and authenticate the user from LDAP (where his public ke is stored), but also to check the: - trust (validation of the CA used for signing the user's certificate i.e. public key) - validity of a user certificate with its public key (its "from" - "to" dates) - revocation status (configuration of SSSD with CRL lists or OCSP) or should I manage this on the LDAP side or on application level or somewhere else? I would be grateful if you share your ideas about the possible solutions of this situation! BR, Hristina

4 47

ldb_modify/sdap_save_group errors
by Orion Poplawski 27 Feb '20

27 Feb '20

I'm getting lots of messages like the following in our newer EL8 IPA servers: (Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait from ldb_modify with LDB_WAIT_ALL: No such object (32)] (Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] (0x0080): Cannot set attrs for name=Wireless Access(a)ad.nwra.com,cn=groups,cn=ad.nwra.com,cn=sysdb, 2 [No such file or directory] (Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_store_group] (0x0040): Cache update failed: 2 (Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_store_group_with_gid] (0x0040): Could not store group Wireless Access(a)ad.nwra.com (Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_group] (0x0080): Could not store group with GID: [No such file or directory] (Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_group] (0x0080): Failed to save group [Wireless Access(a)ad.nwra.com] [No such file or directory] (Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_groups] (0x0040): Failed to store group 1. Ignoring. ad.nwra.com is a trusted AD domain. Is this problematic? Thanks. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 1

Some more concerning messages
by Orion Poplawski 27 Feb '20

27 Feb '20

On a new EL8 IPA server: (Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]] [ipa_get_ad_override_connect_done] (0x0040): dp_id_data_to_override_filter failed. (Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]] [ipa_subdomain_account_got_override] (0x0040): IPA override lookup failed: 1432158283 (Tue Feb 25 10:51:49 2020) [sssd[nss]] [cache_req_common_process_dp_reply] (0x0040): CR #285589: Data Provider Error: 3, 1432158283, The internal name format cannot be parsed sssd-2.2.0-19.el8.x86_64 ipa-server-4.8.0-13.module+el8.1.0+4923+c6efe041.x86_64 -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 3

Encrypted communication to DC
by Jannis Mann 26 Feb '20

26 Feb '20

Hi, I am using sssd with out a domain join. So I am using a binding account which is working fine. I use our root CA to encrypt the communication to use ldaps over port 636. I found this FAQ https://docs.pagure.org/SSSD.sssd/users/faq.html (refering to the Authentication fails against LDAP section) Do I understand correctly that the communication is encrypted over TLS when I dont use ldaps?When this is the case I would not need the root ca certificate and can avoid the problem in running into an expiring certificate? Just for my understanding.. How is the TLS encryption to the DC possible if I don't have a certificate? When I dont use ldaps is every communication encrypted or only the transmission of the users password? What would speak for a ssl encryption over 636 if ldap over 389 is encrypted aswell with out certificate? Thank you and have a nice day!

3 2

auto-discovering sssd domains in upper case? (one small nit)...
by Spike White 25 Feb '20

25 Feb '20

All, When I was first crafting my sssd.conf file, I very much attempted to make all my sssd domains upper-case. Because in my (naive) view, an AD domain is just a Kerberos realm (+ LDAP + nice admin screens). As you know, Kerberos is very much case-sensitive. (Technically, AD is not. but the convention in the /etc/krb5.conf file is to always put Kerberos realms in upper case). Back to sssd. When sssd auto-discovered the other parent and child domains, it discovered them in lower case. I was left with a mix of upper and lower-case sssd domains. Even worse, the one local AD domain showed up twice. Once in upper-case (explicitly defined in sssd.conf) and once in lower-case (auto-discovered). Eventually, I gave up and went with the (apparently recommended sssd) convention of lower-case sssd domain names. In the domain definition, I list the krb5_realm in upper case: [domain/amer.example.com] ... krb5_realm = AMER.EXAMPLE.COM This is extremely unimportant (lower case works). But is there an option to auto-discover sssd domains in upper case? Spike

3 2

Default ldap_group_name for LDAP & AD Providers
by Lars Francke 21 Feb '20

21 Feb '20

Hi, I was looking at the differences between the defaults in the AD & LDAP Provider (when using ldap_schema = ad) and there seems to be a single difference. LDAP: ldap_group_name = name < https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ldap/ldap_opts.c#_3… > AD: ldap_group_name = sAMAccountName < https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ad/ad_opts.c#_239> Looking at the AD schema[1] sAMAccountName is part of the group schema but I can't find name. Can anyone remember whether there is a reason for this inconsistency between the two? Cheers, Lars [1] <https://docs.microsoft.com/en-us/windows/win32/adschema/c-group> <https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ad/ad_opts.c#_239>

2 2

session management by sssd (when using LDAP as an authentication and authorization server)
by Hristina Marosevic 20 Feb '20

20 Feb '20

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 5

Restricted access to MemberOf attribute in AD
by Eugene Vilensky 20 Feb '20

20 Feb '20

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

2 1

SSSD / PAM / LDAP problem.
by Mark London 20 Feb '20

20 Feb '20

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.p… 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

2 1

Proper support for Hostbased Authentication
by Vinícius Ferrão 17 Feb '20

17 Feb '20

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,

2 2

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 14 Feb '20

14 Feb '20

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/lda… > > > > 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/lda… 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.fedo… > > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > > >> 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.fedorahosted.…

1 0

Re: sssd 1.16.4. ADV190023.
by James Ralston 14 Feb '20

14 Feb '20

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.

2 1

sssd 1.16.4. ADV190023.
by David David 13 Feb '20

13 Feb '20

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-binding-…. 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.

3 2

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

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#_2… 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.m…. > > > > > > > > > > > > > > > > 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.fedo… > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > >> 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.fedorahosted.…

1 0

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

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.m…. > > > > > > > > > > > > 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.fedo… > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > >> 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.fedorahosted.…

2 1

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

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.m…. > > > > > > > > > > > > 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.fedo… > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > >> 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.fedorahosted.…

2 1

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

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-monitoring/search?e…> > User Name<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitoring/search?e…> > Binding Type<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitoring/search?e…> > 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=Departments,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=Departments,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.fedorahosted.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.fedorahosted.org> > > > > <sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.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.m…. > > > > > > > > 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%2Fgitl > > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2Fa6f795ba3d6048b32d78634 > > > 68688bf7f42b2cafd&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719 > > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1 > > > %7C637171761658405405&sdata=rPcG9mknHufVZUy6ege6n2vx%2B1Hy5XQhDn7H > > > 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%2Fgitl > > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2F85097245b57f190337225db > > > dbf6e33b58616c092&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719 > > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1 > > > %7C637171761658405405&sdata=9dY6eOGTKimEYqydWbRFROldOTNRM16t1caeUh > > > 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.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%2Fdo > > > > cs > > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0 > > > > 2% > > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2% > > > > 7C > > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sd > > > > at > > > > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%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%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5b > > > > dd > > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdata=QUgcpi8 > > > > 2T > > > > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%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%7Cc0f76fa86d4d42c2 > > > > ae > > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C63716602 > > > > 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.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%2Fdo > > > > cs > > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0 > > > > 2% > > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2% > > > > 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%2Ffe > > > > do > > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo > > > > te > > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5b > > > > dd > > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdata=CIJal5z > > > > 4E > > > > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%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%7Cc0f76fa86d4d42c2 > > > > ae > > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C63716602 > > > > 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.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%7C87719229ad54467ff98808d7b0576033%7C > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdat > > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%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%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5bdd > > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3GV > > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%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%7C87719229ad54467ff9 > > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371717616 > > > 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.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%7C87719229ad54467ff98808d7b0576033%7C > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdat > > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%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%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5bdd > > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3GV > > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%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%7C87719229ad54467ff9 > > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371717616 > > > 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.fedo… > > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > > >> 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.fedorahosted.…

2 2

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

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> > Sent: Thursday, February 6, 2020 10:18 AM > To: sssd-users(a)lists.fedorahosted.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> > > Sent: Thursday, February 6, 2020 12:09 PM > > To: sssd-users(a)lists.fedorahosted.org > > <sssd-users(a)lists.fedorahosted.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.m…. > > > > 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%2Fgitlab.fr… > 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%2Fgitlab.fr… > 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 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%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdat > > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%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%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdata=QUgcpi82T > > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%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%7Cc0f76fa86d4d42c2ae > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371660275 > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3D& > > amp;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%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdat > > a=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%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%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdata=CIJal5z4E > > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%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%7Cc0f76fa86d4d42c2ae > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371660275 > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3D& > > amp;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.fedo… > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > >> 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.fedorahosted.…

2 1

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

On Mon, Feb 10, 2020 at 12:17:22PM +0000, Ondrej Valousek wrote: > Hmm, > The solution with ldap_uri=ldaps://.... is bit ugly and personally I wonder that it works (unless you used public CA to sign AD connections which is, I'd say, quite rare to see) because normally to do that you need to import AD certs. > I guess sssd developers could shed some light into it as I'm not sure either. Hi, you are right, I would recommend to stay with 'id_provider = ad' and use the default LDAP port 389. SSSD uses a SASL bind with GSSAPI in this configuration and as long as the SASL security strength factor (SSF) is higher than 1 in integrity requirement from AD (LDAP signing) should be satisfied. I did some tests yesterday again with some older versions of RHEL7 and AD where channel binding and LDAP signing were required by registry settings as recommended by Microsoft and didn't run into issues with the default SSSD configuration on this platform. If you are seeing issues, it would be nice if you can send some network traces covering the LDAP connections causing the issue or warning on AD. Thanks. bye, Sumit > > Ondra > ________________________________ > From: David David <modrik(a)seznam.cz> > Sent: Thursday, February 6, 2020 5:20 PM > To: sssd-users(a)lists.fedorahosted.org <sssd-users(a)lists.fedorahosted.org> > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023. > > Ahoj Ondro, > well my knowledge about sssd is limited, but I would say that the daemon did it instead me. See the middle message: > Task [AD machine account password renewal]: finished successfully > > This task is by default scheduled after restart of sssd service always. > > However, I probably found another way how to stay safe after AD patching - I have switched from id_provider = ad, to id_provider = ldap, that allowed me to specify ldap_uri = ldaps://our_ad_machine.domain. After restart sssd AD has stopped complaing about unsighned request, because all communication is handled over TSL 1.2. > > But I am still curious if there is another solution in case that I would like to keep the setting in mode id_provider = ad. Is there any way to sighn this kind of request? We were affraid that AD will refuse all unsigned communication after the AD patch is applied. > > Thanks a lot for your knowledge sharing :) > > > _______________________________________________ > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > List Guidelines: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > _______________________________________________ > 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.fedorahosted.…

1 0

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 12 Feb '20

12 Feb '20

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> > Sent: Thursday, February 6, 2020 12:09 PM > To: sssd-users(a)lists.fedorahosted.org <sssd-users(a)lists.fedorahosted.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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.m…. > > 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://gitlab.freedesktop.org/realmd/adcli/commit/a6f795ba3d6048b32d786346… 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://gitlab.freedesktop.org/realmd/adcli/commit/85097245b57f190337225dbd… 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 > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > List Guidelines: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > _______________________________________________ > 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.fedorahosted.…

2 1

Re: sssd 1.16.4. ADV190023.
by David David 10 Feb '20

10 Feb '20

Ahoj Ondro, well my knowledge about sssd is limited, but I would say that the daemon did it instead me. See the middle message: Task [AD machine account password renewal]: finished successfully This task is by default scheduled after restart of sssd service always. However, I probably found another way how to stay safe after AD patching - I have switched from id_provider = ad, to id_provider = ldap, that allowed me to specify ldap_uri = ldaps://our_ad_machine.domain. After restart sssd AD has stopped complaing about unsighned request, because all communication is handled over TSL 1.2. But I am still curious if there is another solution in case that I would like to keep the setting in mode id_provider = ad. Is there any way to sighn this kind of request? We were affraid that AD will refuse all unsigned communication after the AD patch is applied. Thanks a lot for your knowledge sharing :)

2 1

Stored copy of corrupted mmap cache in file ’/var/lib/sss/mc/group_corrupted#012’
by Tom 10 Feb '20

10 Feb '20

Is there a way to analyze the corrupted cache file to identify which group or user triggered the message? I'm interested in finding out what triggered this. Cheers, Tom Sent from my iPhone

2 1

Re: ldap_id_mapping=False then AD user's password not availabe
by James Cassell 07 Feb '20

07 Feb '20

On Thu, Feb 6, 2020, at 9:13 PM, Grant Longhurst wrote: > > Out of interest how did you solve it as have the same issue? > I don't see the referenced mail since you didn't quote it, but usually, you need both a uidNumber and gidNumber defined for each user to work everywhere including older sssd version if you're using the ldap_id_mapping=False setting. V/r, James Cassell

1 0

Re: ldap_id_mapping=False then AD user's password not availabe
by Grant Longhurst 06 Feb '20

06 Feb '20

Out of interest how did you solve it as have the same issue?

1 0

Re: Resolving User Groups - SSSD AD
by Sumit Bose 06 Feb '20

06 Feb '20

On Thu, Feb 06, 2020 at 01:40:46PM +0000, Sangster, Mark wrote: > Hello, > > I am switching our SSSD to use the AD provider but have found that the setup has issues with group membership. > > The following is my domain configuration: > > [domain/<DOMAIN>] > id_provider = ad > auth_provider = ad > access_provider = ad > ad_access_filter = (memberOf=<FILTER>) > ad_hostname = <CLIENT_HOST> > ad_domain = <DOMAIN> > dns_discovery_domain = <DOMAIN> > ldap_id_mapping = false > ldap_sasl_mech = GSSAPI > ldap_referrals = false > dyndns_update = false > cache_credentials = true > enumerate = false > ldap_purge_cache_timeout = 0 > > This setup works just not completely, user authentication and user/group lookups work. However if I attempt to list full group membership of a user (“id user” or “groups user”), then I am provided with only the primary group. Interestingly if I do the following: clear user from cache, lookup group, lookup user, then the information indicates the primary group and additional group. > We utilise an AllowGroups restriction within SSHD which fails, claiming the user isn’t in the group. Hi, what version of SSSD are you using on which platform? It would be best to have debug logs. For this please add 'debug_level = 9' to the [domain/...] and [nss] section of sssd.conf, restart SSSD and call 'id user' again. You can find more details at https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html. Since you are using 'ldap_id_mapping = false' it might be worth to try to disable the Global Catalog lookups by adding 'ad_enable_gc = false' to the [domain/...] section of sssd.conf. bye, Sumit > > Any suggests would be welcome. > > Thanks > Mark > > ------------------------------------------------------------------------ > Mark Sangster > Server Infrastructure Specialist > > Information Technology Services | University of Aberdeen > t: +44 (0)1224 27-3315 | e: mark(a)abdn.ac.uk<mailto:mark@abdn.ac.uk> | u: http://www.abdn.ac.uk/it/ > > > The University of Aberdeen is a charity registered in Scotland, No SC013683. > Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683. > _______________________________________________ > 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.fedorahosted.…

1 0

Resolving User Groups - SSSD AD
by Sangster, Mark 06 Feb '20

06 Feb '20

Hello, I am switching our SSSD to use the AD provider but have found that the setup has issues with group membership. The following is my domain configuration: [domain/<DOMAIN>] id_provider = ad auth_provider = ad access_provider = ad ad_access_filter = (memberOf=<FILTER>) ad_hostname = <CLIENT_HOST> ad_domain = <DOMAIN> dns_discovery_domain = <DOMAIN> ldap_id_mapping = false ldap_sasl_mech = GSSAPI ldap_referrals = false dyndns_update = false cache_credentials = true enumerate = false ldap_purge_cache_timeout = 0 This setup works just not completely, user authentication and user/group lookups work. However if I attempt to list full group membership of a user (“id user” or “groups user”), then I am provided with only the primary group. Interestingly if I do the following: clear user from cache, lookup group, lookup user, then the information indicates the primary group and additional group. We utilise an AllowGroups restriction within SSHD which fails, claiming the user isn’t in the group. Any suggests would be welcome. Thanks Mark ------------------------------------------------------------------------ Mark Sangster Server Infrastructure Specialist Information Technology Services | University of Aberdeen t: +44 (0)1224 27-3315 | e: mark(a)abdn.ac.uk<mailto:mark@abdn.ac.uk> | u: http://www.abdn.ac.uk/it/ The University of Aberdeen is a charity registered in Scotland, No SC013683. Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683.

1 0

Sorry for the spam mail
by Sumit Bose 06 Feb '20

06 Feb '20

Hi, I'm sorry, I pressed a wrong button and let 10 spam emails pass to the list. I'll try to be more careful next time. bye, Sumit

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users February 2020