#3281 case_sensitive incompatibility AD provider vs. cache
Closed: Duplicate None Opened 7 years ago by mreggie.

By default, the AD provider returns group names in lowercase. When the AD backend fails however, the results from the cache are case-preserved. In the case of AD group names with capitals, this breaks case-sensitive comparisons (in sshd's AllowGroups, for one).

The default for case_sensitive is True (including the cache), but for the AD provider the default is the opposite, False. This design breaks the basic compatibility that a cache should provide.

1) If possible, the cache should always follow the case_sensitive setting for that provider.

2) The case_sensitive default for the AD provider should follow the general default (True), or, only if not possible, the most compatible option: Preserving.


Hi,

I'm sorry, but I'm not completely sure what do you mean when you say "When the AD backend fails however, the results from the cache are case-preserved.". Can you give an example, please, or a reproducer or logs?

I think in general the case-sensitiveness must be consistent and for the AD provider, it should be case-insensitive, in other words case_sensitive=false.

AD provider online:

$ id testuser
uid=123456(testuser) gid=100513(domain users) groups=100513(domain users)

AD provider offline:

$ id testuser
uid=123456(testuser) gid=100513(Domain Users) groups=100513(Domain Users)

I have not found a way yet to controllable reproduce the problem. What happens is that on certain (CentOS 7.3, systemd) systems at boot the SSSD AD provider goes offline, and then group names are returned with case preserved. I'll attach the log. (Except for the case and a problem with Kerberos tickets, the caching works pretty good so it takes a while to notice the problem.)

My guess is SSSD is started before the network interface goes online, the internal DNS resolver fails and is never updated (because the /etc/resolv.conf does not need to be updated after a reboot?). I've tried changing the nameservers to non-existant IPs and restarting SSSD but unfortunately that doesn't reproduce the problem (the results from the cache are still lowercase).

Adding a dependency to network-online.target seems to fix the problem at boot. So maybe adding a dependency to network-pre.target instead may allow us to reproduce the problem, however I can't verify that until after this weekend.

My config is:

[sssd]
config_file_version = 2
domains = tudelft.net
services = nss, pam

[nss]

[pam]

[domain/tudelft.net]
id_provider = ad
access_provider = ad
debug_level = 3
ad_gpo_access_control = disabled
cache_credentials = true
dyndns_update = false
ignore_group_members = true
krb5_renew_interval = 1h
ldap_id_mapping = false
ldap_referrals = false
ldap_user_gecos = displayName
override_homedir = /home/nfs/%u

I'm sorry for the late reply, I was on vacation for two weeks.

I think this is a issue that we fixed kindof by accident in upstream. Are you able to test a patch if I build you a package for centos 7.3?

Sure, my test VM is affected so I can test whatever you need me to test. That indeed seems like a real good candidate.

(I did try the network-pre.target for SSSD but it didn't trigger the offline AD provider problem so I'm out of ideas for a reproducer.)

The test build fixes the problem: I can still see the SSSD AD provider going offline but the results returned remain lowercase (with case_sensitive defaulting to False).

Since it's fixed upstream, I guess this fix will automatically end up in one of the next updates?

This leaves me wondering why the default for case_sensitive for the AD provider ("False) is opposite to the general default ("True")?

Great, thank you for testing.

The fix will show up in RHEL-7.4 for sure. We can't fix RHEL-7.3 unless there is a support case open by a RHEL customer..

The default for the AD provider is false because user and group names in Windows are generally case-insensitive.

Since the testing proved that the patch fixed the issue, I'm closing the ticket as a duplicate of #3235.

Thank you for testing and reporting the bug!

resolution: => duplicate
status: new => closed

Metadata Update from @mreggie:
- Issue set to the milestone: NEEDS_TRIAGE

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4314

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata