#3547 data from ipa returned with id_provider=file
Closed: Fixed 6 years ago Opened 6 years ago by hedrick.

centos 7.3, sssd 1.15.2-50.el7_4.2

with id_provider=file I expect that getent -s sss passwd USER will return data only for users in the local /etc/passwd. In fact it returns data for anyone in IPA.

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = cs.rutgers.edu
id_provider = files
auth_provider = ipa
access_provider = permit
ipa_hostname = krb4.cs.rutgers.edu
chpass_provider = none
ipa_server = krb4.cs.rutgers.edu
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_server_mode = True
[sssd]
services = pam, nss

domains = cs.rutgers.edu


hm.... may have been caching. When I removed /var/lib/sss/db/* this problem went away. However at that point "getent -s sss passwd USER" didn't even return data for users in the local file.

may I know what is a use-case for:

id_provider = files
auth_provider = ipa

?

I would like to ask for logs here. But please note that for the AD and IPA providers, there might be assumptions in the code that the user information comes from the same provider.

The 'lower-level' providers such as krb5 or LDAP doesn't have this limitation.

The use case is a server with limited access and its own groups. I want to use local /etc/passwd and group, but Kerberos passwords. There are obviously other ways to achieve my goals, so this isn't a high-priority problem, but it seemed like something that should at least be documented.

The use case is a server with limited access and its own groups. I want to use local /etc/passwd and group, but Kerberos passwords. There are obviously other ways to achieve my goals, so this isn't a high-priority problem, but it seemed like something that should at least be documented.

Then it might better to use id_provider = files with auth_provider = krb5.

I do not think we want to support id_provider = files + auth_provider = ipa

I don't have a problem with saying that it won't work, as long as you document it.

I agree we should turn this ticket into documenting in the sssd-ad and sssd-ipa man pages that the ipa and ad auth providers assume certain properties about user data that the id provider stores in the cache and therefore should only be used with the same provider type.

Metadata Update from @jhrozek:
- Issue tagged with: docs

6 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.1

6 years ago

I didn't want this easy ticket to roll from one release to another, so here's a PR:
https://github.com/SSSD/sssd/pull/479

I wonder if we should also print a DEBUG matches with an incompatible provider type?

Metadata Update from @jhrozek:
- Issue tagged with: PR, postpone-to-1-16-2

6 years ago

Metadata Update from @jhrozek:
- Issue priority set to: minor

6 years ago

Metadata Update from @jhrozek:
- Issue assigned to jhrozek

6 years ago

master:

sssd-1-14:

sssd-1-13:

Metadata Update from @lslebodn:
- Issue untagged with: postpone-to-1-16-2
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 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/4573

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