Bug 2225269 - SSSD should not chase referrals explicitly
Summary: SSSD should not chase referrals explicitly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: sssd
Version: 9.2
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Andre Boscatto
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-24 20:25 UTC by Abhijit Roy
Modified: 2023-08-02 09:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-02 09:52:16 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-163198 0 None None None 2023-07-24 21:57:45 UTC

Description Abhijit Roy 2023-07-24 20:25:53 UTC
Description of problem:

Disable ldap_referrals with respect to id_provider = ldap

I am opening this bz w.r.t https://bugzilla.redhat.com/show_bug.cgi?id=2222478#c12

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Andre Boscatto 2023-07-28 12:57:08 UTC
Hi Abhijit,

I talked to the team about this request, unfortunately Sumit is on PTO and he was the one following the case, but if we understood correctly, this is not the case for an RFE, let's deep dive into it.

SSSD is modifying the defaults for AD and IPA integrations (setting the ldap_referrals = false in those cases), but not LDAP because it indeed is supposed to work. 

What we understood from the scenario is that the customer, in the end of the day, is running against AD and not LDAP, so the proper option should be setting the id_provider to AD and not setting ldap_referrals = false to LDAP.

Are we right about our understanding?

Comment 4 Abhijit Roy 2023-07-28 15:01:56 UTC
(In reply to Andre Boscatto from comment #2)
> Hi Abhijit,
> 
> I talked to the team about this request, unfortunately Sumit is on PTO and
> he was the one following the case, but if we understood correctly, this is
> not the case for an RFE, let's deep dive into it.
> 
> SSSD is modifying the defaults for AD and IPA integrations (setting the
> ldap_referrals = false in those cases), but not LDAP because it indeed is
> supposed to work. 
> 
> What we understood from the scenario is that the customer, in the end of the
> day, is running against AD and not LDAP, so the proper option should be
> setting the id_provider to AD and not setting ldap_referrals = false to LDAP.
> 
> Are we right about our understanding?

Hi Andre,

Thanks for your reply.

Cus is using `id_provider = ldap` but the ldapserver is AD. The reason cus can't use `id_provider = ad` since it's not a direct integration with AD.

Here is the sssd.conf

[domain/AD]
cache_credentials = False
debug_level = 4
enumerate = False
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = none

ldap_schema = rfc2307bis
ldap_id_use_start_tls = True
ldap_uri = ldap://ldap.ad.utah.edu:389
ldap_tls_cacertdir = /etc/sssd/cacerts
ldap_tls_cacert = /etc/sssd/cacerts/iam-car_iam-car-ca.pem
ldap_tls_reqcert = demand
ldap_default_bind_dn = CN=itsunixldap,OU=Unix,OU=PROD,OU=ESS,OU=UUHC,DC=ad,DC=utah,DC=edu
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = ********

ldap_user_search_base = OU=People,DC=ad,DC=utah,DC=edu
ldap_group_search_base = OU=Security Groups,DC=ad,DC=utah,DC=edu
ignore_group_members = True
#access_provider = ldap
#ldap_access_order = filter
#ldap_access_filter = memberOf=CN=HSC Users,OU=Security Groups,DC=ad,DC=utah,DC=edu
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_fullname = displayName
ldap_user_name = sAMAccountName
ldap_user_uid_number = uniqid
ldap_user_gid_number = uidNumber
#ldap_group_gid_number = uidNumber
## Set default group id for sss users
override_gid = 1000
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell

[sssd]
config_file_version = 2
services = nss, pam
domains = AD
reconnection_retries = 3
sbus_timeout = 30


[nss]
filter_groups = root
filter_users = root, nagadm, gkravitz
reconnection_retries = 3
entry_cache_nowait_percentage = 0
memcache_timeout = 20
## Override AD default shell
override_shell = /bin/bash
fallback_homedir = /home/%u


[pam]
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
pam_account_expired_message = Account expired, please contact ITS-UNIX team.
pam_account_locked_message = Account locked, please contact ITS-UNIX team.

Correct me if I am wrong. As per Sumit’s comment https://bugzilla.redhat.com/show_bug.cgi?id=2222478#c12 it is expected that referrals do not work as expected. This is already disabled when using ‘id_provider = ad’ then my idea is to disable the same with id_provider = ldap  as well to avoid issues.

Comment 7 Abhijit Roy 2023-07-28 15:05:19 UTC
Hi,

I am removing the RFE keyword for now may be RFE won't be a valid option here.

Comment 9 Alexey Tikhonov 2023-07-31 08:48:12 UTC
Hi,

(In reply to Abhijit Roy from comment #4)
> 
> Correct me if I am wrong. As per Sumit’s comment Red
> Hathttps://bugzilla.redhat.com/show_bug.cgi?id=2222478#c12 it is expected
> that referrals do not work as expected. This is already disabled when using
> ‘id_provider = ad’ then my idea is to disable the same with id_provider =
> ldap  as well to avoid issues.

No, this comment says:
```
**With Active Directory** in the server side, it is expected that referrals do not work as expected.
```

It's expected to work properly with other LDAP servers.

Comment 10 Abhijit Roy 2023-08-01 14:34:27 UTC
(In reply to Alexey Tikhonov from comment #9)
> Hi,
> 
> (In reply to Abhijit Roy from comment #4)
> > 
> > Correct me if I am wrong. As per Sumit’s comment Red
> > Hathttps://bugzilla.redhat.com/show_bug.cgi?id=2222478#c12 it is expected
> > that referrals do not work as expected. This is already disabled when using
> > ‘id_provider = ad’ then my idea is to disable the same with id_provider =
> > ldap  as well to avoid issues.
> 
> No, this comment says:
> ```
> **With Active Directory** in the server side, it is expected that referrals
> do not work as expected.
> ```
> 
> It's expected to work properly with other LDAP servers.

Hi Alexey,

Thanks for the details. So, in that case, it won't be valid to set referrals = false as default with `id_provider = ldap`. 

You can close this bug.


Note You need to log in before you can comment on or make changes to this bug.