Bug 1001318 - sssd-ad unable to resolve names in other domains possibly UPN related
sssd-ad unable to resolve names in other domains possibly UPN related
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
19
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-26 17:25 EDT by Colin.Simpson
Modified: 2014-01-15 13:22 EST (History)
8 users (show)

See Also:
Fixed In Version: sssd-1.11.1-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-30 22:16:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sssd.conf (473 bytes, text/plain)
2013-08-26 17:26 EDT, Colin.Simpson
no flags Details

  None (edit)
Description Colin.Simpson 2013-08-26 17:25:32 EDT
Description of problem:
When using the sssd-ad provider we are unable to resolve names in other domains. This is possibly related to our use of UPN logins (as again we presume this works for other people and the only real thing we think is different on our network but could be anything). 

Version-Release number of selected component (if applicable):
sssd-1.11.0-0.1.beta2.fc19.x86_64

How reproducible:
Every time

Steps to Reproduce:
1.getent passwd corp\\prodbuild


Actual results:
Returns nothing

Expected results:
Should return the RFC2307 user information for this user in the other domain

Additional info:

Logs seem to indicate that sssd seems to think the domain is offline even though it isn't.

(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f25c4fa9c90:1:prodbuild@corp.iongeo.lan]
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [corp.iongeo.lan][4097][1][name=prodbuild]
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x7f25c6aefa60
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f25c4fa9c90:1:prodbuild@corp.iongeo.lan]
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x7f25c6aefa60
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 7F25C6AE5BA0
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching.
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error message: Fast reply - offline
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider
Error: 1, 11, Fast reply - offline
Will try to return what we have in cache
(Mon Aug 26 19:12:22 2013) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f25c4fa9c90:1:prodbuild@corp.iongeo.lan]
Comment 1 Colin.Simpson 2013-08-26 17:26:16 EDT
Created attachment 790703 [details]
sssd.conf
Comment 2 Sumit Bose 2013-08-27 04:03:19 EDT
Can you attach the full logs, especially the sssd_domain.name.log would be userful.
Comment 3 Jakub Hrozek 2013-08-27 04:41:51 EDT
(In reply to Sumit Bose from comment #2)
> Can you attach the full logs, especially the sssd_domain.name.log would be
> userful.

Colin sent the logs privately and I'll forward them to you.
Comment 4 Sumit Bose 2013-08-29 05:42:09 EDT
Thank you for the log, they helped a lot. While trying to resolve the Globacl Catalog for some reasons SSSD uses only AAAA queries (IPv6 addresses) and does not try to find IPv4 adresses. I can reproduce this issue locally and will ook for a fix.
Comment 5 Jakub Hrozek 2013-08-29 07:23:01 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2063
Comment 6 Sumit Bose 2013-08-29 07:31:30 EDT
Can you try to set 'dyndns_update = False' in the [domain/iongeo.lan] section of sssd.conf and try to look up the user from the other domain again?
Comment 7 Colin.Simpson 2013-08-29 08:27:57 EDT
Didn't seem to workaround the issue. Unless I need to do some flushing of caches
Comment 8 Sumit Bose 2013-08-29 08:59:04 EDT
Additionally you can try to set 'lookup_family_order = ipv4_only'. Nevertheless it would be nice if you can send new logs with one or both of the parameters set.
Comment 9 Sumit Bose 2013-08-29 09:03:35 EDT
got the logs, thank you
Comment 10 Colin.Simpson 2013-08-29 11:03:03 EDT
Tried with no 'lookup_family_order = ipv4_only' and 'dyndns_update = False' . This seemed to still be unable to resolve other trusted domains.
Comment 11 Sumit Bose 2013-08-30 03:11:08 EDT
The issue with the AAAA queries is solved with workaround. I will prepare a patch so that the workaround is not needed anymore.

Now you are hitting a configuration issue. You are using 'ldap_id_mapping = False' i.e. you would like to use the POSIX UID and GID stored on AD. In older versions of SSSD the whole POSIX ID range 1-2**(31) is reserved for the domain. To avoid regression with older installation this is true for the current version as well. Because of this there are no free IDs for the other domains.

To get around this you can either set 'ldap_id_mapping = True' and delete the cache file. Or the new options ldap_min_id and ldap_max_id can be used to restrict the ID range for the POSIX IDs read from the AD server. Please note the for the other domains in the forest SID based ID mapping will be used to avoid ID conflicts.
Comment 12 Colin.Simpson 2013-08-30 06:28:39 EDT
I'd like to be able to pull RFC2307 attributes from all the domains in the forest. 

We have no ID collisions in the forest, the tool we use to change these doesn't allow them to exist, not sure if this is the tool or maybe now even AD itself doesn't allow this to happen (given RFC2307 is now shipped at standard in AD). It's an interesting question. But I don't think a config option should be unavailable just cause someone could do something that is very unwise in the first place.

Either way I think this should be an option, at least, like the ability to flatten usernames across all domains I logged as an RFE at Bug#1001325. Both these two things are supported by other third party AD Linux integration solutions and for good reasons. 

Firstly it gives a consistent UID/GID space across all domains (the forest should behave (and does in general) like a single large domain to end users) and all attributes should be the same to any joined Linux system, whatever the domain.

Secondly UID/GID information should be shareable/consistent with non-Linux applications (e.g the Windows NFS servers and other SFU services) a mapping scheme will not allow this (and unnecessary given we have this data in RFC2307 attributes). 

Thirdly, users can and do move between domains as they change location for example. Their UID should follow them (and on my RFE bug too their username shouldn't change as far as Linux systems are concerned). 

Forthly, mapping schemes don't allow migration from other directory services (or local users) where UID/GID's have to be maintained. 

I'd suggest that that id_mapping is only useful in a small company (or where the Linux admins don't have full/sufficient AD rights). When you start scaling to multiple domains and large companies with fully working RFC2307 setups (easy to get with a reasonable commitment to integration with Windows/Linux) it should never be used. It's fraught with problems....
Comment 13 Jakub Hrozek 2013-08-30 07:54:08 EDT
Do you also make sure that POSIX attributes are replicated to Global Catalog?  They are not by default..
Comment 14 Colin.Simpson 2013-08-30 08:56:23 EDT
True. But we do have these in the Global Catalog as it's a recommended performance enhancement if using RFC2307 attributes in a forest wide sense. 

Other AD integration technologies don't require this to though to allow RFC2307 to be used forest wide. As I say it's just a performance enhancement.
Comment 15 Sumit Bose 2013-08-30 14:58:08 EDT
(In reply to Colin Simpson from comment #12)
> I'd like to be able to pull RFC2307 attributes from all the domains in the
> forest. 

I had expected that such a request will come sooner or later. We have chosen a defensive approach for the start, because our view of a forest is a collection of independently managed domains. In your environment the whole forest is managed centrally by an external tool (at least with respect to the RFC2307 attributes).

But I agree that if the admin is sure that there are not conflicts it should be possible to make use of this knowledge and use the RFC2307 attributes for the whole forest.
 
> 
> We have no ID collisions in the forest, the tool we use to change these
> doesn't allow them to exist, not sure if this is the tool or maybe now even
> AD itself doesn't allow this to happen (given RFC2307 is now shipped at
> standard in AD). It's an interesting question. But I don't think a config

I just tried and it is possible with AD to create a user with the same short name and the same POSIX UID in two different domains of a forest even in the same NIS domain.

> option should be unavailable just cause someone could do something that is
> very unwise in the first place.
> 
> Either way I think this should be an option, at least, like the ability to
> flatten usernames across all domains I logged as an RFE at Bug#1001325. Both
> these two things are supported by other third party AD Linux integration
> solutions and for good reasons. 

Would you mind to open two RFEs in SSSDs own ticket tracker https://fedorahosted.org/sssd/newticket . If you prefer I can do it as well. I think two are better because from my point of view the ID issue is easier to solve than the name issue.

> 
> Firstly it gives a consistent UID/GID space across all domains (the forest
> should behave (and does in general) like a single large domain to end users)
> and all attributes should be the same to any joined Linux system, whatever
> the domain.
> 
> Secondly UID/GID information should be shareable/consistent with non-Linux
> applications (e.g the Windows NFS servers and other SFU services) a mapping
> scheme will not allow this (and unnecessary given we have this data in
> RFC2307 attributes). 
> 
> Thirdly, users can and do move between domains as they change location for
> example. Their UID should follow them (and on my RFE bug too their username
> shouldn't change as far as Linux systems are concerned). 
> 
> Forthly, mapping schemes don't allow migration from other directory services
> (or local users) where UID/GID's have to be maintained. 
> 
> I'd suggest that that id_mapping is only useful in a small company (or where
> the Linux admins don't have full/sufficient AD rights). When you start
> scaling to multiple domains and large companies with fully working RFC2307
> setups (easy to get with a reasonable commitment to integration with
> Windows/Linux) it should never be used. It's fraught with problems....
Comment 16 Sumit Bose 2013-08-30 15:04:10 EDT
Nevertheless it would be nice to know if with 'ldap_id_mapping = False' or with a restricted LDAP range the user can be resolved or if there is another issue. If you want to test I think it would be best to delete the sssd cache file or move it away so that it can be reused when the config is reset to its old state.
Comment 17 Colin.Simpson 2013-08-30 15:22:45 EDT
Having in the config file:

dyndns_update = False
lookup_family_order = ipv4_only
ldap_id_mapping = True

Does indeed correctly return user information for other domains:

# getent passwd corp\\prodbuild
prodbuild@corp.iongeo.lan:*:943823454:943823454:Build User:/home/prodbuild@corp.iongeo.lan:/bin/bash

As you suspected.

I'll file the upstream RFEs.

Thanks
Comment 18 Colin.Simpson 2013-08-30 23:18:58 EDT
I have opened two RFEs.

The first one to provide an option to flatten all usernames in the forest (on any domain) is here:

https://fedorahosted.org/sssd/ticket/2069

I have updated the bugzilla RFE I have for this at Bug#1001325 to point at this upstream RFE too.

The second one to pull RFC2307 attributes from all domains in a forest is here:

https://fedorahosted.org/sssd/ticket/2070

Can you verify these have been completed correctly?

Thanks
Comment 19 Jakub Hrozek 2013-09-02 05:41:48 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2070
Comment 20 Jakub Hrozek 2013-09-02 05:42:01 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2063
Comment 21 Jakub Hrozek 2013-09-02 05:43:32 EDT
Thank you, the RFEs upstream are fine. I also linked them with the two bugzillas you opened in our inhouse tool to track the changes between Bugzilla and Trac.
Comment 22 Sumit Bose 2013-09-02 09:41:05 EDT
(In reply to Colin Simpson from comment #17)
> Having in the config file:
> 
> dyndns_update = False
> lookup_family_order = ipv4_only
> ldap_id_mapping = True
> 
> Does indeed correctly return user information for other domains:
> 
> # getent passwd corp\\prodbuild
> prodbuild@corp.iongeo.lan:*:943823454:943823454:Build
> User:/home/prodbuild@corp.iongeo.lan:/bin/bash

Thank you for the confirmation. I'll fix the issue from comment #4 and close this ticket, since your RFEs now have separate tickets.

> 
> As you suspected.
> 
> I'll file the upstream RFEs.
> 
> Thanks
Comment 23 Jakub Hrozek 2013-09-05 05:34:53 EDT
Fixed upstream.
Comment 24 Jakub Hrozek 2013-09-27 10:11:11 EDT
The ability to resolve POSIX attributes was also just added upstream:
master:
    4343b618051d295cbb1a805a85feb117a91c6945
    c2aeea38addda1a07e60adbc3451f11b640f7bf1
    1b870ffa7910879f9310db453a31ab6f06392b9b
    d3e1d88ce7de3216a862b9fe78dc5aa94dcbc14b 
sssd-1-11:
    4b96f0cd6d075bc2aac18ba8368b65aaae41eb06
    2a413fb8751775f04ee989c92effd38299914ce1
    7830aeaa56d9c60438ffbf51130f5f1d223d628b
    85a5643dde73950a9c1e313699e2b7dc5eaa6758
Comment 25 Fedora Update System 2013-09-27 17:09:39 EDT
sssd-1.11.1-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sssd-1.11.1-1.fc19
Comment 26 Fedora Update System 2013-09-28 21:26:58 EDT
Package sssd-1.11.1-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.11.1-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17879/sssd-1.11.1-1.fc19
then log in and leave karma (feedback).
Comment 27 Fedora Update System 2013-09-30 22:16:10 EDT
sssd-1.11.1-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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